Hi Ryan,
I tried to put some comments in-line below with delimiters before/after (---). Outlook is lousy at this, so if you can’t find my comments I can try this another way. Doug From: Ryan Sleevi <[email protected]> Sent: Tuesday, March 22, 2022 11:17 AM To: Doug Beattie <[email protected]> Cc: Kathleen Wilson <[email protected]>; [email protected] Subject: Re: Adjusting the Draft Policy for Revocation Reason Codes On Tue, Mar 22, 2022 at 8:02 AM 'Doug Beattie' via [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > wrote: #1) regarding the last sentence of the second bullet under the scope of the keyCompromise which says: * The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key. And specifically the statement “MAY block issuance… “. Should this be limited to this subscriber, or would a CA be permitted to block issuance of ALL certificates with this public key? If it’s globally, then I think there is a DoS issue. Should we clarify the scope of the “MAY” by adding “…for that certificate subscriber” to the end of the sentence? Isn't that more restrictive on CAs? That is, you end up limiting the reasons they may block issuance to a single reason. There is potential for DoS, yes, but managed at an individual CA, and with the CAs' discretion as to when and how they act. That is, the scope seems fine as-is, in one of the few times I find myself arguing for CA discretion 😅 --- I’m proposing that we change this: * The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key. To this: * The CA MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key for that subscriber. If we don’t do this, then a CA would be permitted to globally block issuance with certs with that key. Do we want CAs to do that? We went out of our way to prevent this in the keyCompromise section. --- #2 privilegeWithdrawn I understand the prior intent that the CA must be the entity that sets this and that it cannot be supplied by the Subscriber; however, a new bullet was added that says: “the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization.” Isn’t this basically the subscriber specifying the reason without the CA actually “validating” it’s true? If so, then is it necessary to prohibit the subscriber from selecting this reason directly? Isn't the difference that the subscriber is directly affirming the intended semantics, versus the proposed change, which would let them express this for any arbitrary reason? --- Most of the other reasons affirm specific semantics, so I don’t see a difference with this reason code. * the certificate subscriber requests that the CA revoke the certificate for this reason, with the scope of revocation being described below. * the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization. Seems that the subscriber asserts something and then it’s reflected in the CRL reason code. Is privilegeWithdrawn any different? --- That is, I think the difference here is whether or not the customer receives guidance about the intended semantics or not. Is that critical? I'm not sure, but it at least seems to be a functional difference here. #3 superseded This was recently added * or the CA has replaced the certificate due to domain authorization or compliance issues other than those related to keyCompromise or privilegeWithdrawn. but does a CA ever “replace” certificates? I think that the applicant/subscriber is the only entity that can request replacement certificates, unless there is a scenario that I’m not thinking of. I agree with your first question but not sure I understand your second remark? That is, a certificate cannot be distinguished by itself as a "replacement" certificate - a certificate is simply a certificate, independent of all that came before and after. A customer requests a new certificate to replace an old certificate, and so it's functionally a replacement, but that's technically indistinguishable. If CA Foo issues a certificate for domain.example , and then the domain owner goes to CA Bar to obtain a certificate for domain.example, has Bar replaced Foo? Where I'm going is do you think the language resolves if "the CA has revoked the certificate due to ...", and avoids the word "replace" (and the presumption of a 'new', from either Foo or Bar)? --- Yes, I think a wording update would solve the problem here --- #4 General question In a few places we say to use a specific reason code only when X, Y and Z reasons are not used. Is this necessary vs. just saying when it can be used and being silent on when it can’t be used or adding these dependencies? It makes determining the right reason code much more transparent, imo I'm having trouble following this, perhaps you could explain more? That is, it seems like the risk exists either way of CA's misinterpreting, and I thought the general preference of most CAs was to give every explicit MUST/MUST NOT. Leaving things underspecified (by silent on when it can't be used) seems like it invites the default allow/default deny ambiguity? --- Most of the reason codes are supplied by the Subscriber and not the CA (not all of course). If CAs are responsible for “training” users on the proper use, it would be more beneficial to say exactly when they need to use it and not tie in other reasons, like this – does this add any value if the reasons for using the code is clear? This is extremely hard to parse: * The CRLReason affiliationChanged MUST be used when * the certificate subscriber has requested that their certificate be revoked for this reason, or * the CA has * replaced the certificate due to changes in the certificate’s subject information and * the CA has not replaced the certificate for the other reasons: keyCompromise, superseded, cessationOfOperation, or privilegeWithdrawn. What are the CA rules for when this reason can be used? Maybe it’s just the “CA has replaced” wording again that needs to be cleaned up, but it’s not clear to me when a CA MUST use this reason code. -- -- 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/TYZPR03MB6135C3382EBA74DD77EF4C9FF0179%40TYZPR03MB6135.apcprd03.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
