That's right, Peter. They should be out of scope unless browsers want to trust them and/or they are submitted to browsers for that purpose, in which case browsers should be responsible for inputting them into the CCADB.
Aside from treating these as "intermediates" or "subordinates", there are two other ways to look at a self-signed root certificate. First and more commonly, it is a certificate that someone created for submission as a trust anchor (and it is usually created prior to submitting the public key for cross-certification), and, second, it is basically a stub branch--because it is signing itself--that is one way that these kinds of certificates appear in the CCADB. I've gone ahead and uploaded these two root CA certificates as "intermediates" (https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619 and https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca), but I don't think that that is the right approach, IMO, and it would be nice if a policy existed that recognized my concerns. -----Original Message----- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Thursday, June 8, 2017 8:17 PM To: Jonathan Rudenberg <jonat...@titanous.com> Cc: Ben Wilson <ben.wil...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New undisclosed intermediates On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > >> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> I don't believe that disclosure of root certificates is the >> responsibility of a CA that has cross-certified a key. For instance, >> the CCADB interface talks in terms of "Intermediate CAs". Root CAs >> are the responsibility of browsers to upload. I don't even have access to >> upload a "root" >> certificate. > > I think the Mozilla Root Store policy is pretty clear on this point: > >> All certificates that are capable of being used to issue new certificates, >> and which directly or transitively chain to a certificate included in >> Mozilla’s CA Certificate Program, MUST be operated in accordance with this >> policy and MUST either be technically constrained or be publicly disclosed >> and audited. > > The self-signed certificates in the present set are all in scope for the > disclosure policy because they are capable of being used to issue new > certificates and chain to a certificate included in Mozilla’s CA Certificate > Program. From the perspective of the Mozilla root store they look like > intermediates because they can be used as intermediates in a valid path to a > root certificate trusted by Mozilla. There are two important things about self-issued certificates: 1) They cannot expand the scope of what is allowed. Cross-certificates can create alternative paths with different restrictions. Self-issued certificates do not provide alternative paths that may have fewer constraints. 2) There is no way for a "parent" CA to prevent them from existing. Even if the only cross-sign has a path length constraint of zero, the "child" CA can issue self-issued certificates all day long. If they are self-signed there is no real value in disclosing them, given #1. I think that it is reasonable to say that self-signed certificates are out of scope. Thanks, Peter
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
