Re: Public trust of VISA's CA

[Jakob Bohm via dev-security-policy]

On 20/09/2017 09:37, Martin Rublik wrote:

On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


https://crt.sh/mozilla-certvalidations?group=version=896972 is a very
informative graph for me -- this is the number of validations performed by
Firefox for certs under this CA. It looks like at the absolute peak, there
were 1000 validations in a day. That's very little value for our users, in
return for an awful lot of risk.

Alex



Hi,

I agree that 1000 validations in a day is not much, or better to say really
low number. Anyway I was wondering what should be a minimum value or
whether this number is a good metric at all. I went through the Mozilla
validations telemetrics and there are more CAs with similliar number of
validations.



In interpreting that statistic, it is worth noting that Banks etc. tend
to have strong internal security configuration policies, which probably
include the disabling of all kinds of application "telemetry".

But it is still worth considering if this CA root should only be a
non-public CA root, included only by local configuration (typically
using the Firefox/Thunderbird enterprise deployment tools in the case of
Firefox/Thunderbird).

The age of their inclusion suggests a long transition period if removal
is solely for formal reasons rather than actual insecurity.  And of
cause such removal should be in a form that doesn't block manual
reinclusion via configuration.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SHA-1 OCSP responder certificates

[Frank Corday via dev-security-policy]

On September 8, 2017, a member our team discovered that one of our OCSP 
responder certificates had been signed with SHA-1 with a notBefore date of May 
23, 2017.  We initiated an investigation and discovered that there were a total 
of 4 such certificates, all issued on May 23 as annual renewals to support our 
old SHA-1 issuing CAs until the last of the certificates issued from them has 
expired or been revoked and the CAs themselves can be revoked.  The 4 OCSP 
responder certificates have been posted to CT and are available from the 
following URLs:

https://crt.sh/?id=201187008
https://crt.sh/?id=214252118
https://crt.sh/?id=214252119
https://crt.sh/?id=214252120

Our OCSP responses are generated on the same HSMs that host our issuing CAs, so 
the renewal of the OCSP signing certificates is performed using a script 
executed directly on the CA servers during a scheduled quarterly CA room entry. 
 This issuance was the result of an oversight in updating that script from the 
one used in 2016, in order to force the non-default behavior of signing the 
responder certificates with a different hash than the one with which the CA 
itself is signed.  None of our active issuing CAs, nor our offline root CAs 
were affected.  Our offline root CAs also use delegated OCSP responder 
certificates, which were also renewed on the same day, but were properly signed 
with SHA-256.  Our active SHA-256 issuing CAs sign OCSP responses directly and 
thus do not require responder certificates.

We are in the process of updating the OCSP responder issuing script and testing 
it in our test environment.  We will then schedule a CA room entry to repeat 
this procedure to issue and deploy new SHA-256 signed certificate replacements 
and revoke the stated 4 certificates.  We expect to complete this by the end of 
the month.

The last still-valid certificate expiration dates for the 4 CAs are as follows:
DVCA: October 24, 2017
OVCA: January 19, 2018
CLACA: December 10, 2018
CSCA: March 18, 2019

Based on these dates, we would anticipate revoking both DVCA and OVCA in Q1 
2018, and performing one more OCSP responder renewal for CLACA and CSCA in 
mid-2018, for which we will use the updated SHA-256 script.  As further 
insurance against this happening in the future, we have updated QA procedures 
to explicitly check the signature algorithm on OCSP responder certificate 
renewals when testing our quarterly CA room activities.

We appreciate the efforts of the independent researchers who have identified a 
variety of issues as of late, and apologize for our oversight in this instance. 
 We also welcome any further suggestions members of the community may provide 
on this matter.

Best regards,

Frank Corday

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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

On Wednesday, September 20, 2017 at 6:34:04 AM UTC-7, Kurt Roeckx wrote:
> On 2017-09-20 01:09, Kathleen Wilson wrote:
> >  Forwarded Message 
> > Subject: Summary of September 2017 Audit Reminder Emails
> > Date: Tue, 19 Sep 2017 19:00:08 + (GMT)
> > 
> > Mozilla: Overdue Audit Statements
> > Root Certificates:
> > Autoridad de Certificacion Firmaprofesional CIF A62634068
> > Standard Audit: https://cert.webtrust.org/SealFile?seal=2032=pdf
> > Audit Statement Date: 2016-04-11
> > BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981
> > BR Audit Statement Date: 2016-08-05
> > EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982
> > EV Audit Statement Date: 2016-08-05
> > CA Comments: BR and EV audits have happened, but there are action plans 
> > being presented to the auditors. Primary issues are use of UTF8 instead of 
> > PrintableString in jurisdictionOfIncorporation, and a recently repealed 
> > Spanish law that required privat
> 
> Does that mean the standard audit did not happen? The currently linked 
> one covered the period 2015-03-10 to 2016-03-09. The next period of 1 
> year is now over for more than 6 months.
> 
> If the audits happened, why don't we have the audit statement yet?
> 

