Undisclosed CA certificates

[Richard Barnes]

Dear CAs,

As you guys are working toward the June 30 deadline for disclosing
intermediate certificates in SalesForce, I thought I would share some notes
on the undisclosed certificates that we're seeing, so that you can make
sure you get them all uploaded.

Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA
certificates that have been observed in Censys scans of the Internet, and
noted which of those certificates are not in SalesForce so far.

I've posted the list here for your reference:
https://gist.github.com/bifurcation/bf994d9fc3753f78472da8233da1fe52

Note that this list is static, so if you add a certificate to SalesForce,
it won't instantly disappear from this list. But we'll try to update it
every so often as we approach June 30, and will notify this list when we do.

Cheers,
--Richard

[Peter Bowen]

When was the Salesforce data pulled? I see several in that list I
entered a while ago.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Richard Barnes]

I think it was pulled this afternoon, but I don't know if SalesForce
updates the report.

In any case, this is being provided as a guide to CA to help them make sure
they get everything, not to place blame on anyone for being on the list.
Of course, as we get closer to June 30...

[Peter Bowen]

As far as I can tell, SalesForce does not have a way to show multiple
certificates for one CA. So it is entirely possible to have all CAs
disclosed but not have all CA certificates disclosed. (Some of the
edges in the graph may not be present)

Does disclosing all CAs meet the policy or does there need to be an
update to support disclosing additional certificates?

[Wayne Thayer]

My understanding is that CAs are not to add CAs with an EKU extension that doesn't include anyEKU or serverAuth, but this list appears to include those?

Thanks,

Wayne

[Richard Barnes]

This list does include those, e.g.:
https://censys.io/certificates/376377fd1faf4b8a5b1472647a70b941039a62d74cfe99447e48616f8d63a978

I would note for completeness that a CA without any EKU extension at all
would be considered "capable of being used to issue new [SSL] certificates"
and thus required to be disclosed.

It also appears to contain name constrained certificates, which I believe
are also exempt from disclosure (assuming the meet the full definition for
Technically Constrained).
https://censys.io/certificates/4e63f142401a84f8a473d6ddee341a161fada86d3430c8c2c534536413d9db97

So this is a fairly rough first cut. I'll work with Zakir to refine it and
provide a better SNR for everyone.

[Richard Barnes]

On Wed, Apr 27, 2016 at 8:41 PM, Peter Bowen <pzb...@gmail.com> wrote:

> As far as I can tell, SalesForce does not have a way to show multiple
> certificates for one CA. So it is entirely possible to have all CAs
> disclosed but not have all CA certificates disclosed. (Some of the
> edges in the graph may not be present)
>
> Does disclosing all CAs meet the policy or does there need to be an
> update to support disclosing additional certificates?
>

Policy saith:
"""
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 Mozilla’s
CA Certificate Policy
<https://github.com/mozilla/ca-policy/blob/master/index.html> and MUST
either be *technically constrained* or be *publicly disclosed and audited*.
"""

That reads to me to say that all certificates that might be used in
building a chain to a trusted root need to be disclosed, not just one per
CA.

If our SalesForce system doesn't support multiple certs per CA, we might
have to come with a work-around until it does.

--Richard

>
> On Wed, Apr 27, 2016 at 5:19 PM, Richard Barnes <rba...@mozilla.com>
> wrote:
> > I think it was pulled this afternoon, but I don't know if SalesForce
> updates
> > the report.
> >
> > In any case, this is being provided as a guide to CA to help them make
> sure
> > they get everything, not to place blame on anyone for being on the
> list. Of
> > course, as we get closer to June 30...
> >
> > On Wed, Apr 27, 2016 at 8:17 PM, Peter Bowen <pzb...@gmail.com> wrote:
> >>
> >> When was the Salesforce data pulled? I see several in that list I
> >> entered a while ago.
> >>
> >> On Wed, Apr 27, 2016 at 5:15 PM, Richard Barnes <rba...@mozilla.com>
> >> wrote:

[Peter Bowen]

On Wed, Apr 27, 2016 at 7:36 PM, Richard Barnes <rba...@mozilla.com> wrote:
> On Wed, Apr 27, 2016 at 8:41 PM, Peter Bowen <pzb...@gmail.com> wrote:
>>
>> As far as I can tell, SalesForce does not have a way to show multiple
>> certificates for one CA. So it is entirely possible to have all CAs
>> disclosed but not have all CA certificates disclosed. (Some of the
>> edges in the graph may not be present)
>>
>> Does disclosing all CAs meet the policy or does there need to be an
>> update to support disclosing additional certificates?
>
>
> Policy saith:
> """
> 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

> Mozilla’s CA Certificate Policy and MUST either be technically constrained
> or be publicly disclosed and audited.

> """
>
> That reads to me to say that all certificates that might be used in building
> a chain to a trusted root need to be disclosed, not just one per CA.

Does this also include certificates that are revoked?

The test is something like:

(extensions:basicConstraints:CA == TRUE ||
extensions:keyUsage:keyCertSign == TRUE || extensions:keyUsage:crLSign
== TRUE) && ((NOT extensions.include(extendedKeyUsage)) ||
extensions:extendedKeyUsage.include(anyEKU) ||
extensions:extendedKeyUsage.include(serverAuth)) && notAfter >= NOW &&
(NOT TechnicallyConstrained)

> If our SalesForce system doesn't support multiple certs per CA, we might
> have to come with a work-around until it does.

Your SalesForce system seems to assume that a certificate and CA are
equal instead of treating CAs as nodes and certificates as edges in a
directed graph. I'm not sure how to best disclose additional
certificates.

[Peter Bowen]

Here is a Google Spreadsheet without the subordinates that have EKU
restrictions. I didn't match to SalesForce, so most of these are
probably already in there.

https://docs.google.com/spreadsheets/d/14lO33nW-tTN86Vq_urmI6IAIWRPZgd1KKfzvrLk5TZQ/edit?usp=sharing

On Wed, Apr 27, 2016 at 6:11 PM, Wayne Thayer <wth...@godaddy.com> wrote:
> My understanding is that CAs are not to add CAs with an EKU extension that doesn't include anyEKU or serverAuth, but this list appears to include those?
>
> Thanks,
>
> Wayne
>
>> -----Original Message-----
>> From: dev-security-policy [mailto:dev-security-policy-
>> bounces+wthayer=godad...@lists.mozilla.org] On Behalf Of Richard
>> Barnes
>> Sent: Wednesday, April 27, 2016 5:16 PM
>> To: mozilla-dev-s...@lists.mozilla.org
>> Cc: Zakir Durumeric <za...@umich.edu>
>> Subject: Undisclosed CA certificates
>>

[Dimitris Zacharopoulos]

Hi Peter,

Here is the wiki reference that states which Intermediate CAs should be
included in salesforce:

https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

I think Kathleen has captured all cases and the instructions are clear.
It should also be straightforward to script and get a perfect match of
what should be included in salesforce.


Best regards,
Dimitris.

[Rob Stradling]

On 28/04/16 01:15, Richard Barnes wrote:
> Dear CAs,
>
> As you guys are working toward the June 30 deadline for disclosing
> intermediate certificates in SalesForce, I thought I would share some notes
> on the undisclosed certificates that we're seeing, so that you can make
> sure you get them all uploaded.
>
> Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA
> certificates that have been observed in Censys scans of the Internet, and
> noted which of those certificates are not in SalesForce so far.

Also, crt.sh now regularly downloads
https://wiki.mozilla.org/CA:SubordinateCAcerts and automatically links
the audit info to the relevant CA certificates.
(Example: https://crt.sh/?id=3706739)

I'm aiming to produce an (automatically updated) list of CA certificates
that are known to CT but are not (yet) in SalesForce.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Man Ho (Certizen)]

Hi Rob,

I know that there is a discussion regarding "bits of entropy" or
"unpredictable bits" in certificate serial number. I do not familiar
with this topic, but my gut feeling is that "unpredictable bits" is
relatively subjective.

What is your definition of "bits of entropy" used in crt.sh? Could you
elaborate a bit more on how "bits of entropy" is verified?


Cheers,
Man

[Nick Lamb]

On Friday, 29 April 2016 02:22:14 UTC+1, Man Ho (Certizen) wrote:
> Hi Rob,
>
> I know that there is a discussion regarding "bits of entropy" or
> "unpredictable bits" in certificate serial number. I do not familiar
> with this topic, but my gut feeling is that "unpredictable bits" is
> relatively subjective.

Both are subjective in the sense that mathematicians have never developed, and don't expect to be able to develop a method to assure ourselves that a list of numbers, much less an individual number exhibits this property of being unpredictable. Instead we only have statistical tests, for which we can say that a list of inputs which fails the tests is too predictable.

There is an absolutely objective test, but it is negative. If anyone can predict N-bits of your next serial number then those N-bits were by definition predictable. To give a concrete example if you issued with 16 digit serial numbers, but the first 8 are YYYYMMDD from the actual date, any bad guy can predict those numbers in the next certificate, thus they don't constitute entropy / unpredictable bits, so your serial numbers have no more than 8 digits of entropy in this scenario.

In the payment industry a specification was developed in which the consortium were uncomfortable with this idea of "unpredictable" values in cryptography and so they simply defined for conformance purposes that the values should not repeat. Unsurprisingly some implementations of their specification chose to use a simple counter, meaning bad guys could in fact trivially predict the next "unpredictable" value and attack that way. We don't know for sure how much fraud was incurred as a result.

Today's public key systems rely extensively on cryptographically secure random numbers and on statistical rather than absolute assurances already, so this is not really new territory, even aside from the BRs having previously required 20-bits and Microsoft requiring 64-bits.

> What is your definition of "bits of entropy" used in crt.sh? Could you
> elaborate a bit more on how "bits of entropy" is verified?

