Re: How long to resolve unaudited unconstrained intermediates?

[Rob Stradling via dev-security-policy]

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

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

Re: How long to resolve unaudited unconstrained intermediates?

[Gervase Markham via dev-security-policy]

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.

> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

On Wed, Jul 12, 2017 at 12:12:13PM -0400, Ryan Sleevi wrote:
> 
> 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.

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

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

RE: How long to resolve unaudited unconstrained intermediates?

[Ben Wilson via dev-security-policy]

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:agay...@mozilla.com] 
Sent: Tuesday, July 11, 2017 1:24 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@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> =digicert@lists.mozilla.org 
<mailto:digicert@lists.mozilla.org> ] On
Behalf Of Nick Lamb via dev-security-policy
Sent: Tuesday, July 11, 2017 7:57 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy


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

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How long to resolve unaudited unconstrained intermediates?

[Ryan Sleevi via dev-security-policy]

On Wed, Jul 12, 2017 at 10:40 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How long to resolve unaudited unconstrained intermediates?

[Ryan Sleevi via dev-security-policy]

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

> On 2017-07-11 15:56, Nick Lamb wrote:
>
>> 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.
>>
>
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

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

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.


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

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

Re: How long to resolve unaudited unconstrained intermediates?

[Nick Lamb via dev-security-policy]

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How long to resolve unaudited unconstrained intermediates?

[Kurt Roeckx via dev-security-policy]

On 2017-07-10 18:35, Alex Gaynor wrote:

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.


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy