On 09/06/2017 04:09, Jonathan Rudenberg 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.
This is getting awfully confusing.
What exactly about which specific certificates makes them both "self-
signed" and "part of a chain to a root in the Mozilla root store" ?
This seems to be a direct logical contradiction.
Here is how I see it:
If you are talking about two different certificates with the same public
key, then each such certificate needs to be considered separately.
If you are talking about two different certificates with the same
Subject Distinguished Name and optional id, but with different contents,
then again they need to be considered separately, as there is nothing
guaranteeing uniqueness of those fields.
If you are talking about two different certificates that differ only in
the Issuer and Signature fields (and maybe in the serial number too),
then again they need to be considered separately.
Chaining is defined by the tuple [Public Key, Subject, Optional Key ID],
deviating in either public key or subject certainly makes them unrelated
entities for chain building (except that sending irrelevant certificates
to the Browser can cause it to waste time comparing them). Deviating in
the key ID may or may not cause certificates to not chain together
depending on the certificate checking library used (NSS being most
important for Mozilla, BouncyCastle and BoringSSL being of additional
interest for Chrome).
Certificates (not keys or names) that actually chain (as defined above)
to a root certificate in the CCADB are in scope for CCADB policy,
others are not.
Certificates that are in scope and have CA:TRUE in basic constraints
and/or CertificateSigning in Extended Key Usage or (maybe) have an
equivalent bit set in the historic Netscape/Mozilla key usage attribute
belong in CCADB.
Certificates that are in scope but lack all of these CA-usage flags are
end entity certificates that must satisfy Mozilla policy on correct
issuance (such as ownership checks, no RFC1918 addresses as SANs etc.).
Certificates that are not in scope are not in scope.
For example if a virus-scanning middle box has a locally generated root
CA trusted by the local clients (via configuration), and that virus
scanning middle box generates on-the fly certificates matching the names
(but not the keys) in the real public certificates it sees, then those
on-the fly certificates may have the same Subject as the real
certificates, but don't become in scope that way, even if they leak back
out through various forms of "telemetry". Because there is no actual
way in which they would be trusted by a Mozilla browser that hasn't been
locally reconfigured to trust that local root CA.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
