On Wednesday, February 9, 2022 at 9:16:23 AM UTC-8 Kathleen Wilson wrote: > All, > > In regards to the DRAFT Policy about CRLRevocation Reason Codes for TLS > End-Entity Certificates > <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing> > ... > > I do not want to detract from the ongoing discussions here > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/RVFnJJRuUag/m/VFoZh78bBgAJ>, > > but I would like to make forward progress on the following items, so I'm > starting this separate discussion thread. > > 1) Should we add policy to encourage CAs to update the CRL entry for a > certificate that was previously revoked for a non-keyCompromise reason, but > then later it is learned that the private key has been compromised? > Similarly, the CA may learn that the compromise date was earlier than what > they originally put into the CRL. > > My opinion: I think this is a good idea, that I have not yet addressed. >
I added the following paragraph to the keyCompromise section: "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. " > > 2) Should the non-keyCompromise reason codes be required? Or should the > language "The CRLReason ... MUST be used" be changed to "The CRLReason > ... MAY be used"? > > My opinion: I think the language should remain "MUST", because I would > like to get to the point that relying parties can depend on these reason > codes being used consistently, and decide for themselves about how to use > them. In my explanation about why establishing this policy is important > <https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#Revocation_Is_Important>, > > I focused on keyCompromise, but it would be reasonable for Mozilla to > decide to hard-fail for other allowed CRLReasons as well. > I kept the "MUST" wording, and added a "Background Information" section to the end of the document. > 3) Should there be a priority order to the CRLReason codes? > > My opinion: I think it's safe to say that keyCompromise is top priority, > but I prefer not to assign priority to the other CRLReasons. It is fine > with me if you all want to discuss priorities for the purpose of > implementation logic -- if that's the case and you think this should be a > recommendation in the policy, then please suggest what the > implementation/logic order should be. > I have not added priorities to the reason codes. Distantly related... I updated the list of acceptable reason codes to more clearly explain the numbers, and removed the reason flag numbers from the rest of the draft policy. - keyCompromise (RFC 5280 Reason Flag #1) - affiliationChanged (RFC 5280 Reason Flag #3) - superseded (RFC 5280 Reason Flag #4) - cessationOfOperation (RFC 5280 Reason Flag #5) - privilegeWithdrawn ((RFC 5280 Reason Flag #7) > > 4) Should CAs provide the explanation about CRLReason codes in their > subscriber agreement? Or should the policy leave it open as to where the CA > provides that information for their customers? > > My opinion: I think it should be in the subscriber agreement, and the CA > is welcome to provide it other places too. > I have kept it as needing to be in the subscriber agreement. That does not preclude the CA providing the information elsewhere. > > 5) What CRLReason makes sense for the following two scenarios? > - the certificate subscriber notifies the CA that the original certificate > request was not authorized and does not retroactively grant authorization; > or > - the CA obtains reasonable evidence that the validation of domain > authorization or control for any fully‐qualified domain name or IP address > in the certificate should not be relied upon. > > My opinion: In certain situations it might be appropriate for the CA to > use keyCompromise -- that's why these are currently in the draft as "MAY > use keyCompromise". But if the situation does not warrant keyCompromise, > should privilegeWithdrawn be used? > > The following paragraph is in the keyCompromise section: "The CA MUST use either the keyCompromise reasonCode or the privilegeWithdrawn reasonCode when the CA obtains verifiable evidence that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate. The CA SHALL determine which of those two reasonCodes is appropriate under the circumstances of the revocation. For example; - the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or - the CA obtains reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the certificate should not be relied upon. " I will appreciate your feedback on these changes. Thanks, Kathleen -- 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/6bdf57ba-d5aa-41bf-9e6f-cb171c6d86e9n%40mozilla.org.