I'm sure Rob can give a more technical answer, but my understanding is that crt.sh doesn't (and probably can't) detect that individual certificates have enough entropy, instead it flags certificates based on the length of the serial numbers. So it's neither sufficient nor necessary that every certificate from an issuer should pass the test in crt.sh, but it is very suspicious if many or all certificates from a particular issuer fail this test.

[Kurt Roeckx]

On 2016-04-29 09:42, Nick Lamb wrote:
>
> I'm sure Rob can give a more technical answer, but my understanding is that crt.sh doesn't (and probably can't) detect that individual certificates have enough entropy, instead it flags certificates based on the length of the serial numbers. So it's neither sufficient nor necessary that every certificate from an issuer should pass the test in crt.sh, but it is very suspicious if many or all certificates from a particular issuer fail this test.

I think it's the output of certlint that gives that. My understanding
is that it gives that warning when the serial is not long enough. If
it's 56 bit instead of 64 bit, there is only a 1/256 chance that that
certificate has 64 bit random bits. If all certificates only have 56
bit, the chance that it has 64 unpredictable bits approaches 0 very fast.

The current BRs talk about 20 bit entropy instead. You really need to
check that over multiple certificates and can then calculate something
like the Shannon entropy or min entropy.


Kurt

[Rob Stradling]

On 29/04/16 09:24, Kurt Roeckx wrote:
> On 2016-04-29 09:42, Nick Lamb wrote:
>>

>> I'm sure Rob can give a more technical answer, but my understanding is
>> that crt.sh doesn't (and probably can't) detect that individual
>> certificates have enough entropy, instead it flags certificates based
>> on the length of the serial numbers. So it's neither sufficient nor
>> necessary that every certificate from an issuer should pass the test
>> in crt.sh, but it is very suspicious if many or all certificates from
>> a particular issuer fail this test.
>

> I think it's the output of certlint that gives that.

Yes. e.g. https://crt.sh/?cablint=38

> My understanding
> is that it gives that warning when the serial is not long enough.

Seems so. See
https://github.com/awslabs/certlint/blob/master/lib/certlint/cablint.rb#L69

> If it's 56 bit instead of 64 bit, there is only a 1/256 chance that that
> certificate has 64 bit random bits. If all certificates only have 56
> bit, the chance that it has 64 unpredictable bits approaches 0 very fast.
>
> The current BRs talk about 20 bit entropy instead. You really need to
> check that over multiple certificates and can then calculate something
> like the Shannon entropy or min entropy.

[Man Ho (Certizen)]

Thanks. I see. It's by the best effort approach.

[Matt Palmer]

On Fri, Apr 29, 2016 at 12:42:28AM -0700, Nick Lamb wrote:
> There is an absolutely objective test, but it is negative. If anyone can
> predict N-bits of your next serial number then those N-bits were by
> definition predictable. To give a concrete example if you issued with 16
> digit serial numbers, but the first 8 are YYYYMMDD from the actual date,
> any bad guy can predict those numbers in the next certificate, thus they
> don't constitute entropy / unpredictable bits, so your serial numbers have
> no more than 8 digits of entropy in this scenario.

Even more fun: what if the serial number is MD5(YYYYMMDDHHmmss)? In that
case, comparing two serial numbers makes them all *look* awesomely random,
until someone figures out "the secret", at which point pretty much all the
bits are predictable, even though there's no "obvious" pattern from
examining the serials themselves.

- Matt

[Peter Bowen]

What if the serial number is HMAC-MD5(SecretStaticKey,
YYYYMMDDHHmmss)? Or AES encryption of the timestamp?

This is why there are human auditors. They can ask the CA how they
are generating the serial numbers. That is the only way that this can
every be verified.

Thanks,
Peter

[Matt Palmer]

Yes, that's my point. It is entirely pointless to examine the sausages once
they're sitting on the shelf.

- Matt

[Peter Bowen]

Think about it more like home inspectors. The can tell you if
something is wrong but cannot guarantee it is right.

https://crt.sh/?Identity=%25&iCAID=535 is an example of either the
worst RNG ever or not using a RNG. I'd say that is wrong.

[Eric Mill]

On Fri, Apr 29, 2016 at 8:12 PM, Peter Bowen <pzb...@gmail.com> wrote:

> On Fri, Apr 29, 2016 at 5:03 PM, Matt Palmer <mpa...@hezmatt.org> wrote:

> > On Fri, Apr 29, 2016 at 12:42:28AM -0700, Nick Lamb wrote:
> >> There is an absolutely objective test, but it is negative. If anyone can
> >> predict N-bits of your next serial number then those N-bits were by
> >> definition predictable. To give a concrete example if you issued with
> 16
> >> digit serial numbers, but the first 8 are YYYYMMDD from the actual date,
> >> any bad guy can predict those numbers in the next certificate, thus they
> >> don't constitute entropy / unpredictable bits, so your serial numbers
> have
> >> no more than 8 digits of entropy in this scenario.
> >

> > Even more fun: what if the serial number is MD5(YYYYMMDDHHmmss)? In that
> > case, comparing two serial numbers makes them all *look* awesomely
> random,
> > until someone figures out "the secret", at which point pretty much all
> the
> > bits are predictable, even though there's no "obvious" pattern from
> > examining the serials themselves.
>
> What if the serial number is HMAC-MD5(SecretStaticKey,
> YYYYMMDDHHmmss)? Or AES encryption of the timestamp?
>
> This is why there are human auditors. They can ask the CA how they
> are generating the serial numbers. That is the only way that this can
> every be verified.
>

Or a CA could release this part of their infrastructure as open source (or
at least publicly disclosed), and have the auditor attest that the code
used in production is the code in public version control. That would make
it so the community, not just the auditor, could evaluate of the strength
of the methods the CA uses to manage entropy while being assured that
they're evaluating the actual production code.

-- Eric


>
> Thanks,
> Peter

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[Roland Shoemaker]

This assumes the use of a software RNG that can be open sourced. Many
CAs may be using a hardware source of randomness, such as a HSM, which
runs proprietary code they do not hold the license to.

[Eric Mill]

I understand that, but I would assume that the choice of what to ask the
HSM to do would be in the CA's own software. This was the question I was
responding to:

> What if the serial number is HMAC-MD5(SecretStaticKey, YYYYMMDDHHmmss)?
Or AES encryption of the timestamp?

That seems like CA-land code. In Let's Encrypt's boulder, it looks like the
answer is here:

https://github.com/letsencrypt/boulder/blob/b7cf618f5d228ba2699e09cc4a65888d61654b19/ca/certificate-authority.go#L499-L512

-- Eric

On Sat, Apr 30, 2016 at 5:34 PM, Roland Shoemaker <rol...@letsencrypt.org>
wrote:

[Roland Shoemaker]

Ah yes, that is true. It is still the case though that a CA could be
calling out to some third party library or such they are not at liberty
to disclose.

Another thing to point out is that defining the structure that strictly
(i.e. MUST be a HMAC of something) would prevent a number of CAs from
storing various other structure within the serial (including Let's
Encrypt, in the code you linked we append our '8-bit instance id prefix'
to define from which instance a certificate was issued).

It seems the best solution to this problem is to simply remove the use
of entropy and require that N number of bits in the serial were
generated using a CSPRNG. The term is relatively well defined such that
an auditor (or other party) should be able to determine if a CA is
complying given the process by which they generate the required bits.

["Barreira Iglesias, Iñigo"]

Yes, that´s true, there´s no RNG at all, they are sequential numbers. Once the CABF has decided what to do regarding this issue we´ll change accordingly.


Iñigo Barreira
Responsable del Área técnica
i-bar...@izenpe.eus
945067705



ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.


-----Mensaje original-----
De: dev-security-policy [mailto:dev-security-policy-bounces+i-barreira=izenp...@lists.mozilla.org] En nombre de Peter Bowen
Enviado el: sábado, 30 de abril de 2016 4:50
Para: Matt Palmer
CC: mozilla-dev-s...@lists.mozilla.org
Asunto: Re: Undisclosed CA certificates

On Fri, Apr 29, 2016 at 7:17 PM, Matt Palmer <mpa...@hezmatt.org> wrote:

> On Fri, Apr 29, 2016 at 05:12:28PM -0700, Peter Bowen wrote:
>> On Fri, Apr 29, 2016 at 5:03 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
>> > Even more fun: what if the serial number is MD5(YYYYMMDDHHmmss)?
>> > In that case, comparing two serial numbers makes them all *look*
>> > awesomely random, until someone figures out "the secret", at which
>> > point pretty much all the bits are predictable, even though there's
>> > no "obvious" pattern from examining the serials themselves.
>>
>> What if the serial number is HMAC-MD5(SecretStaticKey,
>> YYYYMMDDHHmmss)? Or AES encryption of the timestamp?
>>
>> This is why there are human auditors. They can ask the CA how they
>> are generating the serial numbers. That is the only way that this
>> can every be verified.
>

> Yes, that's my point. It is entirely pointless to examine the
> sausages once they're sitting on the shelf.

Think about it more like home inspectors. The can tell you if something is wrong but cannot guarantee it is right.

https://crt.sh/?Identity=%25&iCAID=535 is an example of either the worst RNG ever or not using a RNG. I'd say that is wrong.

["Barreira Iglesias, Iñigo"]

Is there any updated list? This one is from 27/4. We disclosed our CAs before that date and are included in the list.

Iñigo Barreira
Responsable del Área técnica
i-bar...@izenpe.eus
945067705



ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.


-----Mensaje original-----

De: dev-security-policy [mailto:dev-security-policy-bounces+i-barreira=izenp...@lists.mozilla.org] En nombre de Richard Barnes
Enviado el: jueves, 28 de abril de 2016 2:16
Para: mozilla-dev-s...@lists.mozilla.org
CC: Zakir Durumeric
Asunto: Undisclosed CA certificates

Dear CAs,

As you guys are working toward the June 30 deadline for disclosing intermediate certificates in SalesForce, I thought I would share some notes on the undisclosed certificates that we're seeing, so that you can make sure you get them all uploaded.

Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA certificates that have been observed in Censys scans of the Internet, and noted which of those certificates are not in SalesForce so far.

I've posted the list here for your reference:
https://gist.github.com/bifurcation/bf994d9fc3753f78472da8233da1fe52

Note that this list is static, so if you add a certificate to SalesForce, it won't instantly disappear from this list. But we'll try to update it every so often as we approach June 30, and will notify this list when we do.

Cheers,
--Richard

[Ben Laurie]

On 28 April 2016 at 12:31, Rob Stradling <rob.st...@comodo.com> wrote:
> On 28/04/16 01:15, Richard Barnes wrote:
>>

>> Dear CAs,
>>
>> As you guys are working toward the June 30 deadline for disclosing
>> intermediate certificates in SalesForce, I thought I would share some
>> notes
>> on the undisclosed certificates that we're seeing, so that you can make
>> sure you get them all uploaded.
>>
>> Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA
>> certificates that have been observed in Censys scans of the Internet, and
>> noted which of those certificates are not in SalesForce so far.
>
>

> Also, crt.sh now regularly downloads
> https://wiki.mozilla.org/CA:SubordinateCAcerts and automatically links the
> audit info to the relevant CA certificates.
> (Example: https://crt.sh/?id=3706739)
>
> I'm aiming to produce an (automatically updated) list of CA certificates
> that are known to CT but are not (yet) in SalesForce.

FWIW, we've recently changed how we preload chains, and as a result
more intermediates should be logged in Google's logs, at least.

[Rob Stradling]

On 04/05/16 11:35, Ben Laurie wrote:
> On 28 April 2016 at 12:31, Rob Stradling <rob.st...@comodo.com> wrote:
>> On 28/04/16 01:15, Richard Barnes wrote:
>>>
>>> Dear CAs,
>>>
>>> As you guys are working toward the June 30 deadline for disclosing
>>> intermediate certificates in SalesForce, I thought I would share some
>>> notes
>>> on the undisclosed certificates that we're seeing, so that you can make
>>> sure you get them all uploaded.
>>>
>>> Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA
>>> certificates that have been observed in Censys scans of the Internet, and
>>> noted which of those certificates are not in SalesForce so far.
>>
>>
>> Also, crt.sh now regularly downloads
>> https://wiki.mozilla.org/CA:SubordinateCAcerts and automatically links the
>> audit info to the relevant CA certificates.
>> (Example: https://crt.sh/?id=3706739)
>>
>> I'm aiming to produce an (automatically updated) list of CA certificates
>> that are known to CT but are not (yet) in SalesForce.

As promised, here it is...

https://crt.sh/mozilla-disclosures

Updates made in SalesForce should be reflected on this page within 10
minutes or so.

> FWIW, we've recently changed how we preload chains, and as a result
> more intermediates should be logged in Google's logs, at least.

Excellent. :-)

[Rob Stradling]

Hi Iñigo.

Does https://crt.sh/mozilla-disclosures show what you'd expect to see
for your CAs?

On 04/05/16 09:58, "Barreira Iglesias, Iñigo" wrote:
> Is there any updated list? This one is from 27/4. We disclosed our CAs before that date and are included in the list.
>
>
> Iñigo Barreira
> Responsable del Área técnica
> i-bar...@izenpe.eus
> 945067705
>
>
>
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.
>
>
> -----Mensaje original-----
> De: dev-security-policy [mailto:dev-security-policy-bounces+i-barreira=izenp...@lists.mozilla.org] En nombre de Richard Barnes
> Enviado el: jueves, 28 de abril de 2016 2:16
> Para: mozilla-dev-s...@lists.mozilla.org
> CC: Zakir Durumeric
> Asunto: Undisclosed CA certificates
>

> Dear CAs,
>
> As you guys are working toward the June 30 deadline for disclosing intermediate certificates in SalesForce, I thought I would share some notes on the undisclosed certificates that we're seeing, so that you can make sure you get them all uploaded.
>
> Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA certificates that have been observed in Censys scans of the Internet, and noted which of those certificates are not in SalesForce so far.
>

> I've posted the list here for your reference:
> https://gist.github.com/bifurcation/bf994d9fc3753f78472da8233da1fe52
>
> Note that this list is static, so if you add a certificate to SalesForce, it won't instantly disappear from this list. But we'll try to update it every so often as we approach June 30, and will notify this list when we do.
>
> Cheers,
> --Richard
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

["Barreira Iglesias, Iñigo"]

Thanks Rob, now it´s clearer.

Iñigo Barreira
Responsable del Área técnica
i-bar...@izenpe.eus
945067705



ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.


-----Mensaje original-----

De: Rob Stradling [mailto:rob.st...@comodo.com]
Enviado el: miércoles, 04 de mayo de 2016 13:09
Para: Barreira Iglesias, Iñigo
CC: Richard Barnes; mozilla-dev-s...@lists.mozilla.org; Zakir Durumeric

Asunto: Re: Undisclosed CA certificates

[Nick Lamb]

On Wednesday, 4 May 2016 12:07:01 UTC+1, Rob Stradling wrote:
> As promised, here it is...
>
> https://crt.sh/mozilla-disclosures

Thanks so much Rob, I have written previously in praise of tools that "take something people already knew was a good idea and automate the boring parts". This is definitely another such tool. Mozilla's effort to get CAs to identify their intermediates in Salesforce so that its users can have all the facts before making trust decisions was valuable on its own, but with a tool like this it can be that much more searching and comprehensive.

[Nick Lamb]

I can see that Rob's new tool is still under active development, and probably some of what I mention below is already on his TODO list. Please consider this no more than a couple of friendly suggestions Rob

* As I understand it, implementations do examine the notBefore / notAfter in intermediate certificates so they really expire. Undisclosed but expired intermediate certificates might still be interesting to researchers but they probably deserve their own category?

e.g. https://crt.sh/?sha1=c1b471f0fd9220f4d77f128b423fc5c9e688476e expired some years ago as far as I can see but is currently on the "should disclose" list.

* With lots of similar, long tables on a page it can be hard to be sure what you're looking at after scrolling or searching. Setting a different pastel CSS background for each of the tables, and using the same colours in the summary table at the top could signal which table you're looking at without being a lot of work to implement. Fancier solutions exist of course.

[Rob Stradling]

On 04/05/16 20:13, Nick Lamb wrote:
> I can see that Rob's new tool is still under active development, and probably some of what I mention below is already on his TODO list. Please consider this no more than a couple of friendly suggestions Rob

Thanks Nick. All suggestions welcome. :-)

> * As I understand it, implementations do examine the notBefore / notAfter in intermediate certificates so they really expire. Undisclosed but expired intermediate certificates might still be interesting to researchers but they probably deserve their own category?

My reading of the Mozilla CA Policy and the March 2016 CA Communication
is that expired intermediate certificates must be disclosed to Mozilla.

> e.g. https://crt.sh/?sha1=c1b471f0fd9220f4d77f128b423fc5c9e688476e expired some years ago as far as I can see but is currently on the "should disclose" list.
>
> * With lots of similar, long tables on a page it can be hard to be sure what you're looking at after scrolling or searching. Setting a different pastel CSS background for each of the tables, and using the same colours in the summary table at the top could signal which table you're looking at without being a lot of work to implement. Fancier solutions exist of course.

I'll tweak the colours.

(Fancier solutions are probably out of reach given my meagre webdev
skills ;-) ).

[Richard Barnes]

On Wed, May 4, 2016 at 4:33 PM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 04/05/16 20:13, Nick Lamb wrote:
>
>> I can see that Rob's new tool is still under active development, and
>> probably some of what I mention below is already on his TODO list. Please
>> consider this no more than a couple of friendly suggestions Rob
>>
>
> Thanks Nick. All suggestions welcome. :-)
>
> * As I understand it, implementations do examine the notBefore / notAfter
>> in intermediate certificates so they really expire. Undisclosed but expired
>> intermediate certificates might still be interesting to researchers but
>> they probably deserve their own category?
>>
>
> My reading of the Mozilla CA Policy and the March 2016 CA Communication is
> that expired intermediate certificates must be disclosed to Mozilla.
>

The policy assigns the disclosure requirement to "All certificates that are
capable of being used to issue new certificates". Doesn't that exclude
expired?

--Richard

> e.g. https://crt.sh/?sha1=c1b471f0fd9220f4d77f128b423fc5c9e688476e
>> expired some years ago as far as I can see but is currently on the "should
>> disclose" list.
>>
>> * With lots of similar, long tables on a page it can be hard to be sure
>> what you're looking at after scrolling or searching. Setting a different
>> pastel CSS background for each of the tables, and using the same colours in
>> the summary table at the top could signal which table you're looking at
>> without being a lot of work to implement. Fancier solutions exist of course.
>>
>
> I'll tweak the colours.
>
> (Fancier solutions are probably out of reach given my meagre webdev skills
> ;-) ).
>

> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

[Rob Stradling]

On 04/05/16 22:13, Richard Barnes wrote:
> On Wed, May 4, 2016 at 4:33 PM, Rob Stradling wrote:
<snip>

> My reading of the Mozilla CA Policy and the March 2016 CA
> Communication is that expired intermediate certificates must be
> disclosed to Mozilla.
>
> The policy assigns the disclosure requirement to "All certificates that
> are capable of being used to issue new certificates". Doesn't that
> exclude expired?

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
provides this definition:
"8. A certificate is deemed as capable of being used to issue new
certificates if it contains an X.509v3 basicConstraints extension, with
the cA boolean set to true."

There's no mention of expired certs being excluded AFAICT.

> --Richard
>
>
>
> e.g.
> https://crt.sh/?sha1=c1b471f0fd9220f4d77f128b423fc5c9e688476e
> expired some years ago as far as I can see but is currently on
> the "should disclose" list.
>
> * With lots of similar, long tables on a page it can be hard to
> be sure what you're looking at after scrolling or searching.
> Setting a different pastel CSS background for each of the
> tables, and using the same colours in the summary table at the
> top could signal which table you're looking at without being a
> lot of work to implement. Fancier solutions exist of course.
>
>
> I'll tweak the colours.
>
> (Fancier solutions are probably out of reach given my meagre webdev
> skills ;-) ).

[Dimitris Zacharopoulos]

> On 5 Μαΐ 2016, at 00:18, Rob Stradling <rob.st...@comodo.com> wrote:
>
>> On 04/05/16 22:13, Richard Barnes wrote:
>> On Wed, May 4, 2016 at 4:33 PM, Rob Stradling wrote:
> <snip>
>> My reading of the Mozilla CA Policy and the March 2016 CA
>> Communication is that expired intermediate certificates must be
>> disclosed to Mozilla.
>>
>> The policy assigns the disclosure requirement to "All certificates that
>> are capable of being used to issue new certificates". Doesn't that
>> exclude expired?
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ provides this definition:
> "8. A certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true."
>
> There's no mention of expired certs being excluded AFAICT.

https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

The above link clarifies that

CAs should not add records for:
Expired intermediate certificates

It seems a bit conflicting but it is more recent and very specific to salesforce.


Dimitris.

>
>> --Richard
>>
>>
>>
>> e.g.
>> https://crt.sh/?sha1=c1b471f0fd9220f4d77f128b423fc5c9e688476e
>> expired some years ago as far as I can see but is currently on
>> the "should disclose" list.
>>
>> * With lots of similar, long tables on a page it can be hard to
>> be sure what you're looking at after scrolling or searching.
>> Setting a different pastel CSS background for each of the
>> tables, and using the same colours in the summary table at the
>> top could signal which table you're looking at without being a
>> lot of work to implement. Fancier solutions exist of course.
>>
>>
>> I'll tweak the colours.
>>
>> (Fancier solutions are probably out of reach given my meagre webdev
>> skills ;-) ).
>

> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

[Richard Barnes]

On Wed, May 4, 2016 at 5:41 PM, Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

>
>
>
> On 5 Μαΐ 2016, at 00:18, Rob Stradling <rob.st...@comodo.com> wrote:
>
> On 04/05/16 22:13, Richard Barnes wrote:
>
> On Wed, May 4, 2016 at 4:33 PM, Rob Stradling wrote:
>
> <snip>
>
> My reading of the Mozilla CA Policy and the March 2016 CA
>
> Communication is that expired intermediate certificates must be
>
> disclosed to Mozilla.
>
>
> The policy assigns the disclosure requirement to "All certificates that
>
> are capable of being used to issue new certificates". Doesn't that
>
> exclude expired?
>
>
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> provides this definition:
> "8. A certificate is deemed as capable of being used to issue new
> certificates if it contains an X.509v3 basicConstraints extension, with the
> cA boolean set to true."
>
> There's no mention of expired certs being excluded AFAICT.
>
>
>
> https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
>
> The above link clarifies that
>
>

