On Wed, Dec 29, 2021 at 3:18 PM Peter Bowen <[email protected]> wrote:
> From the bug above, and linked bugs, it seems that the status issue is > that the root certificate profile in the current version of the BRs > says "If the Root CA Private Key is used for signing OCSP responses, > then the digitalSignature bit MUST be set." You are asserting that if > _any_ certificate exists that identifies a CA in the Mozilla trust > store as the subject exists that does not assert the digitalSignature, > then that CA key may not directly sign OCSP responses. For example, > if CA in the Mozilla trust store has an old v1 certificate issued > before the BRs, then it cannot directly sign OCSP responses, even if > the certificate in the Mozilla trust store is v3 and has the > digitalSignature bit asserted. You appear to be asserting that there > is no possible remediation action that can be taken by the CA operator > to allow this - the only two actions would be Mozilla updating the > Mozilla policy to explicitly allow this or for the CA/BF to modify the > BRs to either remove the requirement or clarify that the sentence is > not normative. > > Is this an accurate representation of your view? > Not quite, at least how you framed it. That is, I think you're spot on and we're in very much agreement about the vertices being (CA key, DN), which is also how it's reflected in tools like crt.sh (e.g. the CA ID), with certificates linking as edges between these vertices. To borrow from that terminology, I think we can agree that a self-signed certificate effectively serves as an edge that is a self-loop. That is, for a self-signed certificate, the Subject DN == Issuer DN, and the SPKI == Signing Key, we draw an edge from the vertex back to itself, with that edge being the self-signed certificate. The distinction here is that doppelgangers for CA certificates also serve as self-loops between these (Key, DN) tuples. If you have Cert A (using Key 1, Issuer DN == Subject DN == DN Foo), and Cert A' (using Key 1, Issuer DN == Subject DN == DN Foo), then we can say that A issued A', and A' issued A. If we're imagining these as vertices and edges, then for A and A', there are two edges between the vertex (Key, DN) - the first edge is a self-loop A, the second edge is a self-loop A'. When it comes to building paths to the vertex (Key, DN), then we can build a path [A], [A'], [A, A'], and [A', A], while paths such as [A, A], [A', A'], [A, A', A], and [A', A, A'] are prohibited by X.509 (specifically, Section 10.1(a), at least in 08/2005). This is explicitly called out in RFC 4158, Section 5.2 (and Section 2.4.2), when discussing paths that are valid in RFC 5280 (Section 6.1.3) but can otherwise cause suboptimal loops. From an RFC 5280 perspective, if we imagine a CA A, CA A' (as above), and EE B, then the possible valid paths here are [[A, B], [A', B], [A', A, B], [A, A', B]]. As a first check for possible disagreement: 1) Do we agree that [A, A', B] and [A', A, B] are valid paths? - If we don't agree, we should dig into that more, to figure out if there's a misunderstanding of the relevant documents. Assuming we agree here, the next possible source of disagreement is: 2) Is the following statement accurate, assuming A is a trust anchor: "A' is an intermediate certificate which has at least one valid, unrevoked chain up to a CA certificate included in, or under consideration for inclusion in, the Mozilla root program" - If we don't agree, we should dig into that more, because this can have some truly interesting consequences for what misissuance means. Note that, in tools like CCADB and crt.sh, there's been an understanding that both A and A', because they share (Key, DN), are considered "in-scope". For example, disclosure is required for these certificates; if A' is encountered in CT, for example, and not disclosed in CCADB (at minimum, as an intermediate of A), then it's been treated as a failure to disclose and a violation of policy. This is what I mean when I say that doppelgangers have been considered in scope. Section 5.3 of Mozilla's policy makes this very explicit, in the discussion of "directly or transitively chain to a CA certificate", by defining the technical properties that apply here, and Section 5.3.2 applies the audit and disclosure requirement. If these two previous statements hold, then the conclusion is that, on encountering an OCSP Response, Signed by Key 1, issued by DN Foo, then the OCSP response is signed by both A and A'. Both A and A' are subject to policy and the BRs, as the alternative can have quite interesting consequences. If A and A' differ in their capabilities - for example, in key usage - then one of them has violated the BRs, and thus, policy. By A existing, it means you cannot create an A', because even if A' replaces A as the trust anchor, the path [A', A, B] remains valid, A is subject to the BRs, and A is thus violating the requirements. A and A' share a Root CA Private Key, and the nature of the valid transitive paths mean that there is, indeed, no remediation, at least as it applies to root certificates, that would allow you to use Key 1 to sign OCSP Responses while asserting DN=Foo. Now, to briefly discuss Section 8.1.5 of X.509, which specifically touches on how to extend the capabilities of the CA with DN=Foo to include other key usages. If we read this as a closed-set (i.e. a default deny), then the scenario being described is that A' is being created to serve as a "type b)" certificate (e.g. used to add OCSP signing to a CA that lacks the capability for its public key). However, in this scenario, the expectation is a key change event, certifying a new public key, such that you're really creating a Certificate C, which shares the DN (DN=Foo), but contains a different key (Key 2). Certificate A/Key 1 signs Certificate C/Key 2, and the path for certificates remains [A, B], while the path for OCSP responses is [A, C]. This is, in effect, a delegated OCSP signing certificate whose DN (Foo) is shared between A and C, but which otherwise represents distinct paths. Understandably, if you read Section 8.1.5 as an illustrative set (i.e. default allow), this argument doesn't hold, but it's also not key to understanding the scope issues touched on above. Of course, this scenario (of DN=Foo being associated with both Key 1 and Key 2) has its own set of complications, as some CAs have discovered in the context of generic key rollover (i.e. rekeying for expiration purposes). That's why I intentionally elided it from the set of options here, and which tracks with your own past thoughts on the binding between DN and Keys [1]. [1] https://archive.cabforum.org/pipermail/public/2016-November/008966.html -- 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%3DHE8O9bb%2BvuOencyXBRLPFx3UEVCEWA%3DPK1yRKtzErT1cA%40mail.gmail.com.