I'll contact the CA, and ask them to respond.

I noticed that for the audit reminders the program was sending to the email 
alias only, so I've asked my Salesforce consultant to make sure the Primary 
POC(s) are always in the 'To' list for the emails. However, it is the CA's 
responsibility to provide their updated audit statements, so not receiving the 
audit reminder email does not excuse them.


> > Mozilla: Audit Reminder
> > Root Certificates:
> > Chambers of Commerce Root
> > Chambers of Commerce Root - 2008
> > Global Chambersign Root
> > Global Chambersign Root - 2008
> > Standard Audit: 
> > https://bug986854.bmoattachments.org/attachment.cgi?id=8775118
> > Audit Statement Date: 2016-06-17
> > BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807
> > BR Audit Statement Date: 2016-08-05
> > EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811
> > EV Audit Statement Date: 2016-08-05
> > CA Comments: null
> 
> The standard audit was for the period of 2015-04-14 to 2016-04-13, and 
> so are also late with their audit.

I'll contact the CA...


> 
> > Mozilla: Audit Reminder
> > Root Certificates:
> > GlobalSign ECC Root CA - R5
> > Standard Audit: https://cert.webtrust.org/SealFile?seal=2287=pdf
> > Audit Statement Date: 2017-07-26
> > BR Audit: https://bug1388488.bmoattachments.org/attachment.cgi?id=8895040
> > BR Audit Statement Date: 2017-07-26
> > EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf
> > EV Audit Statement Date: 2016-06-10
> > CA Comments: null
> 
> The EV period was from 2015-04-01 to 2013-03-31. The others are new, 
> maybe forgot to update something?


Bug in CCADB. I am waiting for my Salesforce consultant to confirm that she has 
replicated the bug in Sandbox, and then I will fix the data in Production.


> 
> > Mozilla: Audit Reminder
> > Root Certificates:
> > Certum Trusted Network CA 2**
> > Certum Trusted Network CA**
> > 
> > ** Audit Case in the Common CA Database is under review for this root 
> > certificate.
> > 
> > Standard Audit: https://cert.webtrust.org/SealFile?seal=2064=pdf
> > Audit Statement Date: 2016-06-10
> > BR Audit: https://cert.webtrust.org/SealFile?seal=2066=pdf
> > BR Audit Statement Date: 2016-06-10
> > EV Audit: https://cert.webtrust.org/SealFile?seal=2065=pdf
> > EV Audit Statement Date: 2016-06-10
> > CA Comments: null
> 

As noted by the '**' we have received the updated audit statements, and are 
working with the CA on their Audit Case. Since the Audit Case is a new process, 
there is a learning curve for most CAs. 


Kathleen

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

RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

The original Mozilla plan was to distrust around Sep 2018.  We're still 
planning for that date, but would appreciate it if trust was permitted around a 
single intermediate (say the DigiCert Global Trust G2 root?).  If we need to 
use a separate root with no other certs as the transition, we could create one. 
 I know my team would prefer it as the Global Trust G2 root is our primary SHA2 
root.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Wednesday, September 20, 2017 10:21 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy 
 wrote:
>
> The current end-state plan for root cross-signing is provided at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show 
> all of the existing sub CAs along with the new Sub CAs and root signings 
> planned for post-close. Some of these don’t have names so they are lumped in 
> a general “Intermediate” box.
>
> The Global G2 root will become the transition root to DigiCert for customers 
> who can’t move fully to an operational DigiCert roots prior to September 
> 2018. Any customers that require a specific root can use the transition root 
> for as long as they want, realizing that path validation may be an issue as 
> Symantec roots are removed by platform operators. Although we cannot 
> currently move to a single root because of the lack of EV support and trust 
> in non-Mozilla platforms, we can move to the existing three roots in an 
> orderly fashion.
>
> If the agreement closes prior to Dec 1, the Managed CA will never exist. 
> Instead, all issuance will occur through one of the three primary DigiCert 
> roots mentioned above with the exception of customers required to use a 
> Symantec root for certain platforms or pinning. The cross-signed Global root 
> will be only transitory, meaning we’d hope customers would migrate to the 
> DigiCert roots once the systems requiring a specific Symantec roots are 
> deprecated or as path validation errors arise.

Jeremy,

Am I correct that a key input into this plan was the Mozilla plan to fully 
remove the Symantec roots from the trust store before then end of 2018?  Google 
seemed to suggest they would keep trusting them for a longer period with a 
restriction on which subordinate CAs are trusted.

Thanks,
Peter


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: DigiCert-Symantec Announcement

[Peter Bowen via dev-security-policy]

On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy
 wrote:
