Re: WoSign new system passed Cure 53 system security audit

[Richard Wang via dev-security-policy]

Hi Ryan,

We got confirmation from Cure 53 that new system passed the full security 
audit. Please contact Cure 53 directly to verify this, thanks.

We don't start the BR audit now.

Best Regards,

Richard

On 12 Jul 2017, at 22:09, Ryan Sleevi > 
wrote:



On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang 
> wrote:
Hi all,

Your reported BR issues is from StartCom, not WoSign, we don't use the new 
system to issue any certificate now since the new root is not generated.
PLEASE DO NOT mix it, thanks.

Best Regards,

Richard

No, the BR non-compliance is demonstrated from the report provided to browsers 
- that is, the full report associated with this thread.

That is, as currently implemented, the infrastructure for the new roots would 
not be able to receive an unqualified audit. Further system work is necessary, 
and that work is significant enough that it will affect the conclusions from 
the report.
___
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#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 
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 
 > 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 
 =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 
 
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 
 
https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
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

Leaking private keys through web servers

[Hanno Böck via dev-security-policy]

Hello,

I recently did an investigation where I tried to simply download private
keys from web servers with common filenames. I collected these
filenames simply from common tutorials on the web (server.key,
privatekey.key, myserver.key, key.pem and [hostname].key with and
without www).
In several cases I was able to download private keys belonging to
currently valid certificates.

I wrote about this today for the German news site Golem.de (with an
english translation available):
https://www.golem.de/news/https-private-keys-on-web-servers-1707-128862.html


In the course of this I also learned quite a bit about the revocation
process. According to the baseline requirements a CA shall revoke keys
within 24 hours in case of a key compromise.

Some notes about my experiences:
* All certificates I reported are revoked now.
* In several cases the deadline wasn't hit and CAs took longer. Some
  took over 4 days. In one case (Gandi) I learned that it's a branded
  CA from Comodo. Comodo immediately revoked the cert after they
  learned about it, but this raises interesting questions about the
  responsibilities of branded CAs.
* The reporting process is wildly different. Some CAs provide email
  addresses, others online forms, Symantec has forms with captchas. In
  the April CA communications [1] mozilla announced that it wants to
  compile a list of contact methods and has asked CAs for them. I would
  encourage streamlining that process. I also think revocation should
  be automatable (at least on the side of the reporter) and wonder
  whether things like forms with captchas should be outruled.
  Particularly interesting is Let's Encrypt that provides an API via
  ACME to revoke if you posess the private key. IMHO that's ideal.
* Comodo re-issued certs with the same key. I wonder if there should be
  a rule that once a key compromise event is known to the CA it must
  make sure this key is blacklisted. (Or maybe one of the existing
  rules already apply, I don't know.)

I had opened a private bug in mozillas bugtracker which contains some
more info and lists of the specific certificates. It's up to mozilla
when they'll open it, but from my side I think this can go public.


[1] https://wiki.mozilla.org/CA/Communications#April_2017_Responses
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1378074
-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
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: WoSign new system passed Cure 53 system security audit

[Ryan Sleevi via dev-security-policy]

On Tue, Jul 11, 2017 at 8:18 PM, Richard Wang  wrote:

> Hi all,
>
> Your reported BR issues is from StartCom, not WoSign, we don't use the new
> system to issue any certificate now since the new root is not generated.
> PLEASE DO NOT mix it, thanks.
>
> Best Regards,
>
> Richard
>

No, the BR non-compliance is demonstrated from the report provided to
browsers - that is, the full report associated with this thread.

That is, as currently implemented, the infrastructure for the new roots
would not be able to receive an unqualified audit. Further system work is
necessary, and that work is significant enough that it will affect the
conclusions from the report.
___
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