How long to resolve unaudited unconstrained intermediates?

[Alex Gaynor]

Hi all,

I wanted to call some attention to a few intermediates which have been
hanging out in the "Audit required" section for quite a while:
https://crt.sh/mozilla-disclosures#disclosureincomplete

Specifically, the TurkTrust and Firmaprofesional ones. Both have issues
open in Bugzilla:

- https://bugzilla.mozilla.org/show_bug.cgi?id=1367842
- https://bugzilla.mozilla.org/show_bug.cgi?id=1368171

However, neither appears to have seen any attention from the CAs in the
past two months.

Section 5.3.2 of the Mozilla Root Policy says they have a week to disclose
the cert, however I'm a bit less clear on on what timeline they're required
to provide the audit statements.

Cheers,
Alex

[Kurt Roeckx]

We have a template for reminding about missing audits here:
https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template

As far as I know, this was first sent on the 3rd of April, see the
thread with subject: "Automated email reminders about intermediate certs
missing audit or CP/CPS". I don't think such reminders were sent a
second time.

So at least some of them have been notified more than 3 months ago, and
a bug was filed a month later. I think you already gave them too much
time to at least respond to it, and suggest that you sent a new email
indicating that if they don't respond immediately that they will get
added to OneCRL.


Kurt

[Nick Lamb]

On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:>
> So at least some of them have been notified more than 3 months ago, and
> a bug was filed a month later. I think you already gave them too much
> time to at least respond to it, and suggest that you sent a new email
> indicating that if they don't respond immediately that they will get
> added to OneCRL.

Agreed. It may also make sense to add telemetry that allows Mozilla to determine whether listing such subCAs in the OneCRL are ever actually blocking anything. This makes a difference in my opinion as to the severity of the breach of policy by the CA in question.

[Ben Wilson]

By the way, I just noticed on https://crt.sh/mozilla-disclosures#undisclosed
that CA certificates with an EKU of eMailProtection (1.3.6.1.5.5.7.3.4) are
now listed when they weren't required to be listed previously. Presumably
CAs will be given ample time to update these entries.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Tuesday, July 11, 2017 7:57 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: How long to resolve unaudited unconstrained intermediates?

On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:>

> So at least some of them have been notified more than 3 months ago,
> and a bug was filed a month later. I think you already gave them too
> much time to at least respond to it, and suggest that you sent a new
> email indicating that if they don't respond immediately that they will
> get added to OneCRL.

Agreed. It may also make sense to add telemetry that allows Mozilla to
determine whether listing such subCAs in the OneCRL are ever actually
blocking anything. This makes a difference in my opinion as to the severity
of the breach of policy by the CA in question.

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

[Alex Gaynor]

Hey Ben,

Take a look at the thread "Disclosing unconstrained emailProtection
intermediates to CCADB" by Rob, it explains the change and has the relevant
dates by which CAs must comply.

Alex

On Tue, Jul 11, 2017 at 3:21 PM, Ben Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> By the way, I just noticed on https://crt.sh/mozilla-
> disclosures#undisclosed
> that CA certificates with an EKU of eMailProtection (1.3.6.1.5.5.7.3.4) are
> now listed when they weren't required to be listed previously. Presumably
> CAs will be given ample time to update these entries.
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Tuesday, July 11, 2017 7:57 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: How long to resolve unaudited unconstrained intermediates?
>
> On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:>

> > So at least some of them have been notified more than 3 months ago,
> > and a bug was filed a month later. I think you already gave them too
> > much time to at least respond to it, and suggest that you sent a new
> > email indicating that if they don't respond immediately that they will
> > get added to OneCRL.
>

[Kurt Roeckx]

I don't know if this currently happens, but I would like to see all CA
certificates that are in OneCRL but are not revoked to be added to the
root store as distrusted too.


Kurt

[Ryan Sleevi]

On Wed, Jul 12, 2017 at 6:03 AM, Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 2017-07-11 15:56, Nick Lamb wrote:
>

> I don't know if this currently happens, but I would like to see all CA
> certificates that are in OneCRL but are not revoked to be added to the root
> store as distrusted too.
>

Why? I can share reasons why it might not be desirable, but rather than
start out negatively, I was hoping you could expand upon the reasons for
including.

[Kurt Roeckx]

On 2017-07-12 16:12, Ryan Sleevi wrote:
>> I don't know if this currently happens, but I would like to see all CA
>> certificates that are in OneCRL but are not revoked to be added to the root
>> store as distrusted too.
>>
>
> Why? I can share reasons why it might not be desirable, but rather than
> start out negatively, I was hoping you could expand upon the reasons for
> including.

My understanding is that certdata.txt is what is the trust of the root
store is, and that OneCRL is mostly a browser only thing to get
revocation information, but is also (ab)used to distrust something.

The certdata.txt currently does explicitly list CA certificates that
shouldn't be trusted.

As far as I know external user of the trust information currently only
use certdata.txt. So only adding it to OneCRL will not reach all the
users of the trust store.

It could be that maybe the combination is what should be used, but as
far as I know it's not documented as such and I doubt it gets used much
outside Mozilla products.


Kurt

[Ryan Sleevi]

On Wed, Jul 12, 2017 at 10:40 AM, Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 2017-07-12 16:12, Ryan Sleevi wrote:
>

>> I don't know if this currently happens, but I would like to see all CA
>>> certificates that are in OneCRL but are not revoked to be added to the
>>> root
>>> store as distrusted too.
>>>
>>>
>> Why? I can share reasons why it might not be desirable, but rather than
>> start out negatively, I was hoping you could expand upon the reasons for
>> including.
>>
>

> My understanding is that certdata.txt is what is the trust of the root
> store is, and that OneCRL is mostly a browser only thing to get revocation
> information, but is also (ab)used to distrust something.
>
> The certdata.txt currently does explicitly list CA certificates that
> shouldn't be trusted.
>
> As far as I know external user of the trust information currently only use
> certdata.txt. So only adding it to OneCRL will not reach all the users of
> the trust store.
>
> It could be that maybe the combination is what should be used, but as far
> as I know it's not documented as such and I doubt it gets used much outside
> Mozilla products.

You're correct that OneCRL is specific to Firefox. OneCRL has the (highly
desirable) properties of being able to be rapidly updated, much like
CRLSets. In times of compatibility issues, it's possible to 'un'revoke a
certificate - as has been necessary, in the past, due to high-profile
revocations causing various path building issues. As a concrete example,
both Symantec and Comodo had revocations which - while, on a pure technical
level, were entirely correct - the processing of these revocations caused
issues for clients as diverse as Apple macOS, Microsoft Windows, and,
perhaps unsurprisingly, Google Chrome.

The risk in moving these to certdata.txt (which is consumed by a wide
variety of clients - and in particular, those not using the current version
of Mozilla NSS as Mozilla Firefox) is generally that carried out by
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
. That is, it is patently unwise (and, at times, unsafe) to consume the
Mozilla Root CA Store without using and validating certificates using the
same code as Mozilla Firefox. I know this dismays some members, but that's
the reality due to the complexity of chain and path building.

Consider, for example, a client that does not support path discovery
(which, for example, includes most actively-deployed OpenSSL versions). If
one were to extract certdata.txt into trust and distrust records, with the
algorithm that OpenSSL uses, this would actively break connections to a
number of sites, as it would encounter the distrusted certificates and
cease path building. Mozilla Firefox, on the other hand, uses mozilla::pkix
and implements a robust path discovery mechanism - the presence of a
distrust record will have it 'unwind' on path discovery and continue trying
alternative paths.

One can see this having played out in other situations in the past as well
- such as Red Hat's decision to (temporarily) ship 1024-bit roots that were
removed from the Mozilla Root CA store, due to their need to support
OpenSSL clients that could not build alternative paths to the (included)
2048-bit roots.

In this sense, by keeping them separated - into certdata.txt and OneCRL -
Mozilla is able to ensure certdata.txt is more usable by these clients.
Including them in certdata.txt, while certainly more complete and
comprehensive, would conversely mean more clients would break when
consuming certdata.txt - or, if Mozilla were to try to maintain
certdata.txt as an 'interoperable source of truth', would prevent the
necessary changes to ensure users are safe.

Further, consider that while the use of OCSP or CRLs, and in particular,
hard fail, is unsuitable for a client such as Mozilla Firefox, other
products may have different requirements for both performance and
availability. For example, for a mutually authenticating batch processing
system, the additional latency and/or unreliability imposed by these
revocation checking methods is not as significant to the overall product
flow, and thus offers a better alternative than relying on either OneCRL or
certdata.txt updates.

Because the situation varies by client - and, again, I want to stress that
a "Web PKI" client that wishes to remain interoperable with 'the browsers'
truly needs to be using the same code as 'the browsers' (and this is true
across all major browser platforms) - keeping it distinct best serves the
needs of various consumers, and allows the few distrust records included to
be ones that minimize the large-scale compatibility impact that might
otherwise be introduced.

[Ben Wilson]

Even though I have until 15-Jan-2018 to comply, I have uploaded a few CAs where EKU contains emailProtection, and here a few more questions.



For CAs with emailProtection and proper name constraints, where would such CAs appear in <https://crt.sh/mozilla-disclosures> https://crt.sh/mozilla-disclosures? <https://crt.sh/mozilla-disclosures#constrainedother> https://crt.sh/mozilla-disclosures#constrainedother ? Or a new section of the list, yet to be determined?



