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"

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On
Behalf Of Kurt Roeckx via dev-security-policy
Sent: Thursday, June 8, 2017 6:40 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On 2017-06-08 14:09, wiz...@ida.net wrote:
> But Censys lists it as a trusted intermediate chaining to a root (
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:
> https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a
> 9ef1aa5baa9cc64b38b6c01ca/validation

I got confused by crt.sh, it's not obvious if a certificate is in some root
store or not. They have an other certificate
for the same CA that is in the root store.

I have no idea what common implementations do when trying to validate a
chain with such certificate in the middle.

> With respect to Gerv's question: given the ample time to disclose
intermediates, and given all CAs in the program indicated that they had,
seems reasonable to immediately add undisclosed ones that are discovered to
OneCRL. Other than some breakage, as already noted, main downside would seem
to be potentially large growth in OneCRL.

I think there are 2 solutions: OneCRL or a whitelist. OneCRL is probably
easier to do, no new code would need to be written in the browser or NSS. A
whitelist would mean that that list would need to get updated regularly and
that list is probably larger.

dev-security-policy mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to