Hi Doug, I believe your email correctly summarizes the policy.
You also asked whether we were "expecting CAs to update reasonCode or revocationDate in any other cases to support TLS implementations that process the revocationDate field as the date when the certificate is first considered to be compromised”. I am not aware of any. Maybe others are aware of such potential implementations. I am unaware of any other situations where Mozilla policy allows divergence from RFC 5280 (in this particular area of revocation and CRL production), but I'm open to any corrections or clarifications from the community. Thanks, Ben On Thu, Apr 21, 2022 at 5:12 AM Doug Beattie <[email protected]> wrote: > Hi Ben, > > > > I wanted to ask a question about when revocation reasons and dates can be > changed. > > > > The current wording is: > > > > When the CA obtains verifiable evidence of private key compromise for a > certificate whose CRL entry does not contain a reasonCode extension or has > a reasonCode extension with a non-keyCompromise reason, the *CA SHOULD > update the CRL entry to enter keyCompromise as the CRLReason* in the > reasonCode extension. Additionally, *the CA SHOULD update the revocation > date in a CRL entry when it is determined that the private key of the > certificate was compromised prior to the revocation date that is indicated > in the CRL entry* for that certificate. Note: Backdating the > revocationDate field is an exception to best practice described in RFC 5280 > (section 5.3.2); however, this policy specifies the use of the > revocationDate field to support TLS implementations that process the > revocationDate field as the date when the certificate is first considered > to be compromised. > > > > From this, I assume that the logic needs to be: > > - Reason can be changed only from a non key compromise reason to the > keyCompromise reason. > - When setting the date for an initial revocation for key compromise > (and only key compromise), the revocationDate may be in the past. > Backdating for other reasons is not being endorsed by Mozilla and CAs > should follow RFC5280 > - Date can be changed only when the reason is keyCompromise (either > when changing it to keyCompromise, or when reason was already > keyCompromise, if it was determined that the date first provides was > inaccurate.) > - The date can be changed to a date that’s before the current/existing > revocationDate (never move it later than a previously set date) > > > > Are you expecting CAs to update reasonCode or revocationDate in any other > cases to support “TLS implementations that process the revocationDate field > as the date when the certificate is first considered to be compromised”? > Given RFC 5280 recommends not backdating (or changing) revocation dates, we > wanted to get clear guidance for what scenarios Mozilla wants CAs to not > follow the RFC5280 best practices. > > > > If we apply the “default deny” logic to the Mozilla Policy, I believe the > logic I described above is an accurate representation, so perhaps no > additional changes to the policy are needed, but wanted to double check I > was not missing anything. > > > > Doug > > > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *Ben Wilson > *Sent:* Wednesday, April 13, 2022 1:18 PM > *To:* [email protected] <[email protected]> > *Subject:* Policy 2.8: Final Review of MRSP v. 2.8 > > > > All, > > > > Here are links helpful during your final review of version 2.8 of the > Mozilla Root Store Policy (MRSP) : > > > > https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.8/rootstore/policy.md > > https://github.com/mozilla/pkipolicy/compare/master...BenWilson-Mozilla:2.8 > (redlined) > > > > Please review the changes and provide any additional comments by the end > of Tuesday, April 19, 2022. > > > > My plan is to move this version over to the Mozilla pkipolicy repository > on Github <https://github.com/mozilla/pkipolicy/tree/master/rootstore>, > and then I'll request that it be published on Mozilla's website > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/> > to replace version 2.7.1. > > > > Thanks, > > > > Ben > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaby8DypMdN2ih3xF_nf0FoshtaKUes-KC%2Baxfi-3cRiqw%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaby8DypMdN2ih3xF_nf0FoshtaKUes-KC%2Baxfi-3cRiqw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZZ3LrXVUEqz5Xfb%3DHwHA9O%3DypjSgK%2BeS9Zi%2BBD9E4DVQ%40mail.gmail.com.