> - CAs should *not* add records for:
> - Expired intermediate certificates

>
>
> It seems a bit conflicting but it is more recent and very specific to
> salesforce.
>

This is perhaps something we should clarify in the policy.

--Richard

>
>
> Dimitris.
>
>
>
> --Richard
>
>
>
>
> e.g.
>
> https://crt.sh/?sha1=c1b471f0fd9220f4d77f128b423fc5c9e688476e
>
> expired some years ago as far as I can see but is currently on
>
> the "should disclose" list.
>
>
> * With lots of similar, long tables on a page it can be hard to
>
> be sure what you're looking at after scrolling or searching.
>
> Setting a different pastel CSS background for each of the
>
> tables, and using the same colours in the summary table at the
>
> top could signal which table you're looking at without being a
>
> lot of work to implement. Fancier solutions exist of course.
>
>
>
> I'll tweak the colours.
>
>
> (Fancier solutions are probably out of reach given my meagre webdev
>
> skills ;-) ).
>
>

> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

[Rob Stradling]

On 04/05/16 22:42, Richard Barnes wrote:
> On Wed, May 4, 2016 at 5:41 PM, Dimitris Zacharopoulos wrote:
<snip>

> https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
>
> The above link clarifies that
>

> * CAs should *not* add records for:
> o Expired intermediate certificates

>
>
> It seems a bit conflicting but it is more recent and very specific
> to salesforce.

Thanks for pointing that out.

> This is perhaps something we should clarify in the policy.

Good idea.

https://crt.sh/mozilla-disclosures now groups expired intermediate certs
with untrusted intermediate certs. Colours added too.

> --Richard
>
>
>
>
>
> Dimitris.
>
>
>>
>>> --Richard
>>>
>>>
>>>
>>> e.g.
>>> https://crt.sh/?sha1=c1b471f0fd9220f4d77f128b423fc5c9e688476e
>>> expired some years ago as far as I can see but is currently on
>>> the "should disclose" list.
>>>
>>> * With lots of similar, long tables on a page it can be
>>> hard to
>>> be sure what you're looking at after scrolling or searching.
>>> Setting a different pastel CSS background for each of the
>>> tables, and using the same colours in the summary table at the
>>> top could signal which table you're looking at without being a
>>> lot of work to implement. Fancier solutions exist of course.
>>>
>>>
>>> I'll tweak the colours.
>>>
>>> (Fancier solutions are probably out of reach given my meagre
>>> webdev
>>> skills ;-) ).
>>

>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online

>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org

>> <mailto:dev-secur...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-security-policy

>
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Rob Stradling]

On 04/05/16 23:05, Rob Stradling wrote:
> On 04/05/16 22:42, Richard Barnes wrote:
>> On Wed, May 4, 2016 at 5:41 PM, Dimitris Zacharopoulos wrote:
> <snip>
>>
>> https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
>>
>>
>> The above link clarifies that
>>
>> * CAs should *not* add records for:
>> o Expired intermediate certificates
>>
>>
>> It seems a bit conflicting but it is more recent and very specific
>> to salesforce.
>
> Thanks for pointing that out.
>
>> This is perhaps something we should clarify in the policy.
>
> Good idea.

Kathleen,

Please would you add a note about this to...
https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3
?

Thanks.

[Nick Lamb]

On Wednesday, 4 May 2016 21:34:28 UTC+1, Rob Stradling wrote:
> Thanks Nick. All suggestions welcome. :-)

Not so much a suggestion this time as a potential bug report

"Let's Encrypt Authority X2" appears twice in the table, both times it is listed with the DST Root CA X3 issuer. However it seems to me that only one of the two certificates for "Let's Encrypt Authority X2" is actually from that issuer, the other is from ISRG's own root, which is not yet trusted (there's another thread adjacent to this one discussing its inclusion of course).

I presume there's some confusion somewhere which has muddled these two certificates together ? The result seems to be not only that they're listed wrongly, but also some certificates appear in the wrong table, as (for now) ISRG issued certificates are not trusted by NSS.

[Rob Stradling]

RFC5280 says (emphasis mine)...
"4.2.1.10. Name Constraints
The name constraints extension, which MUST be used only in a CA
certificate, indicates a name space within which all subject names in
*subsequent certificates in a certification path* MUST be located."

The Mozilla CA Policy says...
"For a certificate to be considered technically constrained, the
certificate MUST include an Extended Key Usage (EKU) extension
specifying all extended key usages that the subordinate CA is
authorized to issue certificates for...
If the certificate includes the id-kp-serverAuth extended key usage,
then the certificate MUST include the Name Constraints X.509v3
extension with constraints on both dNSName and iPAddress."
(BRs Section 7.1.5 contains the same requirements)


Consider a certificate chain of this form:
Root
Intermediate 1 (contains Name Constraints / EKU)
Intermediate 2 (does not contain Name Constraints / EKU)
End-entity

In fact, here's a real example:
Root: https://crt.sh/?id=1
Intermediate 1: https://crt.sh/?id=1250505
Intermediate 2: https://crt.sh/?id=1250506
End-entity certs: https://crt.sh/?Identity=%25&iCAID=1188


As per RFC5280, certificate path processing software imposes
Intermediate 1's name constraints upon Intermediate 2, because name
constraints flow down to "subsequent certificates in a certification path".

Similarly, (IINM) NSS treats the EKU extension in an intermediate
certificate as a constraint on the permitted EKUs in "subsequent
certificates in a certification path". (This is arguably an abuse of
RFC5280, but let's not revisit that argument yet again).


Since Intermediate 2 is effectively technically constrained, you might
imagine that it should be exempt from the disclosure requirement.
However, the "certificate MUST include...extension" language in both the
Mozilla CA Policy and the BRs seems to clearly state that:
- Intermediate 1 need not be disclosed.
- Intermediate 2 MUST be disclosed.

Anyone disagree with my interpretation?

[Rob Stradling]

On 05/05/16 10:32, Nick Lamb wrote:
> On Wednesday, 4 May 2016 21:34:28 UTC+1, Rob Stradling wrote:

>> Thanks Nick. All suggestions welcome. :-)
>

> Not so much a suggestion this time as a potential bug report

Potential bug reports are also very welcome. :-)

> "Let's Encrypt Authority X2" appears twice in the table, both times it is listed with the DST Root CA X3 issuer. However it seems to me that only one of the two certificates for "Let's Encrypt Authority X2" is actually from that issuer, the other is from ISRG's own root, which is not yet trusted (there's another thread adjacent to this one discussing its inclusion of course).
>
> I presume there's some confusion somewhere which has muddled these two certificates together ? The result seems to be not only that they're listed wrongly, but also some certificates appear in the wrong table, as (for now) ISRG issued certificates are not trusted by NSS.

I agree that this is a bug.

Those two "Let's Encrypt Authority X2" intermediates belong to the same
CA - that is, they share the same Subject Name/Key (see
https://crt.sh/?caid=9745).

The complexities of cross-signing strike yet again. I can almost hear
the collective groan from the NSS developers... ;-).

[Rob Stradling]

On 05/05/16 11:10, Rob Stradling wrote:
> On 05/05/16 10:32, Nick Lamb wrote:
>> On Wednesday, 4 May 2016 21:34:28 UTC+1, Rob Stradling wrote:

>>> Thanks Nick. All suggestions welcome. :-)
>>

>> Not so much a suggestion this time as a potential bug report
>
> Potential bug reports are also very welcome. :-)
>
>> "Let's Encrypt Authority X2" appears twice in the table, both times it
>> is listed with the DST Root CA X3 issuer. However it seems to me that
>> only one of the two certificates for "Let's Encrypt Authority X2" is
>> actually from that issuer, the other is from ISRG's own root, which is
>> not yet trusted (there's another thread adjacent to this one
>> discussing its inclusion of course).
>>
>> I presume there's some confusion somewhere which has muddled these two
>> certificates together ? The result seems to be not only that they're
>> listed wrongly, but also some certificates appear in the wrong table,
>> as (for now) ISRG issued certificates are not trusted by NSS.
>
> I agree that this is a bug.

I've fixed it.

> Those two "Let's Encrypt Authority X2" intermediates belong to the same
> CA - that is, they share the same Subject Name/Key (see
> https://crt.sh/?caid=9745).
>
> The complexities of cross-signing strike yet again. I can almost hear
> the collective groan from the NSS developers... ;-).

[Kurt Roeckx]

I would agree, since you can't be sure that there isn't an
alternative for Intermediate 1 that doesn't have the constraints.


Kurt

[Rob Stradling]

On 05/05/16 10:57, Rob Stradling wrote:
<snip>

> Consider a certificate chain of this form:
> Root
> Intermediate 1 (contains Name Constraints / EKU)
> Intermediate 2 (does not contain Name Constraints / EKU)
> End-entity

<snip>

> Since Intermediate 2 is effectively technically constrained, you might
> imagine that it should be exempt from the disclosure requirement.
> However, the "certificate MUST include...extension" language in both the
> Mozilla CA Policy and the BRs seems to clearly state that:
> - Intermediate 1 need not be disclosed.
> - Intermediate 2 MUST be disclosed.

Similarly, consider a certificate chain that is technically constrained
using EKU alone:

Root (with "websites" trust bit enabled)
Intermediate 1 (contains EKU with one OID: id-kp-clientAuth)
Intermediate 2 (does not contain EKU)
End-entity

Again, ISTM that Intermediate 2 MUST be disclosed (as per policy) even
though NSS/Firefox would not trust serverAuth certs issued by it.


(Note: https://crt.sh/mozilla-disclosures currently classifies
Intermediate 2 as "Technically Constrained (id-kp-serverAuth ∉ EKU", but
I'm wondering if I should change that to match my understanding of the
policy).

[Rob Stradling]

On 05/05/16 12:50, Kurt Roeckx wrote:
<snip>
>> Since Intermediate 2 is effectively technically constrained, you might
>> imagine that it should be exempt from the disclosure requirement. However,
>> the "certificate MUST include...extension" language in both the Mozilla CA
>> Policy and the BRs seems to clearly state that:
>> - Intermediate 1 need not be disclosed.
>> - Intermediate 2 MUST be disclosed.
>>

>> Anyone disagree with my interpretation?
>
> I would agree, since you can't be sure that there isn't an
> alternative for Intermediate 1 that doesn't have the constraints.

That logic would imply that all of the "Not Trusted by Mozilla"
intermediates should be moved to "Disclosure required!", given that I
can't prove the non-existence of cross-certificates that would cause
these intermediates to become trusted!

AIUI, Mozilla are only requiring disclosure when a
trusted-and-unconstrained path does exist. This is indeed something I
cannot be sure of (except, as it happens, for intermediates under
Comodo's roots), but it is something that each CA should be capable of
being sure of.

https://crt.sh/mozilla-disclosures isn't a complete and authoritative
list. It attempts to avoid false positives and only deal with "known
knowns".

[Peter Bowen]

On Thu, May 5, 2016 at 2:57 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> RFC5280 says (emphasis mine)...
> "4.2.1.10. Name Constraints
> The name constraints extension, which MUST be used only in a CA
> certificate, indicates a name space within which all subject names in
> *subsequent certificates in a certification path* MUST be located."
>
> The Mozilla CA Policy says...
> "For a certificate to be considered technically constrained, the
> certificate MUST include an Extended Key Usage (EKU) extension
> specifying all extended key usages that the subordinate CA is
> authorized to issue certificates for...
> If the certificate includes the id-kp-serverAuth extended key usage,
> then the certificate MUST include the Name Constraints X.509v3
> extension with constraints on both dNSName and iPAddress."
> (BRs Section 7.1.5 contains the same requirements)
>
>

> Consider a certificate chain of this form:
> Root
> Intermediate 1 (contains Name Constraints / EKU)
> Intermediate 2 (does not contain Name Constraints / EKU)
> End-entity
>

> In fact, here's a real example:
> Root: https://crt.sh/?id=1
> Intermediate 1: https://crt.sh/?id=1250505
> Intermediate 2: https://crt.sh/?id=1250506
> End-entity certs: https://crt.sh/?Identity=%25&iCAID=1188
>
>
> As per RFC5280, certificate path processing software imposes Intermediate
> 1's name constraints upon Intermediate 2, because name constraints flow down
> to "subsequent certificates in a certification path".
>
> Similarly, (IINM) NSS treats the EKU extension in an intermediate
> certificate as a constraint on the permitted EKUs in "subsequent
> certificates in a certification path". (This is arguably an abuse of
> RFC5280, but let's not revisit that argument yet again).
>
>

> Since Intermediate 2 is effectively technically constrained, you might
> imagine that it should be exempt from the disclosure requirement. However,
> the "certificate MUST include...extension" language in both the Mozilla CA
> Policy and the BRs seems to clearly state that:
> - Intermediate 1 need not be disclosed.
> - Intermediate 2 MUST be disclosed.
>
> Anyone disagree with my interpretation?

I will disagree. I think the intent is to "prune" the tree once either
a technical constraint is hit or when the set of allowed key purposes
ceases to include serverAuth. I also think that path length
constraints should be taken in to account.

That being said, because multiple cross-certificates can exist with
the same subject, it is possible that one path would be pruned but
there is another path that is unconstrained, which would result in
disclosure being required.

Thanks,
Peter

[Richard Barnes]

Oh, if only it were a tree, and not a DAG. Well, *hopefully* acyclic.

> once either
> a technical constraint is hit or when the set of allowed key purposes
> ceases to include serverAuth. I also think that path length
> constraints should be taken in to account.
>
> That being said, because multiple cross-certificates can exist with
> the same subject, it is possible that one path would be pruned but
> there is another path that is unconstrained, which would result in
> disclosure being required.
>

Let's label the alternative policies here as C (for "cert") and CoAP (for
"cert-or-all-parents"), according to what must be constrained.

I appreciate the desire to bound disclosure here. CoAP does result in a
lower disclosure burden for CAs. However, I have two major concerns about
it:

1. You need global state to evaluate it. Evaluating the disclosure
requirement for a certificate requires that you evaluate a "not exists"
qualfiier -- "there does not exist a certification path that is not
constrained". You can't do that unless you know all possible
cross-certifications. That might sound feasible for the CA itself, but for
a third party like an auditor or a relying party (e.g., Mozilla), it's
pretty daunting. The only way that could possibly be practical is if the
universe of CAs were explicitly bounded, i.e., there were a whitelist of
subordinate CAs.

2. It leads to bad operational scenarios. With C, a CA knows when they
create the subordinate CA certificate whether it needs to be disclosed or
not. With CoAP, a subordinate CA can suddenly become unconstrained, if any
of their parents gets an un-constrained cross-signature. This would
require them to go through all the expense and complexity of audits on
short notice.

I appreciate that both of the proposed policies are well-formed. But given
the above, I would have a hard tiem finding CoAP practical.

--Richard




>
> Thanks,
> Peter

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Peter Bowen]

> On May 5, 2016, at 6:50 AM, Richard Barnes <rba...@mozilla.com> wrote:
>
> On Thu, May 5, 2016 at 8:32 AM, Peter Bowen <pzb...@gmail.com> wrote:
>>
>> I will disagree. I think the intent is to "prune" the tree
>
>
> Oh, if only it were a tree, and not a DAG. Well, *hopefully* acyclic.

Nope, not acyclic. Already seen proof of that.

Consider the inverse.

A root CA issues a CA certificate that is technically constrained (KP=serverAuth, permittedTree=dNSName:example.com, all other forbidden). It has no path length constraint. There is no disclosure required of this certificate, by policy.

The subject of that constrained certificate issues another certificate. You propose disclosure is required of the child. But there will be no link to any root disclosed.

How does this make sense?

Thanks,
Peter

[Richard Barnes]

Well, "no link" is a little strong, since the constrained intermediate does
exist. But I grant that it is a bit odd for there to be no link in the
disclosed data set.

>
> How does this make sense?
>

It at least has the benefit of making the policy uniform: The rule "When
you create a subordinate CA certificate, you must either include technical
constraints or disclose it" could apply uniformly to all CAs in the PKI,
constrained or not.

Maybe the question here is whether the "for all" qualifier points up the
"tree" or down:
- All parents must be constrained [CoAP] to be exempt from disclosure
- All children must be constrained [C] to be exempt from disclosure

After all, you could remove the "no link" oddity above by saying that if
the constrained CA issues an unconstrained subordinate, then it must be
disclosed.

This still leaves me thinking that C is more practical, since it aligns the
"for all" qualifier with the power relationship: A subordinate can't
control what its parents do, so it can't guarantee that all its parents are
constrained. But a CA can control what its subordinates do, by revoking a
misbehaving subordinate.

--Richard



>
> Thanks,
> Peter
>
>
>

[Nick Lamb]

On Thursday, 5 May 2016 13:22:34 UTC+1, Rob Stradling wrote:
> That logic would imply that all of the "Not Trusted by Mozilla"
> intermediates should be moved to "Disclosure required!", given that I
> can't prove the non-existence of cross-certificates that would cause
> these intermediates to become trusted!

As a relying party I think the correct algorithm here is an iterative one, or at least, is best explained that way. Given the set of disclosed certificates, create a graph of CA nodes, reachable from the NSS public trust roots by following certificates that meet certain criteria. From each of those nodes, if you know of any certificates that would also meet the criteria, which are not yet disclosed, you must disclose them. Repeat until nobody discloses any more certificates and thus the graph stops changing.

A rough stab at the criteria goes like this:

CA:TRUE (and not ruled out by path length?)
notBefore < now() < notAfter()
EKU either non-existent or contains TLS-server
something about name constraints ?

Why do I say the algorithm is iterative ? Here's an extreme example. Suppose there are two rather incestuous companies Foo and Bar, each is a public root CA but also operates a confusing number of intermediates built up over many years, some even prior to the World Wide Web. Their root CAs are respectively Foo Root CA and Bar Root CA and all their intermediates have their name in the CN (already an improvement over the reality we face today).

Step 1. Foo identifies that "Foo Root CA" signed an unconstrained cert for "Bar Public Issuer Class 8" and they disclose that, although the only record they still have is a stained bar napkin so they hope they copied the serial number down correctly.

Step 2. Bar now remembers that "Bar Public Issuer Class 8" is still trusted, it had a 25 year expiry date and from archive tapes they find it signed an unconstrained cert for "Foo SHA-1 Upgrade CA" so they disclose that.

Step 3. Foo is surprised to be reminded of the old "Foo SHA-1 Upgrade CA" and that it's still technically trusted despite being retired back when Twitter didn't exist, they dig through old records and find it signed "Bar New 2048 RSA" so they disclose that.

Step 4. Bar is a little embarrassed, the keys from "Bar New 2048 RSA" are actually still in use in an OCSP server, but yep, it was technically unconstrained, and worse yet they find it was used to sign a cert for "Foo Private CA Oscar Zulu" before moving to its OCSP role.

Step 5. Foo are even more embarrassed that "Foo Private CA Oscar Zulu" is actually publicly trusted, they've been moving clients who want Intranet certs onto it, and completely forgot it has a cross-signature. Whoops. At least it didn't sign any other CA certificates though. The algorithm terminates.

As I understand it this algorithm, once performed properly, discloses all the intermediate certificates that should end up in a chain for a certificate I, a normal relying party, end up relying on. Relying parties can make trust decisions based on these disclosures, and Mozilla can inspect e.g. audits and evidence of appropriate technical controls for the disclosed intermediates.

If I run into a bad certificate (not talking about merely non-conforming, but e.g. a fake "google.com" or something of that sort) with an undisclosed intermediate in the chain Mozilla can most reasonably as a first step actively distrust that undisclosed intermediate. It would be literally _incredible_ for a root CA to argue that an intermediate is so important that Mozilla should still trust it despite the bad certificate, yet so unimportant they forgot it even existed and so didn't disclose it. From there Mozilla can investigate the intermediate's issuer. Did they "forget" any others? But in many cases just this first step plugs a big hole without waiting for weeks of discussion to conclude.

So far what we tend to see with intermediates that have been "forgotten" is that they aren't supposed to be used to issue TLS certificates. Distrusting those as a result of a security incident would be no great loss to the web PKI. A "submarine" intermediate, one that was not only technically unconstrained but deliberately signing end-entity TLS certificates or signing another CA that does so, yet not disclosed to Mozilla during the current process would therefore be rare and deserving of extra scrutiny if found later.

[Rob Stradling]

On 05/05/16 17:42, Nick Lamb wrote:
> On Thursday, 5 May 2016 13:22:34 UTC+1, Rob Stradling wrote:

>> That logic would imply that all of the "Not Trusted by Mozilla"
>> intermediates should be moved to "Disclosure required!", given that I
>> can't prove the non-existence of cross-certificates that would cause
>> these intermediates to become trusted!
>

> As a relying party I think the correct algorithm here is an iterative one, or at least, is best explained that way. Given the set of disclosed certificates, create a graph of CA nodes, reachable from the NSS public trust roots by following certificates that meet certain criteria. From each of those nodes, if you know of any certificates that would also meet the criteria, which are not yet disclosed, you must disclose them. Repeat until nobody discloses any more certificates and thus the graph stops changing.

Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is
that right?

