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] <mailto:[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/PUZPR03MB61294383C8CC71BC3DC36B6FF0F49%40PUZPR03MB6129.apcprd03.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
