WilsonKathleen
commented
2 years ago Some of the requirements of this section (for example, that the "subscriber agreement... MUST inform certificate subscribers about the revocation reasons list above...") do not seem to "apply to revocations" so much as "apply to CA operators". When do these provisions go into effect? Do they have an effective date of June 1, 2022, along with the rest of this version, or do they have an effective date of October 1, 2022, along with the rest of this section?
October 1, 2022.
I have updated https://wiki.mozilla.org/CA/Root_Store_Policy_Archive#2.8 to indicate this expectation as well.
aarongable
Unfortunately I was on vacation while the final rounds of discussion on Revocation Reasons were wrapping up, so I didn't get a good look at the final-final version until after it was merged and published. Now the whole team has conducted a thorough review of the published text and we have a few questions, comments, and clarifications.
I'm sorry to resurrect the specter of this discussion, but some of the comments seem large enough that I would prefer to raise them now when there is still an opportunity for a potential v2.8.1 prior to October, rather than wait for them to be litigated by whatever CA is unlucky enough to have the first revocation-related incident after October 1st.
Some of the requirements of this section (for example, that the "subscriber agreement... MUST inform certificate subscribers about the revocation reasons list above...") do not seem to "apply to revocations" so much as "apply to CA operators". When do these provisions go into effect? Do they have an effective date of June 1, 2022, along with the rest of this version, or do they have an effective date of October 1, 2022, along with the rest of this section?
I believe that this bulleted-list format of highly-specific situation descriptions is likely to be interpreted as normative text, despite the "intended to be used" language at the top. In particular, the "will no longer be using the certificate" situation is not reflected in the reasons below (for example, they could still own the domain, but simply turn off their web server), which will lead to confusion especially regarding the question of "how much of the text in this section does the final sentence's 'Otherwise' cover?".
I suggest that this intro paragraph be shortened and elided into something more like: "The CRLReason cessationOfOperation is intended to be used when the website with the certificate is shut down prior to the expiration of the certificate, if the subscriber no longer owns or controls the domain name in the certificate, or if the subscriber is no longer legally permitted to own or control the domain name in the certificate".
What about situations where both a
privilegeWithdrawnqualification and acessationOfOperationqualification apply? For example, the Let's Encrypt Subscriber Agreement states "If at any time You no longer control the Internet domain names associated with any of Your Certificates... You will immediately request that ISRG revoke the affected Certificates.". If an applicant buys a domain, then requests that Let's Encrypt revoke any older certs issued to that domain's previous owner, then two things are true: 1) Let's Encrypt has received verifiable evidence that the previous subscriber is no longer authorized to use the domain in the certificate (therefore Let's Encrypt MUST usecessationOfOperation); and 2) the previous subscriber is in material violation of the subscriber agreement because they did not request to revoke as soon as they no longer controlled the domain (therefore Let's Encrypt MUST useprivilegeWithdrawn).As was discussed on the mailing list, I believe there needs to be an explicit hierarchy of reasons. I think this paragraph header should be: " Unless the keyCompromise or privilegeWithdrawn reason is being used, the CRLReason cessationOfOperation MUST be used when:"
Similar to the above, I believe this sentence needs to list all of the other reasons which should take precedence over it. However, since the second bullet point below actually implies that
supersededalso takes precedence overaffilicationChanged, I belive that this sentence should list all four other reason codes, and that this whole section should be moved to after thesupersededsection for sake of easy reading: "Unless the keyCompromise, privilegeWithdrawn, or cessationOfOperation, or superseded CRLReason is being used, the CRLReason affiliationChanged MUST be used when:"As noted above, this bullet point can remove the references to the other four revocation reasons, because they will be referenced in the first sentence of the paragraph.
First, I want to note that none of the language below references the certificate being replaced. This feels very odd to me -- the common meaning of "superseded" is that something has been replaced or supplanted, not simply disposed of. Is it appropriate to use the "superseded" reason code in situations where the certificate has been revoked (e.g. for having a one-second-too-long validity period) but not replaced? The text below suggests Yes, a common english understanding of the word suggests No. I think that if we are going to redefine the word to not imply replacement, that should be explicitly noted and called out in the section text.
Again, I suspect like this highly-specific paragraph will be treated as normative text and lead to bitter discussion over the intent and meaning of the text. I suggest that it be simplified to something like: "The CRLReason superseded is intended to be used to indicate when the CA operator needs to revoke and replace the certificate for reasons not covered by the other reason codes above, such as because the certificate was issued with a non-compliant validity period or extension."
And again, update this sentence to include all of the higher-priority reasons: "Unless the keyCompromise, privilegeWithdrawn, or cessationOfOperation CRLReason is being used, the CRLReason superseded MUST be used when:"