On Tue, Mar 22, 2022 at 8:02 AM 'Doug Beattie' via [email protected] <[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 😅 > #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? 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)? > #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? -- 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/CAErg%3DHEYqV8v4d2mbBtu9dtM3y_3NoANEeeY3xBPWCCDj1F1wQ%40mail.gmail.com.
