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. 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. 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. 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. 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? Thanks to all of you who have been providing input into this draft policy. I greatly appreciate it! 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/8a043f09-0642-47e3-98f6-b52cdacd585fn%40mozilla.org.
