On Wed, Apr 12, 2017 at 10:15 AM, Peter Bowen <[email protected]> wrote:
> On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy > <[email protected]> wrote: > > > > A certificate hash does provide distinct value. > > > > The certificate hash is what is desired. Yes, there could be multiple > > certificates. But within the context of the scope of an audit and a > > 'logical' CA, the auditor can and should be clear about what physical > > certificates corresponded to the logical operations of that CA. > > What portions of the certificate(s) naming that CA as the subject will > impact the audit? > > As I see it, the only certificates that are relevant to the audit are > those that have the CA as the issuer. It really doesn't matter who > cross-signs the CA. > So we talked about this (briefly) during the CA/Browser Forum F2F 40 in Raleigh, but: As you know, RFC 5280 defines a trust anchor as a DN/Key tuple as the basis for trust. That is, if a thing signed by a CA bears a particular DN in the field, we say that it was 'issued' by that CA - CAs can issue different things using a single key, governed by the relevant specification - For example, if a TBSCertificate ( https://tools.ietf.org/html/rfc5280#section-4.1 ) contains the given DN in the Issuer field, and is signed by the associated key (creating a Certificate), then we say the CA issued the Certificate - For example, if a TBSCertList ( https://tools.ietf.org/html/rfc5280#section-5.1 ) contains the given DN in the Issuer field, and is signed by the associated key (creating a CertList), then we say the CA issued the CRL - For example, if a CA's key is used to sign a ResponseData ( https://tools.ietf.org/html/rfc6960#section-4.2.1 ) in the production of a BasicOCSPResponse, then we say the CA issued the OCSP response (notably, there's no encoding of the Issuer DN within the ResponseData beyond that of the CertID, which comes from the request and contains the hash of the Issuer DN and Issuer Key, but not their actual values; the binding to the CA comes from the unsigned portion of the BasicOCSPResponse which establishes the certificate chain of the issuer, or is implied to be the issuer of the current CertID if absent) - For example, if a CA's key is used to sign a TBSCertificate ( https://tools.ietf.org/html/rfc5280#section-4.1 ) containing the given DN in the Issuer field, a critical poison extension ( https://tools.ietf.org/html/rfc6962#section-3.1 ) and signed by the associated key (creating a Certificate), then we say the CA issued the Precertificate (the confusion and complexity here about whether a Precertificate-is-a-Cert is well known) I mention all of these examples to illustrate that the act is with the key, and whether or not it was 'issued' determines on where, how, and if the given ASN.1 structure encodes the DN. There's a whole host of complexity there - for example, if I create a Sleevi-ID and submit to the IETF that uses the same ASN.1 structure of a Certificate/TBSCertificate, but name it differently (and perhaps use slightly different encoding, such as omitting the DEFAULT production rule for some fields in the syntax), is that or is that not a certificate? Now further, imagine a given CA has multiple certificates bearing the associated DN in the Subject, and sharing the same key. This might be the common case of having a self-signed certificate and one which may be cross-signed by either the same legal entity or a different legal entity. One of these certificates contains no nameConstraints extension (and the subject and issuer match) Another of these certificates contains a nameConstraints extension restricting its issuance practices to test.example (and a different issuer) I take that private key and copy it between two distinct infrastructures. The first infrastructure is my publicly trusted infrastructure. The second is what I call my 'test' instance. Both are independently maintained and operated, and responsible for their own serial number production (e.g. they may collide) I issue all sorts of 'evil' certs from the latter infrastructure (e.g. I don't perform domain validation). All of these I claim are benign, because nameConstraints means they are not processed as valid. Except for the fact that all of these 'evil' certs could be intepreted as chaining to the first CA (and thus be actively used for nefarious purposes). Now, if the auditor only comes in and examines the first infrastructure - the one that is acting properly - and issues an audit report, then they will have only examined one part of the issuance infrastructure, and only in the 'context' of the self-signed, well-behaving certificate. Without binding that audit to the certificate, my evil self can take that audit report and present it as being binding to my 'evil' infrastructure as proof that I have acted good and well, despite not having done so. You can also imagine the inverse (where the 'name constrained' infrastructure is the good infrastructure, but the 'unconstrained' infrastructure is the evil infrastructure), and you end up with transplantation issues. So the goal of binding not just to the name and key but also the certificate is an attempt to reduce the ambiguity and guarantee the scoping is related to what was examined. Other variations of this issue still exist. For example, if I encode my DN using printableString using one format, but UTF8String using another, can I attempt to do transplantation of audit statements across these name types? Hashing the name makes it more specific (since there's a specific sequence of bytes), and providing the name in textual, unencoded form makes it more general (since it assumes to all encodings of that sequence with that key) I'm not suggesting this comprehensively addresses the issues. I'm not suggesting this paranoia is warranted, other than I'm amazed by the ability of CAs to interpret the BRs and policies in the strangest of ways. Thus I assume that any statements will be interpreted either by a literal genie <http://tvtropes.org/pmwiki/pmwiki.php/Main/LiteralGenie> or a jackass genie <http://tvtropes.org/pmwiki/pmwiki.php/Main/JackassGenie>, and try to address that as best possible. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
