Re: Symantec Conclusions and Next Steps

2017-04-25 Thread Ryan Sleevi via dev-security-policy
Continuing to look through the audits, I happened to notice a few other
things that stood out, some more pressing than others.

More pressing:
I can find no disclosure with Salesforce or crt.sh of at least two CAs that
are listed 'in scope' of the audit report, as part of
https://www.symantec.com/content/en/us/about/media/
repository/Symantec-NFSSP-WTCA_11-30-2016.pdf

This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
CA2" as within scope for this audit. It would be useful to understand their
lack of disclosure, relative to the audits and to Section 5.3.2 of the
inclusion policy.

Less pressing (as it relates to e-mail):
One other question with disclosing audits: My understanding of
https://www.mozilla.org/en-US/about/governance/policies/
security-group/certs/policy/ , particularly Section 5.3.2 and Section
3.1.2.1, is that for CA certificates that are enabled for the email trust
bit, the CA, and all subordinate CAs capable of issuing e-mail
certificates, must have a WebTrust for CAs audit, and must be publicly
disclosed, is that correct?

Looking through CAs such as https://crt.sh/?caid=598 , which is disclosed (
https://crt.sh/?id=68409 ), it seems there are a substantial number of
subordinate CAs capable of issuing e-mail certificates that are not
disclosed. I thought this might be due to scaling the CCADB, but I note
that Microsoft's Trusted Root Requirements have required the same audits (
https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-
trusted-root-certificate-program-audit-requirements.aspx#A_WebTrust_Audits )
for some time. Do you or Kathleen know the status of these disclosures and
audits?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Criticism of Google Re: Google Trust Services roots

2017-04-25 Thread Peter Kurrasch via dev-security-policy
Sure, happy to take a look. I think Ryan H. makes some good points and I'm not 
entirely opposed to acquisitions or transfers. My standpoint is that when a 
transfer is to take place, can we be sure that the right things do happen 
instead of leaving things to chance? It's the age old problem of encouraging 
the good and preventing the bad.


  Original Message  
From: Gervase Markham
Sent: Tuesday, April 25, 2017 4:28 AM
To: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

Hi Peter,

On 25/04/17 02:10, Peter Kurrasch wrote:
> Fair enough. I propose the following for consideration:

As it happens, I have been working on encoding:
https://wiki.mozilla.org/CA:RootTransferPolicy
into our policy. A sneak preview first draft is here:

https://github.com/mozilla/pkipolicy/compare/issue-57

Would you be kind enough to review that and see if it addresses your
points and, if not, suggest how it might change and why?

I can see the value of a "definition of intention" and the choosing of a
category, as long as we are careful to make sure the categories do not
preclude operations that we would like to see occur. As Ryan Hurst
notes, there is potentially significant value to the ecosystem in root
transfers.

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


Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

2017-04-25 Thread douglas.beattie--- via dev-security-policy
Misissuance Report

On February 25th 2017, we received a report that there was a SAN in an 
Incapsula OV certificate (specifically an OV certificate issued via the 
GlobalSign CloudSSL product) for a domain that is no longer registered 
(testsslfeb20.me).


1) GlobalSign CloudSSL product description

To help clarify what we mean by GlobalSign CloudSSL product we wanted to 
describe the different operations CloudSSL customers can perform.  CloudSSL 
supports New, Update, Reissue and Renew operations which all result in a new 
certificate being created. 

* New: We perform a manual organization validation on the initial CloudSSL OV 
certificate and CommonName.  We assign a new OrderID.

* Update: Customers can request the addition and removal of SANs.  When a SAN 
is added, it is validated (in accordance with one of the approved domain 
validation methods) and then when the Update command is called, a new 
certificate with the requested changes is issued.  The issued certificate has 
the same Subject DN, expiration date and OrderID. 

* Renew: When a CloudSSL order is renewed, it retains the same OrderID and 
Subject DN  but the validity period is extended by 1-2 years.

* Reissue: When a CloudSSL certificate is Reissued, it receives a new OrderID, 
but contains the same Subject DN, cert expiration date and SANs.

* Revocation: The GlobalSign CA performs revocation by OrderID. This revokes 
all certificates in the Order which could be hundreds for CloudSSL orders.  
CloudSSL is the only GlobalSign SSL product where multiple certificates are 
issued against the same OrderID.

In general, CloudSSL customers need large multi-domain SSL certificates which 
have SANs added and removed to support their changing customer needs.  As such, 
updating certificates is a more frequent activity that with any other 
GlobalSign SSL products.


2) Incapsula certificates issued with testslsslfeb20.me

We investigated this order and determined that this domain was verified when 
the certificate was first issued on 3/31/2014. While this order was issued and 
subsequently updated and reissued a number of times without breaking the 39 
month certificate data re-use period, it’s clear that based on this report the 
domain is no longer controlled by Incapsula. At the conclusion of this analysis 
we revoked two OrderIDs that contained this SAN which resulted in the 
revocation of 26 certificates with this SAN.

All unexpired certificates with this SAN are now revoked as can be seen on the 
page:
https://crt.sh/?dNSName=testslsslfeb20.me


3) Research to verify all domains are being validated every 39 months

After this initial review, we further investigated the time between the initial 
SAN approval and inclusion of the SAN in future certificates.  We found that 
not all SANs have been validated within the prior 39 months due to a product 
bug. CloudSSL was not updated in February 2015 when the 39 month certificate 
data re-use policy was added to the BRs, thus domains were being included in 
reissued certificates without having updated domain verification checks 
performed.  This product was launched in late 2011, so some SANs had reached 
their 39 month limit in February 2015, and some of those continued to be 
included in certificates through March 2017.


4) Resolution

As soon as this was discovered, the system was patched on 3/16 to prevent 
additional certificates from being issued with SANs not validated within the 
prior 39 months.  


5) Follow-up tasks

The reporting interface and capabilities of the CA system to identify and 
revoke the impacted certificates was inadequate to properly locate impacted 
customers and OrderIDs which we needed to process.  While some of them were 
identified and revoked relatively quickly, it took several weeks to set up a 
new database and reporting infrastructure which could be used to load and then 
correlate all of the certificates and SANs with the SAN approval dates and then 
notify customers and perform the revocations.  Several rounds of reporting 
uploads, reporting and customer revocation updates were needed to completely 
capture the list of non-compliant certificates and revoke them.

In summary the following are the final statistics:

* 7 customers
* 79 OrderIDs had certificates revoked
* 945 unique SANs were included in certificates where the domain was not 
verified within the prior 39 months.
* 905 Certificates were issued containing one or more SANs that has not been 
verified within the prior 39 months.  These SANs were either removed from 
future certificates or they were re-validated.

We've been actively working with 17 customers on 146 Orders and about 4000 SANs 
which expired on April 22 in order to comply with the 825 day data reuse 
policy.  Checks were put in place to prevent certificates from being issued 
that contain SANs not validated within the prior 825 days prior to April 20th 
effective date.


6) Future Mitigation plans

While we've put checks in 

Re: Criticism of Google Re: Google Trust Services roots

2017-04-25 Thread Gervase Markham via dev-security-policy
Hi Peter,

On 25/04/17 02:10, Peter Kurrasch wrote:
> Fair enough. I propose the following for consideration:

As it happens, I have been working on encoding:
https://wiki.mozilla.org/CA:RootTransferPolicy
into our policy. A sneak preview first draft is here:

https://github.com/mozilla/pkipolicy/compare/issue-57

Would you be kind enough to review that and see if it addresses your
points and, if not, suggest how it might change and why?

I can see the value of a "definition of intention" and the choosing of a
category, as long as we are careful to make sure the categories do not
preclude operations that we would like to see occur. As Ryan Hurst
notes, there is potentially significant value to the ecosystem in root
transfers.

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