> A rough stab at the criteria goes like this:
>
> CA:TRUE (and not ruled out by path length?)
> notBefore < now() < notAfter()
> EKU either non-existent or contains TLS-server
> something about name constraints ?
>
> Why do I say the algorithm is iterative ? Here's an extreme example. Suppose there are two rather incestuous companies Foo and Bar, each is a public root CA but also operates a confusing number of intermediates built up over many years, some even prior to the World Wide Web. Their root CAs are respectively Foo Root CA and Bar Root CA and all their intermediates have their name in the CN (already an improvement over the reality we face today).
>
> Step 1. Foo identifies that "Foo Root CA" signed an unconstrained cert for "Bar Public Issuer Class 8" and they disclose that, although the only record they still have is a stained bar napkin so they hope they copied the serial number down correctly.
>
> Step 2. Bar now remembers that "Bar Public Issuer Class 8" is still trusted, it had a 25 year expiry date and from archive tapes they find it signed an unconstrained cert for "Foo SHA-1 Upgrade CA" so they disclose that.
>
> Step 3. Foo is surprised to be reminded of the old "Foo SHA-1 Upgrade CA" and that it's still technically trusted despite being retired back when Twitter didn't exist, they dig through old records and find it signed "Bar New 2048 RSA" so they disclose that.
>
> Step 4. Bar is a little embarrassed, the keys from "Bar New 2048 RSA" are actually still in use in an OCSP server, but yep, it was technically unconstrained, and worse yet they find it was used to sign a cert for "Foo Private CA Oscar Zulu" before moving to its OCSP role.
>
> Step 5. Foo are even more embarrassed that "Foo Private CA Oscar Zulu" is actually publicly trusted, they've been moving clients who want Intranet certs onto it, and completely forgot it has a cross-signature. Whoops. At least it didn't sign any other CA certificates though. The algorithm terminates.
>
> As I understand it this algorithm, once performed properly, discloses all the intermediate certificates that should end up in a chain for a certificate I, a normal relying party, end up relying on. Relying parties can make trust decisions based on these disclosures, and Mozilla can inspect e.g. audits and evidence of appropriate technical controls for the disclosed intermediates.
>
> If I run into a bad certificate (not talking about merely non-conforming, but e.g. a fake "google.com" or something of that sort) with an undisclosed intermediate in the chain Mozilla can most reasonably as a first step actively distrust that undisclosed intermediate. It would be literally _incredible_ for a root CA to argue that an intermediate is so important that Mozilla should still trust it despite the bad certificate, yet so unimportant they forgot it even existed and so didn't disclose it. From there Mozilla can investigate the intermediate's issuer. Did they "forget" any others? But in many cases just this first step plugs a big hole without waiting for weeks of discussion to conclude.
>
> So far what we tend to see with intermediates that have been "forgotten" is that they aren't supposed to be used to issue TLS certificates. Distrusting those as a result of a security incident would be no great loss to the web PKI. A "submarine" intermediate, one that was not only technically unconstrained but deliberately signing end-entity TLS certificates or signing another CA that does so, yet not disclosed to Mozilla during the current process would therefore be rare and deserving of extra scrutiny if found later.

[Rob Stradling]

I've tweaked the categorization on https://crt.sh/mozilla-disclosures.
I think it's now as clear as possible, although any further comments are
welcome.

The 'C (for "cert")' policy is used to populate the "Technically
Constrained" and "Expired" categories. It's undisputed that
intermediates in these two categories do not need to be disclosed.

The rest of the currently undisclosed intermediates are split between
"Undisclosed" (where crt.sh can be sure that disclosure is required) and
"No Known id-kp-serverAuth Trust Paths" (where crt.sh cannot be sure).

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Nick Lamb]

On Friday, 6 May 2016 11:59:32 UTC+1, Rob Stradling wrote:
> Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is
> that right?

I suppose so. I think Richard has the trust arrow upside down in his reflection on this policy. Take his scenario in which a SubCA (A) is surprised to discover that its previously constrained parent (B) has now obtained an unconstrained certificate from a trusted root (C).

Richard seems concerned that this puts A in an awkward position, but what idiot is running C? They've just issued an unconstrained certificate to B, and they apparently didn't so much as reach out to previously constrained A, never mind having it properly audited for the new responsibilities they've given it. Did they even review the signatures from B to ensure they knew A existed? Nobody should trust C after this. With C untrusted, the unconstrained certificate they've erroneously issued is now worthless and A can continue to be as well run as it was before - once its leadership team have recovered from their heart attacks.

[Richard Barnes]

On Fri, May 6, 2016 at 6:58 AM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 05/05/16 17:42, Nick Lamb wrote:
>
>> On Thursday, 5 May 2016 13:22:34 UTC+1, Rob Stradling wrote:
>>

>>> That logic would imply that all of the "Not Trusted by Mozilla"
>>> intermediates should be moved to "Disclosure required!", given that I
>>> can't prove the non-existence of cross-certificates that would cause
>>> these intermediates to become trusted!
>>>
>>

>> As a relying party I think the correct algorithm here is an iterative
>> one, or at least, is best explained that way. Given the set of disclosed
>> certificates, create a graph of CA nodes, reachable from the NSS public
>> trust roots by following certificates that meet certain criteria. From each
>> of those nodes, if you know of any certificates that would also meet the
>> criteria, which are not yet disclosed, you must disclose them. Repeat until
>> nobody discloses any more certificates and thus the graph stops changing.
>>
>

> Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is
> that right?
>

Note that this is not just a Mozilla policy question, it's also a BR
question:

"""
*Technically Constrained Subordinate CA Certificate*: A Subordinate CA
certificate which uses a combination of Extended Key Usage settings and
Name Constraint settings to limit the scope within which the Subordinate CA
Certificate may issue Subscriber or additional Subordinate CA Certificates.

...

Certificates that are capable of being used to issue new certificates MUST
either be Technically Constrained in line with section 7.1.5 and audited in
line with section 8.7 only, or Unconstrained and fully audited in line with
all remaining requirements from this section. A Certificate is deemed as

capable of being used to issue new certificates if it contains an X.509v3

basicConstraints extension, with the cA boolean set to true and is
therefore by definition a Root CA Certificate or a Subordinate CA
Certificate.
"""
https://github.com/cabforum/documents/blob/master/docs/BR.md#161-definitions
https://github.com/cabforum/documents/blob/master/docs/BR.md#81-frequency-or-circumstances-of-assessment

It seems like the Mozilla policy's disclosure requirement basically boils
down to saying that any CAs that are considered Unconstrained by the BRs
(and thus require an audit) must also be disclosed to Mozilla. So we need
to answer this question for the BRs as well as for the Mozilla policy.

The BR text above seems to me to pretty much read as saying "look at the
certificate", not "look at the certificate and all its parents" (i.e., C
not CoAP). I'll grant that the phrase "uses" in the definition of
Technically Constrained is a little ambiguous.

--Richard

> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

[Richard Barnes]

On Fri, May 6, 2016 at 9:46 AM, Nick Lamb <tiala...@gmail.com> wrote:

> On Friday, 6 May 2016 11:59:32 UTC+1, Rob Stradling wrote:

> > Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is
> > that right?
>

> I suppose so. I think Richard has the trust arrow upside down in his
> reflection on this policy. Take his scenario in which a SubCA (A) is
> surprised to discover that its previously constrained parent (B) has now
> obtained an unconstrained certificate from a trusted root (C).
>
> Richard seems concerned that this puts A in an awkward position, but what
> idiot is running C? They've just issued an unconstrained certificate to B,
> and they apparently didn't so much as reach out to previously constrained
> A, never mind having it properly audited for the new responsibilities
> they've given it. Did they even review the signatures from B to ensure they
> knew A existed? Nobody should trust C after this. With C untrusted, the
> unconstrained certificate they've erroneously issued is now worthless and A
> can continue to be as well run as it was before - once its leadership team
> have recovered from their heart attacks.
>

I would phrase this slightly differently :) If C is a Mozilla program
root, it has an obligation to verify that all of the subordinates under B
are audited and disclosed. My point is that if C doesn't do this check
proactively, before issuing the subordinate to B, or if C relies on
information from B and B gets things wrong, then A now has to get an audit
in emergency mode, or else cease operations.

Whereas under the C='cert' policy, either A would be unconstrained and
already audited/disclosed, or they would have name constraints and there
would be no problem.

That said, you're correct that the CoAP policy is consistent, and I agree
that the risk of surprise isn't that bad if everyone is being responsible.
I'm more concerned about our ability to verify that CAs are in compliance
with the policy, in a world where we don't know the whole universe of
cross-certs. (And about consistency with the BRs on this point.)

--Richard

[Nick Lamb]

On Friday, 6 May 2016 15:06:30 UTC+1, Richard Barnes wrote:
> I would phrase this slightly differently :) If C is a Mozilla program
> root, it has an obligation to verify that all of the subordinates under B
> are audited and disclosed. My point is that if C doesn't do this check
> proactively, before issuing the subordinate to B, or if C relies on
> information from B and B gets things wrong, then A now has to get an audit
> in emergency mode, or else cease operations.

This is where I think our interpretations of the situation diverge. Why should A get an "emergency audit" ? I think it's patently ridiculous to insist they do any such thing, and it's certainly beyond the practical power of Mozilla. Mozilla can distrust C though.

> Whereas under the C='cert' policy, either A would be unconstrained and
> already audited/disclosed, or they would have name constraints and there
> would be no problem.

Consider an only very slightly different scenario, with entities A1 through C1 instead of A through C, but now A1 and B1 are private CA issuers which previously weren't part of the web PKI at all. Maybe they were companies issuing mostly client certs to a specific industry, whatever the circumstances they weren't covered by the BRs or by Mozilla root programme rules. B1 is thinking of getting into the public CA business, and is talking to C1.

Somebody at C1 jumps the gun and issues an unconstrained certificate joining B1, and thus A1 into the web PKI before they've actually done any sort of audit or due diligence. Whoops.

In that scenario it doesn't matter whether you have policy C or policy CoAP, either way suddenly A1 is part of the Web PKI without being audited or disclosed. I believe this is because C1 screwed up and that trust stores like Mozilla should react accordingly, you seem to believe that instead A1 screwed up, by... allowing a business they have no direct relationship with to be run incompetently? And they now need to go through an emergency audit because... that will help the incompetents stay in business?

As I said, I feel you have the trust arrow upside down. When C1 violates the rules, the negative consequences need to accrue to C1, otherwise they have no incentive to obey.

When Mozilla was informed that The Walt Disney Company Root CA cert was in fact revoked by its issuer before that CA began violating the BRs but they didn't notify Mozilla, the expression of disappointment was - correctly - directed at that trusted CA issuer. Not at Disney, because that would be futile.

> I'm more concerned about our ability to verify that CAs are in compliance
> with the policy, in a world where we don't know the whole universe of
> cross-certs. (And about consistency with the BRs on this point.)

Consistency with the BRs is indeed worth having, but probably shouldn't be the primary consideration here. If we can choose a policy that's good, or one that's consistent, let's pick "good" and send the consistency problem to CA/B Forum for them to look at.

[Ryan Sleevi]

On Thursday, May 5, 2016 at 6:57:21 AM UTC-7, Peter Bowen wrote:
> Nope, not acyclic. Already seen proof of that.

Correct - the Web PKI is a distributed, directed, cyclic graph.

> Consider the inverse.
>
> A root CA issues a CA certificate that is technically constrained (KP=serverAuth, permittedTree=dNSName:example.com, all other forbidden). It has no path length constraint. There is no disclosure required of this certificate, by policy.
>
> The subject of that constrained certificate issues another certificate. You propose disclosure is required of the child. But there will be no link to any root disclosed.
>
> How does this make sense?

I have to agree with Peter here. I'm actually surprised to see Richard arguing otherwise, since the intent was, when drafting this language in the previous update, to make it CoAP - the point at which the graph becomes 'snipped' because the risks are localized and contained.

In the case of:
Root
|- Intermediate 1 ("Technically Constrained")
|- Intermediate 2 (no constraints)
|- Leaf

The 'risk' scenario here is if Intermediate 2 is signed by another party. But I'm not sure how disclosing "Intermediate 2" makes any difference in that. If anything, it creates more noise - it makes people think that leaf was issued unconstrained, when it wasn't. The suggestion that Intermediate 2 should also be Technically Constrained is also not terribly appealing - that's adding more bytes for no value, other than the presumption of saving work for those monitoring the system, but I would argue that in order to be able to meaningfully monitor (meaning not raise false positives, and have actionable signals), they already need a global view.

I'm hesitant to play the interpretation game on the policy, and rather than suggest a reading that would support that position, suggest we try to resolve this. I'm still unclear of the objective value, and curious what Richard's position would be on the scope of the BRs is, since Gerv's representations of Mozilla's position with respect to BR scope have seemed in line with the CoAP view.

[Richard Barnes]

On Mon, May 9, 2016 at 10:12 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

> On Thursday, May 5, 2016 at 6:57:21 AM UTC-7, Peter Bowen wrote:

> > Nope, not acyclic. Already seen proof of that.
>

> Correct - the Web PKI is a distributed, directed, cyclic graph.
>

> > Consider the inverse.
> >
> > A root CA issues a CA certificate that is technically constrained
> (KP=serverAuth, permittedTree=dNSName:example.com, all other forbidden).
> It has no path length constraint. There is no disclosure required of this
> certificate, by policy.
> >
> > The subject of that constrained certificate issues another certificate.
> You propose disclosure is required of the child. But there will be no link
> to any root disclosed.
> >
> > How does this make sense?
>

> I have to agree with Peter here. I'm actually surprised to see Richard
> arguing otherwise, since the intent was, when drafting this language in the
> previous update, to make it CoAP - the point at which the graph becomes
> 'snipped' because the risks are localized and contained.
>
> In the case of:
> Root
> |- Intermediate 1 ("Technically Constrained")
> |- Intermediate 2 (no constraints)
> |- Leaf
>
> The 'risk' scenario here is if Intermediate 2 is signed by another party.

To be concrete, the risk is that a cert is issued with the same subject and
public key as the "Intermediate 1" cert.

> But I'm not sure how disclosing "Intermediate 2" makes any difference in
> that. If anything, it creates more noise - it makes people think that leaf
> was issued unconstrained, when it wasn't. The suggestion that Intermediate
> 2 should also be Technically Constrained is also not terribly appealing -
> that's adding more bytes for no value, other than the presumption of saving
> work for those monitoring the system, but I would argue that in order to be
> able to meaningfully monitor (meaning not raise false positives, and have
> actionable signals), they already need a global view.
>
> I'm hesitant to play the interpretation game on the policy, and rather
> than suggest a reading that would support that position, suggest we try to
> resolve this. I'm still unclear of the objective value, and curious what
> Richard's position would be on the scope of the BRs is, since Gerv's
> representations of Mozilla's position with respect to BR scope have seemed
> in line with the CoAP view.
>

To be honest, I probably started this from a slightly naïve position. I
think my preference would still be for C (if only because I have an innate
bias toward disclosure), but I've been convinced through this discussion
that CoAP is livable.

[Ryan Sleevi]

On Wednesday, May 11, 2016 at 10:55:12 AM UTC-7, Richard Barnes wrote:
> > In the case of:
> > Root
> > |- Intermediate 1 ("Technically Constrained")
> > |- Intermediate 2 (no constraints)
> > |- Leaf
> >
> > The 'risk' scenario here is if Intermediate 2 is signed by another party.
>
>
> To be concrete, the risk is that a cert is issued with the same subject and
> public key as the "Intermediate 1" cert.

Ah! Thanks for clarifying!

That's actually something that the Chrome team has been thinking about too, in the context of Certificate Transparency and monitors looking for possible misissuance. In effect, how to require Intermediates be appropriately disclosed, such that Intermediate 1 and Intermediate 1' are visible (to monitors), so that even if Leaf is for 'google.com' and Intermediate 1 is constrained to 'example.com' (aka "not valid/no risk"), if Intermediate 1' is unconstrained, a valid path exists and Monitors should be alerting. While it was implicit that Monitors should be continually watching all non-expired certs they're interested in (and not just 'new' certs), we're trying to make that more explicit.

You can also see some of the discussion on the IETF TRANS list, although I must admit, it's a bit weird there, as it seems like people are arguing in the context of a perfect-world of RFC 5280, rather than the 'real world' of "crap happens and threats exist".

I think we're both in agreement of the need to disclose Intermediate 1 and Intermediate 1'. If I am now correctly understanding your concern, it's that if a party (Root B) issues Intermediate 1' (the unconstrained version), that should now force a disclosure of Intermediate 2, right? I think that's an consequence entirely consistent with either interpretation of the policy - but it sounds like you think there's risk to that consequence, is that right?

If Root B issues such a certificate, aren't they effectively taking on the liability (in the Mozilla Root Program, and other programs) that Intermediate 2/Leaf comply with all the applicable policies Root B is subject to? Wouldn't the heavy hammer of non-compliance come down on Root B if they didn't ensure this, much like a CA who issues an unconstrained sub-CA to a party without a BR PITRA with an appropriately generated private key (which has happened)? Are there additional concerns?

[Richard Barnes]

On Wed, May 11, 2016 at 8:18 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

> On Wednesday, May 11, 2016 at 10:55:12 AM UTC-7, Richard Barnes wrote:

> > > In the case of:
> > > Root
> > > |- Intermediate 1 ("Technically Constrained")
> > > |- Intermediate 2 (no constraints)
> > > |- Leaf
> > >
> > > The 'risk' scenario here is if Intermediate 2 is signed by another
> party.
> >
> >
> > To be concrete, the risk is that a cert is issued with the same subject
> and
> > public key as the "Intermediate 1" cert.
>

> Ah! Thanks for clarifying!
>
> That's actually something that the Chrome team has been thinking about
> too, in the context of Certificate Transparency and monitors looking for
> possible misissuance. In effect, how to require Intermediates be
> appropriately disclosed, such that Intermediate 1 and Intermediate 1' are
> visible (to monitors), so that even if Leaf is for 'google.com' and
> Intermediate 1 is constrained to 'example.com' (aka "not valid/no risk"),
> if Intermediate 1' is unconstrained, a valid path exists and Monitors
> should be alerting. While it was implicit that Monitors should be
> continually watching all non-expired certs they're interested in (and not
> just 'new' certs), we're trying to make that more explicit.
>

Right, if the monitors are trying to identify all the valid certs, then
it's very important for them to have a full list of intermediates. Maybe
this is yet another positive use of this data set. (Note that the same
concern would apply to logs filtering on ingress.)

> You can also see some of the discussion on the IETF TRANS list, although I
> must admit, it's a bit weird there, as it seems like people are arguing in
> the context of a perfect-world of RFC 5280, rather than the 'real world' of
> "crap happens and threats exist".
>
> I think we're both in agreement of the need to disclose Intermediate 1 and
> Intermediate 1'. If I am now correctly understanding your concern, it's
> that if a party (Root B) issues Intermediate 1' (the unconstrained
> version), that should now force a disclosure of Intermediate 2, right? I
> think that's an consequence entirely consistent with either interpretation
> of the policy - but it sounds like you think there's risk to that
> consequence, is that right?
>

Yes, we agree on that.

It's mainly the discontinuity of Intermediate 2 suddenly transitioning from
the "constrained, so no worries" state to the "needs to be fully disclosed
and audited" state that worries me. Especially when you consider that
there could be a whole chain of intermediates above Intermediate 2, any one
of which could cause this state transition.

As you note below, it would be incumbent on the issuer of the unconstrained
intermediate 1' to assure compliance. But, you know, we see these "oops,
I missed that one" events all the time around here.

The fact that existing policy does apply here is the reason I'm saying I
can live with CoAP. But requiring each intermediate to be constrained
seems more conservative, because it avoids surprise and makes monitoring
more straightforward.

--Richard

>
> If Root B issues such a certificate, aren't they effectively taking on the
> liability (in the Mozilla Root Program, and other programs) that
> Intermediate 2/Leaf comply with all the applicable policies Root B is
> subject to? Wouldn't the heavy hammer of non-compliance come down on Root B
> if they didn't ensure this, much like a CA who issues an unconstrained
> sub-CA to a party without a BR PITRA with an appropriately generated
> private key (which has happened)? Are there additional concerns?

[Ryan Sleevi]

On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote:
> Right, if the monitors are trying to identify all the valid certs, then
> it's very important for them to have a full list of intermediates. Maybe
> this is yet another positive use of this data set.

Right, but I think the longer-goal is to get it into CT.

> (Note that the same
> concern would apply to logs filtering on ingress.)

Logs shouldn't be filtering on ingress, ideally ;)

> It's mainly the discontinuity of Intermediate 2 suddenly transitioning from
> the "constrained, so no worries" state to the "needs to be fully disclosed
> and audited" state that worries me. Especially when you consider that
> there could be a whole chain of intermediates above Intermediate 2, any one
> of which could cause this state transition.

Who is the concern for? The operators of Intermediate 2? The operators of Intermediate 1? The operators of Root B?

> As you note below, it would be incumbent on the issuer of the unconstrained
> intermediate 1' to assure compliance. But, you know, we see these "oops,
> I missed that one" events all the time around here.

Isn't another way to address that via technical means? Such as whitelisting (disclosed) intermediates and only allowing (undisclosed) intermediates if they chain to a constrained intermediate?

That's fundamentally our goal with Certificate Transparency, but even in the absence of precerts-in-an-Intermediate (which CAs can totally be doing today *cough*), you could still devise technical means to address that.

> The fact that existing policy does apply here is the reason I'm saying I
> can live with CoAP. But requiring each intermediate to be constrained
> seems more conservative, because it avoids surprise and makes monitoring
> more straightforward.

I suppose I can buy that. If we had a hypothetical world where, say, every Intermediate had to be accompanied by a requisite number of SCTs, or was perhaps a whitelist driven by public CT data, or was driven by a whitelist driven by Salesforce, would you still see that as valuable?

I agree with you that it's conservative, and also provides greater defense in depth, but at greater overhead, so I'm wondering if there's a world where we can have both our speed and our disclosures, and have technical enforcement for both.

[Rob Stradling]

On 12/05/16 00:53, Ryan Sleevi wrote:
> On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote:

>> Right, if the monitors are trying to identify all the valid certs, then
>> it's very important for them to have a full list of intermediates. Maybe
>> this is yet another positive use of this data set.
>

> Right, but I think the longer-goal is to get it into CT.
>

>> (Note that the same
>> concern would apply to logs filtering on ingress.)
>

> Logs shouldn't be filtering on ingress, ideally ;)
>

>> It's mainly the discontinuity of Intermediate 2 suddenly transitioning from
>> the "constrained, so no worries" state to the "needs to be fully disclosed
>> and audited" state that worries me. Especially when you consider that
>> there could be a whole chain of intermediates above Intermediate 2, any one
>> of which could cause this state transition.
>

> Who is the concern for? The operators of Intermediate 2? The operators of Intermediate 1? The operators of Root B?
>

>> As you note below, it would be incumbent on the issuer of the unconstrained
>> intermediate 1' to assure compliance. But, you know, we see these "oops,
>> I missed that one" events all the time around here.
>

> Isn't another way to address that via technical means? Such as whitelisting (disclosed) intermediates and only allowing (undisclosed) intermediates if they chain to a constrained intermediate?
>
> That's fundamentally our goal with Certificate Transparency, but even in the absence of precerts-in-an-Intermediate (which CAs can totally be doing today *cough*), you could still devise technical means to address that.

Ryan,

Why would CAs totally be embedding precert SCTs into intermediate certs
today? Would Chrome validate such SCTs? When has Google announced that
this is something that CAs are expected or encouraged to do? Where is
it documented that this is something that CAs are even permitted to do
today?

In recent months I've add-chain'd lots (1000s, IIRC) of CA certs to
existing public RFC6962 logs, and I intend to keep doing so (so that
there are zero "Unknown to crt.sh" [1] certs :-) ). I haven't tried
add-pre-chain'ing a CA cert to any existing public RFC6962 logs, but it
would surprise me if it would work.

*Nonetheless*, RFC6962 says (for both add-chain and add-pre-chain) that
the "first element is the end-entity certificate". Clearly, CA
certificates are not end-entity certificates, so we're talking about
undocumented behaviour. (6962-bis changes this, but that's not relevant
yet).

If you want CAs to do something today that relies on undocumented
behaviour, merely *cough*ing won't help.


[1] https://crt.sh/mozilla-disclosures

>> The fact that existing policy does apply here is the reason I'm saying I
>> can live with CoAP. But requiring each intermediate to be constrained
>> seems more conservative, because it avoids surprise and makes monitoring
>> more straightforward.
>

> I suppose I can buy that. If we had a hypothetical world where, say, every Intermediate had to be accompanied by a requisite number of SCTs, or was perhaps a whitelist driven by public CT data, or was driven by a whitelist driven by Salesforce, would you still see that as valuable?
>
> I agree with you that it's conservative, and also provides greater defense in depth, but at greater overhead, so I'm wondering if there's a world where we can have both our speed and our disclosures, and have technical enforcement for both.

[Richard Barnes]

On Thu, May 12, 2016 at 1:53 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

> On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote:

> > Right, if the monitors are trying to identify all the valid certs, then
> > it's very important for them to have a full list of intermediates. Maybe
> > this is yet another positive use of this data set.
>

> Right, but I think the longer-goal is to get it into CT.
>

> > (Note that the same
> > concern would apply to logs filtering on ingress.)
>

> Logs shouldn't be filtering on ingress, ideally ;)
>

> > It's mainly the discontinuity of Intermediate 2 suddenly transitioning
> from
> > the "constrained, so no worries" state to the "needs to be fully
> disclosed
> > and audited" state that worries me. Especially when you consider that
> > there could be a whole chain of intermediates above Intermediate 2, any
> one
> > of which could cause this state transition.
>

> Who is the concern for? The operators of Intermediate 2? The operators of
> Intermediate 1? The operators of Root B?
>

> > As you note below, it would be incumbent on the issuer of the
> unconstrained
> > intermediate 1' to assure compliance. But, you know, we see these
> "oops,
> > I missed that one" events all the time around here.
>

> Isn't another way to address that via technical means? Such as
> whitelisting (disclosed) intermediates and only allowing (undisclosed)
> intermediates if they chain to a constrained intermediate?
>
> That's fundamentally our goal with Certificate Transparency, but even in
> the absence of precerts-in-an-Intermediate (which CAs can totally be doing
> today *cough*), you could still devise technical means to address that.
>

Oh totally. We are already looking at extending OneCRL to do a whitelist
of this sort. In fact, I think I said up-thread that this would make the
CoAP policy OK because it would limit the universe of possible paths.

>
> > The fact that existing policy does apply here is the reason I'm saying I
> > can live with CoAP. But requiring each intermediate to be constrained
> > seems more conservative, because it avoids surprise and makes monitoring
> > more straightforward.
>

> I suppose I can buy that. If we had a hypothetical world where, say, every
> Intermediate had to be accompanied by a requisite number of SCTs, or was
> perhaps a whitelist driven by public CT data, or was driven by a whitelist
> driven by Salesforce, would you still see that as valuable?
>
> I agree with you that it's conservative, and also provides greater defense
> in depth, but at greater overhead, so I'm wondering if there's a world
> where we can have both our speed and our disclosures, and have technical
> enforcement for both.
>

I think we're in violent agreement. If we pair the CoAP policy with
whitelist / CT, we get to a pretty good state. The only real cost is that
it you need to do some computation to figure out whether a given cert needs
to be disclosed, but I assume Rob can get that done :)

--Richard

[Ben Laurie]

On 12 May 2016 at 00:53, Ryan Sleevi <ry...@sleevi.com> wrote:
> On Wednesday, May 11, 2016 at 3:44:54 PM UTC-7, Richard Barnes wrote:

>> Right, if the monitors are trying to identify all the valid certs, then
>> it's very important for them to have a full list of intermediates. Maybe
>> this is yet another positive use of this data set.
>

> Right, but I think the longer-goal is to get it into CT.

FYI, we recently changed the way we submit chains from our web crawl
into CT so that all intermediates seen should end up logged.

[Ben Laurie]

On 12 May 2016 at 09:43, Rob Stradling <rob.st...@comodo.com> wrote:
> In recent months I've add-chain'd lots (1000s, IIRC) of CA certs to existing
> public RFC6962 logs, and I intend to keep doing so (so that there are zero
> "Unknown to crt.sh" [1] certs :-) ). I haven't tried add-pre-chain'ing a CA
> cert to any existing public RFC6962 logs, but it would surprise me if it
> would work.

As far as I know, it should work. Why would you be surprised?

>
> *Nonetheless*, RFC6962 says (for both add-chain and add-pre-chain) that the
> "first element is the end-entity certificate". Clearly, CA certificates are
> not end-entity certificates, so we're talking about undocumented behaviour.
> (6962-bis changes this, but that's not relevant yet).

Not so sure about that. It seems to me that "end entity" is only
defined in the context of a chain, and refers to the last cert in the
chain. If the chain ends at an intermediate CA cert, then it is the
end entity cert in that chain.

[Rob Stradling]

On 12/05/16 12:00, Ben Laurie wrote:
> On 12 May 2016 at 09:43, Rob Stradling <rob.st...@comodo.com> wrote:
>> In recent months I've add-chain'd lots (1000s, IIRC) of CA certs to existing
>> public RFC6962 logs, and I intend to keep doing so (so that there are zero
>> "Unknown to crt.sh" [1] certs :-) ). I haven't tried add-pre-chain'ing a CA
>> cert to any existing public RFC6962 logs, but it would surprise me if it
>> would work.
>
> As far as I know, it should work. Why would you be surprised?

Gah! Insufficient coffee.

s/would/wouldn't/

>> *Nonetheless*, RFC6962 says (for both add-chain and add-pre-chain) that the
>> "first element is the end-entity certificate". Clearly, CA certificates are
>> not end-entity certificates, so we're talking about undocumented behaviour.
>> (6962-bis changes this, but that's not relevant yet).
>
> Not so sure about that. It seems to me that "end entity" is only
> defined in the context of a chain, and refers to the last cert in the
> chain. If the chain ends at an intermediate CA cert, then it is the
> end entity cert in that chain.

RFC5280 section 3.2 says:
"This specification covers two classes of certificates: CA
certificates and end entity certificates.
...
End entity certificates are issued to subjects that are not
authorized to issue certificates."

Section 4.2.1.9 says:
"The basic constraints extension identifies whether the subject of the
certificate is a CA"

I think it's clear that any cert containing basicConstraints:CA=TRUE is
a "CA certificate" and not an "end-entity certificate."

[Rob Stradling]

On 12/05/16 10:08, Richard Barnes wrote:
<snip>

> I think we're in violent agreement. If we pair the CoAP policy with
> whitelist / CT, we get to a pretty good state. The only real cost is that
> it you need to do some computation to figure out whether a given cert needs
> to be disclosed, but I assume Rob can get that done :)

Done.

https://crt.sh/mozilla-disclosures now puts all explicitly Technically
Constrained intermediates in the "Technically Constrained" bucket, and
all 'implicitly technically constrained' intermediates in the "No
Observed Unconstrained id-kp-serverAuth Trust" bucket.

Note the distinction between "No" and "Never". "No" here means "Not as
far as we know right now, but this would change upon discovery of an
unconstrained id-kp-serverAuth trust path".

[Ben Laurie]

OK, then - I hope we fixed this in 6962-bis. :-)

[Rob Stradling]

On 12/05/16 15:33, Ben Laurie wrote:
<snip>

>> I think it's clear that any cert containing basicConstraints:CA=TRUE is a
>> "CA certificate" and not an "end-entity certificate."
>
> OK, then - I hope we fixed this in 6962-bis. :-)

We did. :-)