>
> The current end-state plan for root cross-signing is provided at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show 
> all of the existing sub CAs along with the new Sub CAs and root signings 
> planned for post-close. Some of these don’t have names so they are lumped in 
> a general “Intermediate” box.
>
> The Global G2 root will become the transition root to DigiCert for customers 
> who can’t move fully to an operational DigiCert roots prior to September 
> 2018. Any customers that require a specific root can use the transition root 
> for as long as they want, realizing that path validation may be an issue as 
> Symantec roots are removed by platform operators. Although we cannot 
> currently move to a single root because of the lack of EV support and trust 
> in non-Mozilla platforms, we can move to the existing three roots in an 
> orderly fashion.
>
> If the agreement closes prior to Dec 1, the Managed CA will never exist. 
> Instead, all issuance will occur through one of the three primary DigiCert 
> roots mentioned above with the exception of customers required to use a 
> Symantec root for certain platforms or pinning. The cross-signed Global root 
> will be only transitory, meaning we’d hope customers would migrate to the 
> DigiCert roots once the systems requiring a specific Symantec roots are 
> deprecated or as path validation errors arise.

Jeremy,

Am I correct that a key input into this plan was the Mozilla plan to
fully remove the Symantec roots from the trust store before then end
of 2018?  Google seemed to suggest they would keep trusting them for a
longer period with a restriction on which subordinate CAs are trusted.

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

Re: Public trust of VISA's CA

[Peter Bowen via dev-security-policy]

On Wed, Sep 20, 2017 at 12:37 AM, Martin Rublik via
dev-security-policy  wrote:
> On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> https://crt.sh/mozilla-certvalidations?group=version=896972 is a very
>> informative graph for me -- this is the number of validations performed by
>> Firefox for certs under this CA. It looks like at the absolute peak, there
>> were 1000 validations in a day. That's very little value for our users, in
>> return for an awful lot of risk.
>>
>> Alex
>
>
> Hi,
>
> I agree that 1000 validations in a day is not much, or better to say really
> low number. Anyway I was wondering what should be a minimum value or
> whether this number is a good metric at all. I went through the Mozilla
> validations telemetrics and there are more CAs with similliar number of
> validations.