And for CAs where EKU contains emailProtection, what are the programmatic criteria that determine whether the CA will be in such list as properly name constrained, since the Baseline Requirements don’t cover email certificates? (Presumably, a properly name-constrained email CA would not require any audit.)



Can the mozilla-disclosures list filter on whether there is a WebTrust 2.0/ETSI audit (and not on the BR audit since email certificates aren’t covered by BR audits)?



Thanks,



Ben

From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Tuesday, July 11, 2017 1:24 PM
To: Ben Wilson <ben.w...@digicert.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: How long to resolve unaudited unconstrained intermediates?

Hey Ben,



Take a look at the thread "Disclosing unconstrained emailProtection intermediates to CCADB" by Rob, it explains the change and has the relevant dates by which CAs must comply.



Alex

On Tue, Jul 11, 2017 at 3:21 PM, Ben Wilson via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:

By the way, I just noticed on https://crt.sh/mozilla-disclosures#undisclosed
that CA certificates with an EKU of eMailProtection (1.3.6.1.5.5.7.3.4) are
now listed when they weren't required to be listed previously. Presumably
CAs will be given ample time to update these entries.


-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben <mailto:dev-security-policy-bounces%2Bben> =digice...@lists.mozilla.org <mailto:digice...@lists.mozilla.org> ] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Tuesday, July 11, 2017 7:57 AM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: How long to resolve unaudited unconstrained intermediates?

On Tuesday, 11 July 2017 10:56:43 UTC+1, Kurt Roeckx wrote:>

> So at least some of them have been notified more than 3 months ago,
> and a bug was filed a month later. I think you already gave them too
> much time to at least respond to it, and suggest that you sent a new
> email indicating that if they don't respond immediately that they will
> get added to OneCRL.

Agreed. It may also make sense to add telemetry that allows Mozilla to
determine whether listing such subCAs in the OneCRL are ever actually
blocking anything. This makes a difference in my opinion as to the severity
of the breach of policy by the CA in question.

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

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


_______________________________________________
dev-security-policy mailing list

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

[Kurt Roeckx]

So I think what you're saying is that adding it to certdata.txt
might result in it breaking for for non-browsers while it might
keep working for browsers because they behave better, and so you
prefer adding it to OneCRL.

I'm interested in having OpenSSL behave more like the browsers,
and so maybe some of the points you're making might not apply
in the future anymore.

You could argue that it's a bug in the other implementations that
they can't deal with it, and that you should not restrict what is
in certdata.txt to what all consumers of it can handle.


Kurt

[Gervase Markham]

On 12/07/17 21:18, Ben Wilson wrote:
> For CAs with emailProtection and proper name constraints, where would such CAs appear in <https://crt.sh/mozilla-disclosures> https://crt.sh/mozilla-disclosures? <https://crt.sh/mozilla-disclosures#constrainedother> https://crt.sh/mozilla-disclosures#constrainedother ? Or a new section of the list, yet to be determined?

I believe Rob has now split the list into two.

> And for CAs where EKU contains emailProtection, what are the programmatic criteria that determine whether the CA will be in such list as properly name constrained, since the Baseline Requirements don’t cover email certificates? (Presumably, a properly name-constrained email CA would not require any audit.)

Rob would be able to say. But the criteria for whether an email
intermediate is properly name constrained are in Mozilla policy 2.5.

Gerv

[Rob Stradling]

On 20/07/17 15:24, Gervase Markham via dev-security-policy wrote:
> On 12/07/17 21:18, Ben Wilson wrote:

>> For CAs with emailProtection and proper name constraints, where would such CAs appear in https://crt.sh/mozilla-disclosures? https://crt.sh/mozilla-disclosures#constrainedother? Or a new section of the list, yet to be determined?

>
> I believe Rob has now split the list into two.

Ben, these intermediate certs should appear in
https://crt.sh/mozilla-disclosures#constrained (if they've not been
disclosed to CCADB).

https://crt.sh/mozilla-disclosures#constrainedother is for intermediate
certs for which there is a signature chain up to a root that is trusted
by Mozilla, but which are trusted for neither Server Authentication nor
Secure Email. (Mostly they're Code Signing intermediates, it seems).

>> And for CAs where EKU contains emailProtection, what are the programmatic criteria that determine whether the CA will be in such list as properly name constrained, since the Baseline Requirements don’t cover email certificates? (Presumably, a properly name-constrained email CA would not require any audit.)
>

> Rob would be able to say. But the criteria for whether an email
> intermediate is properly name constrained are in Mozilla policy 2.5.

The purpose of the https://crt.sh/mozilla-disclosures page is to track
compliance with the Mozilla Root Store Policy. BRs, or the lack of
them, are only relevant to this page insofar as the Mozilla Root Store
Policy says they're relevant.

So yes, this page uses the criteria from Mozilla Root Store Policy v2.5.

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