Could I propose a change? I suggest adding an IneffectiveDate (i.e., the point in time when P-521 becomes allowed) to the old lints, and duplicating the PR implementation into new lints with an EffectiveDate (i.e., when P-521 becomes allowed). This way, we can avoid false negatives for P-521 certificates issued before that date. While this approach duplicates some code, I believe it is the simplest way to address the issue.

We could also keep the new implementation and set the date when P-521 becomes allowed as the EffectiveDate. If linting older certificates is not required, this approach would work as well. I suppose this touches on a more general issue with linting: if only forward linting is needed, then this solution should suffice. However, if retrospective linting is also necessary, then the first proposal would address that. Any thoughts?

@mtgag In the old version the policy had this line (It still does, but just for Curve25519 and 448):

The following curves are not prohibited, but are not currently supported: P-521, Curve25519, and Curve448.

So I would argue that the lint was being overly strict before by returning an error for P-521. In this case I think it's fine for this specific lint to be forward linting, since before it should've probably been returning a warning for P-521.

@mtgag In the old version the policy had this line (It still does, but just for Curve25519 and 448):

The following curves are not prohibited, but are not currently supported: P-521, Curve25519, and Curve448.

So I would argue that the lint was being overly strict before by returning an error for P-521. In this case I think it's fine for this specific lint to be forward linting, since before it should've probably been returning a warning for P-521.

The original lint refers to version 2.7 of the Mozilla policy (see: https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md#512-ecdsa).

In my opinion, either option 1, adding MozillaPolicy30Date as the ineffective date to the original lint and moving the PR implementation to a new lint with MozillaPolicy30Date as its effective date, or option 2, simply updating the effective date of the new lint to MozillaPolicy30Date, reflects the situation more accurately than option 3, which updates the implementation while keeping the original MozillaPolicy27Date.

I see what you mean, I'll update the effective date.

Howdy @digirenpeter, it looks like you went with option 2, simply updating the effective date of the new lint to MozillaPolicy30Date. Is this correct?

@mtgag thank you for chiming in! Does the change now reflect your vision?

That's right, I feel like option 2 is the cleanest, but I'm open to option 3 if people feel strongly enough about it.

Howdy @digirenpeter, it looks like you went with option 2, simply updating the effective date of the new lint to MozillaPolicy30Date. Is this correct?

@mtgag thank you for chiming in! Does the change now reflect your vision?

Yes, option 2 is perfectly fine.