Note that Firefox 55 had a regression on how it does chain building
(https://bugzilla.mozilla.org/show_bug.cgi?id=1400913) that causes it
prefer the longest chain rather than the shortest chain.  This means,
for Root CAs that are cross-signed, Firefox 55 will frequently
attribute to the wrong bucket.  The total on the buckets does not
change, but the validations per day did shift.  For example, Firefox
55 shows "AddTrust External CA Root" is a super popular root while
prior versions had "COMODO RSA Certification Authority" as a top root.
"Go Daddy Class 2 CA" and "Go Daddy Root Certificate Authority - G2"
also flipped in Firefox 55.

This does not impact the Visa bucket, as far as I know, as the Visa
root is not cross-signed by any other root.

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

Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

[Dmitry Belyavsky via dev-security-policy]

Dear Nikos

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos 
wrote:

>
> 4. How do you handle extensions to this format?
>
> Overall, why not use X.509 extensions to store such additional
> constraints? We already (in the p11-kit trust store in Fedora/RHEL
> systems) use the notion of stapled extensions to limit certificates
> [0, 1] and seems quite a flexible approach. Have you considered that
> path?
>
> regards,
> Nikos
>
> [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/
> storing-trust-model.html
> [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-
> certificates.html
>

I've looked through the specification. It's OK for me, but I do not get
whether the attached extensions are crypto-protected.
I'm ready to cooperate with you if there is any interest.

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

Re: DigiCert-Symantec Announcement

[James Burton via dev-security-policy]

Hi Jeremy,

Is DigiCert planning on continuing selling DV certificates after the 
transition? As DigiCert has previously been vocal on the fact that the 
drawbacks of issuing DV certificates outweigh the benefits as stated here: 
https://www.digicert.com/dv-ssl-certificate.htm. If DigiCert is going to issue 
DV certificates which root or roots are you going to dedicated for the 
certificates?

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

RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Thanks a ton, Ryan! This was very helpful, and we really appreciate the 
feedback and suggestions.  Here’s what we currently use as publicly-trusted 
roots and how we use them:

 

1.  Baltimore CyberTrust Root – Expires in 2025. Currently only used to 
support Verizon customers who have not transitioned to DigiCert’s roots for 
whatever reason (SubCAs, Pinned keys, etc)
2.  CyberTrust Global Root – Expires in 2021 (I think) and used primarily 
in Japan.  This is our EV root for customers who need trust in Japanese systems.
3.  DigiCert Assured ID Root CA –  RSA root that issues primarily client 
certs and code signing certificates. The root is trusted in Adobe and 
cross-signed by the FBCA (one-way trust). Although it issues some TLS certs, 
these TLS are only issued when a special cross-certification is required that 
is no available under the other roots.
4.  DigiCert Assured ID Root G2 – RSA rollover root for the Assured ID 
root. Once sufficient ubiquity exists, the plan is to retire the Assured ID 
Root in favor of this one.
5.  DigiCert Assured ID Root G3 – ECC version of the G2 root. This root is 
for entities who want a complete ECC chain.
6.  DigiCert Global Root CA – RSA root that is used for OV and code signing 
certificates. This is our primary issuing root and is cross-signed by Baltimore 
for additional ubiquity. 
7.  DigiCert Global Root G2 – RSA rollover root intended to replace the 
Global Root CA.
8.  DigiCert Global Root G3 – ECC version of the G2 root used to support 
entities who want a complete ECC chain
9.  DigiCert High Assurance EV Root CA – Our only EV root until this bug is 
complete: https://bugzilla.mozilla.org/show_bug.cgi?id=1165472.  This root is 
primarily used for entities who want one or more EV certificates and is 
cross-signed by the Baltimore root for ubiquity.
10. DigiCert Trusted Root CA – A 4096 bit root in case 2048 is no longer 
sufficient. This is cross-signed by the Global Root.

 

Symantec has the following roots according to CCADB. Symantec would have to 
comment on how these are used.

1.  Symantec Class 1 G4
2.  Symantec Class 1 G6
3.  Symantec Class 2 G4
4.  Symantec Class 2 G6
5.  Symantec Class 3 G4
6.  Symantec Class G6
7.  Symantec Enterprises Mobile
8.  Equifax Secure Certificate Authority
9.  Equifax Secure eBusiness CA-1 
10. Equifax Secure Global eBusiness CA-1
11. GeoTrust Global CA
12. GeoTrust Global CA 2
13. GeoTrust Primary Certificate Authority
14. GeoTrust Primary Certificate Authority – G2
15. GeoTrust Primary Certificate Authority – G3
16. GeoTrust Universal CA
17. GeoTrust Universal CA 2
18. Thawte Premium Server CA
19. Thawte Primary Root CA
20. Thawte Primary Root CA – G2
21. Thawte Primary Root CA – G3
22. Thawte Server CA
23. Thawte Timestamping CA
24. UTN-Userfirst-Network Applications 
25. Verisign Class 1 Public PCA
26. Verisign Class 3 Public Primary Certificate Authority – G4
27. Verisign Class 3 Public Primary Certificate Authority – G5
28. Verisign Class 4 Public Primary Certificate Authority – G3
29. Verisign Time Stamping CA
30. Verisign Universal Root Certificate Authority
31. Verisign4
32. Verisign Class 1 Public PCA – G3
33. Verisign Class 1 Public PCA – G2
34. Verisign Class 2 Public PCA – G3
35. Verisign Class 2 Public PCA – G2
36. Verisign Class 3 Public PCA 
37. Verisign Class 3 Public PCA – MD2
38. Verisign Class 3 Public PCA – G2
39. Verisign Class 2 Public Primary Certification Authority – G3

 

The current end-state plan for root cross-signing is provided at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show 
all of the existing sub CAs along with the new Sub CAs and root signings 
planned for post-close. Some of these don’t have names so they are lumped in a 
general “Intermediate” box.  

 

We reached the same conclusion as you about segmentation by root (that 
compartmentalization by root won’t work), not to mention that 
compartmentalization will be near impossible considering what we’ve previously 
issued and how the roots are trusted in various root programs. Instead, we plan 
on creating sub CAs based on the number of entities using the intermediate.  
For example, every 2000 or so entities will use another Sub CA. This will 
roughly segment customers based on excepted volumes.  We also plan on providing 
a lot more unique intermediates on a per customer basis.  Permitting large 
companies to have a dedicated intermediate will help shield them from being 
revoked if another Sub CA needs to be revoked and allow browsers to selectively 
whitelist/blacklist entities.  Of course, not every company will want this, but 
it’ll be available for anyone who wants it.  

 

The plan, based on your suggestions, is to cross-sign the DigiCert Global G2 
root with the four Symantec roots:

 

1. 

Re: Public trust of VISA's CA

[Martin Rublik via dev-security-policy]

On Tue, Sep 19, 2017 at 5:22 PM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> https://crt.sh/mozilla-certvalidations?group=version=896972 is a very
> informative graph for me -- this is the number of validations performed by
> Firefox for certs under this CA. It looks like at the absolute peak, there
> were 1000 validations in a day. That's very little value for our users, in
> return for an awful lot of risk.
>
> Alex


Hi,

I agree that 1000 validations in a day is not much, or better to say really
low number. Anyway I was wondering what should be a minimum value or
whether this number is a good metric at all. I went through the Mozilla
validations telemetrics and there are more CAs with similliar number of
validations.


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