RE: Certificates with less than 64 bits of entropy

[Ben Wilson via dev-security-policy]

They are working on the issue and preparing a report.  

 

From: Eric Mill [mailto:e...@konklone.com] 
Sent: Saturday, August 12, 2017 9:03 PM
To: Ben Wilson 
Cc: Alex Gaynor ; Jonathan Rudenberg 
; mozilla-dev-security-pol...@lists.mozilla.org; Jeremy 
Rowley 
Subject: Re: Certificates with less than 64 bits of entropy

 

If they're not going to revoke within 24 hours and willingly violate that part 
of the policy, I would at least expect them to, within that 24 hours, produce a 
description of why this happened, what they're doing to fix it, and when they 
expect the certificates to be replaced (along with an expectation of when a 
hard revocation deadline would be regardless of customer responsiveness). Once 
the underlying issue is fixed, I would expect them to ring in to say that it's 
fixed and what they did to fix it. 

 

That's just basic good-faith engagement that demonstrates that the issuing CA 
at least takes the issue as seriously as the community does, and engenders 
trust that the issue is being addressed.

 

Let's Encrypt just responded this week to an encoding compliance failure with a 
live production code fix (including code review and sign off) within 6 hours of 
being notified. 

 

While not every issuing CA may take security seriously enough to employ 
engineers on staff who can research, author and deploy a production code fix in 
a 24 hour period, every issuing CA should be able to muster the strength to 
keep the community informed of their plans and progress in however long it 
takes to address the issue.

 

-- Eric

 

On Fri, Aug 11, 2017 at 10:33 AM, Ben Wilson via dev-security-policy 
 > wrote:

Apparently they haven’t yet, but we’ll assume that they will.

Does the community expect a remediation plan for their code and then a 
revocation-and-replacement plan?



Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678  





From: Alex Gaynor [mailto:agay...@mozilla.com  ]
Sent: Friday, August 11, 2017 8:31 AM
To: Ben Wilson  >
Cc: Jeremy Rowley  >; Jonathan Rudenberg 
 >; 
mozilla-dev-security-pol...@lists.mozilla.org 
 
Subject: Re: Certificates with less than 64 bits of entropy



Have they fixed whatever issue there is with their PKI infrastructure that 
leads to this issue? From skimming, I see this pool contains certs issued as 
recently as one month ago.



Alex



On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy 
  
 > > wrote:

With regard to Siemens, given the large number of certificates and the 
disruption that massive revocations will have on their infrastructure, what 
does this community expect them to do?


-Original Message-
From: dev-security-policy [mailto:dev-security-policy-bounces+ben 
  
 > =digicert@lists.mozilla.org 
   > ] On Behalf Of Jeremy Rowley via 
dev-security-policy
Sent: Thursday, August 10, 2017 12:01 PM
To: Jonathan Rudenberg   
 > >; 
mozilla-dev-security-pol...@lists.mozilla.org 
  
 >
Subject: RE: Certificates with less than 64 bits of entropy

Hi Jonathan,

InfoCert's sub CA was revoked on August 1, 2017. We'll reach out to Siemens. 
They moved to Quovadis a while ago and are no longer issuing from that Sub CA.

Jeremy

-Original Message-
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley 
  
 > 
=digicert@lists.mozilla.org   
 
> ] On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Thursday, August 10, 2017 9:26 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
  

Re: Certificates with less than 64 bits of entropy

[Eric Mill via dev-security-policy]

If they're not going to revoke within 24 hours and willingly violate that
part of the policy, I would at least expect them to, within that 24 hours,
produce a description of why this happened, what they're doing to fix it,
and when they expect the certificates to be replaced (along with an
expectation of when a hard revocation deadline would be regardless of
customer responsiveness). Once the underlying issue is fixed, I would
expect them to ring in to say that it's fixed and what they did to fix it.

That's just basic good-faith engagement that demonstrates that the issuing
CA at least takes the issue as seriously as the community does, and
engenders trust that the issue is being addressed.

Let's Encrypt just responded this week to an encoding compliance failure
with a live production code fix (including code review and sign off) within
6 hours of being notified.

While not every issuing CA may take security seriously enough to employ
engineers on staff who can research, author and deploy a production code
fix in a 24 hour period, every issuing CA should be able to muster the
strength to keep the community informed of their plans and progress in
however long it takes to address the issue.

-- Eric

On Fri, Aug 11, 2017 at 10:33 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Apparently they haven’t yet, but we’ll assume that they will.
>
> Does the community expect a remediation plan for their code and then a
> revocation-and-replacement plan?
>
>
>
> Ben Wilson, JD, CISA, CISSP
>
> VP Compliance
>
> +1 801 701 9678
>
>
>
>
>
> From: Alex Gaynor [mailto:agay...@mozilla.com]
> Sent: Friday, August 11, 2017 8:31 AM
> To: Ben Wilson 
> Cc: Jeremy Rowley ; Jonathan Rudenberg <
> jonat...@titanous.com>; mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with less than 64 bits of entropy
>
>
>
> Have they fixed whatever issue there is with their PKI infrastructure that
> leads to this issue? From skimming, I see this pool contains certs issued
> as recently as one month ago.
>
>
>
> Alex
>
>
>
> On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org  sts.mozilla.org> > wrote:
>
> With regard to Siemens, given the large number of certificates and the
> disruption that massive revocations will have on their infrastructure, what
> does this community expect them to do?
>
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bounces+ben  dev-security-policy-bounces%2Bben> =digicert@lists.mozilla.org
>  ] On Behalf Of Jeremy Rowley via
> dev-security-policy
> Sent: Thursday, August 10, 2017 12:01 PM
> To: Jonathan Rudenberg  >; mozilla-dev-security-pol...@lists.mozilla.org
> 
> Subject: RE: Certificates with less than 64 bits of entropy
>
> Hi Jonathan,
>
> InfoCert's sub CA was revoked on August 1, 2017. We'll reach out to
> Siemens. They moved to Quovadis a while ago and are no longer issuing from
> that Sub CA.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bo
> unces+jeremy.rowley  =
> digicert@lists.mozilla.org  ]
> On Behalf Of Jonathan Rudenberg via dev-security-policy
> Sent: Thursday, August 10, 2017 9:26 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org  mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Certificates with less than 64 bits of entropy
>
>
> > On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org  sts.mozilla.org> > wrote:
> >
> > QuoVadis (560)
> >Siemens Issuing CA Internet Server 2016 (560)
> >
> > D-TRUST (224)
> >D-TRUST SSL Class 3 CA 1 2009 (178)
> >D-TRUST SSL Class 3 CA 1 EV 2009 (45)
> >D-TRUST Root Class 3 CA 2 EV 2009 (1)
> >
> > DigiCert (85)
> >Siemens Issuing CA Class Internet Server 2013 (82)
> >InfoCert Web Certification Authority (3)
> >
> > Izenpe S.A. (62)
> >EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)
> >
> > Government of The Netherlands, PKIoverheid (Logius) (55)
> >Digidentity Services CA - G2 (55)
> >
> > Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
> >Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)
>
> It looks like my summary missed one QuoVadis intermediate:
>
> Bayerische SSL-CA-2016-01 (3)
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org  sts.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> 

RE: Certificates with reserved IP addresses

[Ben Wilson via dev-security-policy]

We’ll look into these on Monday and get back to you.  

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Saturday, August 12, 2017 8:56 PM
To: Ben Wilson 
Cc: Jonathan Rudenberg ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with reserved IP addresses

 

Do you have an estimate on when you can provide an explanation to the community 
about how/why this happened, how many certificates it affected, and what steps 
DigiCert is taking to prevent these issues in the future? Do you have details 
about why DigiCert failed to detect these, and what steps DigiCert has in place 
to ensure compliance from its subordinate CAs?

 

On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy 
 > wrote:

Thanks.  We've sent an email to the operators of the first two CAs (TI Trust 
Technologies and Cybertrust Japan) that they need to revoke those certificates.
Thanks again,
Ben


-Original Message-
From: dev-security-policy [mailto:dev-security-policy-bounces+ben 
 =digicert@lists.mozilla.org 
 ] On Behalf Of Jonathan Rudenberg via 
dev-security-policy
Sent: Saturday, August 12, 2017 7:53 PM
To: mozilla-dev-security-pol...@lists.mozilla.org 
 
Subject: Certificates with reserved IP addresses

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
containing IANA reserved IP addresses and any certificates containing them 
should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and 
trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates 
contain dnsNames with internal names, which are prohibited under the same BR 
section.

Jonathan
___
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

More certificates with invalid dnsNames

[Jonathan Rudenberg via dev-security-policy]

I’ve found 54 additional unexpired unrevoked certificates that are known to CT 
and trusted by NSS containing dnsNames that are invalid. The errors include 
invalid characters, internal names, and wildcards in the wrong position.

The full list is here: https://misissued.com/batch/8/

There are a few threads from the past few weeks about similar certificates, but 
as far as I know none of the certificates on this list have been discovered yet.

I’ve included a summary of the CCADB owners and intermediates at the end of 
this email.

Jonathan

—

DigiCert (18)
TI Trust Technologies Global CA (16)
Justica (1)
WellsSecure Certification Authority 01 G2 (1)

DocuSign (OpenTrust/Keynectis) (10)
CLASS 2 KEYNECTIS CA (8)
KEYNECTIS SSL RGS (2)

AC Camerfirma, S.A. (4)
AC CAMERFIRMA AAPP (2)
Camerfirma Corporate Server II - 2015 (2)

Certinomis (4)
Certinomis - Easy CA (2)
Certinomis Serveurs et Equipements (2)

Symantec / VeriSign (3)
Symantec Class 3 Secure Server CA - G4 (2)
Symantec Class 3 Secure Server SHA256 SSL CA (1)

Visa
Visa eCommerce Issuing CA (2)

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
EC-SectorPublic (2)

Taiwan-CA Inc. (TWCA)
TWCA Secure SSL Certification Authority (1)

WoSign CA Limited
StartCom Class 3 OV Server CA (1)

CA Disig a.s.
CA Disig R2I2 Certification Service (1)

Actalis
Actalis Authentication CA G3 (1)

PROCERT
PSCProcert (1)

Comodo
Intel External Basic Issuing CA 3B (1)

Izenpe S.A.
EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (1)

WISeKey
WISeKey CertifyID Advanced Services CA 4 (1)

T-Systems International GmbH (Deutsche Telekom)
Uni-Osnabrueck RZ-CA G-002 (1)

QuoVadis
QuoVadis Global SSL ICA G2 (1)

Symantec / GeoTrust
RapidSSL SHA256 CA - G3 (1)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with reserved IP addresses

[Ryan Sleevi via dev-security-policy]

Do you have an estimate on when you can provide an explanation to the
community about how/why this happened, how many certificates it affected,
and what steps DigiCert is taking to prevent these issues in the future? Do
you have details about why DigiCert failed to detect these, and what steps
DigiCert has in place to ensure compliance from its subordinate CAs?

On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks.  We've sent an email to the operators of the first two CAs (TI
> Trust Technologies and Cybertrust Japan) that they need to revoke those
> certificates.
> Thanks again,
> Ben
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bounces+ben=
> digicert@lists.mozilla.org] On Behalf Of Jonathan Rudenberg via
> dev-security-policy
> Sent: Saturday, August 12, 2017 7:53 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Certificates with reserved IP addresses
>
> Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from
> containing IANA reserved IP addresses and any certificates containing them
> should have been revoked by 2016-10-01.
>
> There are seven unexpired unrevoked certificates that are known to CT and
> trusted by NSS containing reserved IP addresses.
>
> The full list can be found at: https://misissued.com/batch/7/
>
> DigiCert
> TI Trust Technologies Global CA (5)
> Cybertrust Japan Public CA G2 (1)
>
> PROCERT
> PSCProcert (1)
>
> It’s also worth noting that three of the "TI Trust Technologies”
> certificates contain dnsNames with internal names, which are prohibited
> under the same BR section.
>
> Jonathan
> ___
> 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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with reserved IP addresses

[Jeremy Rowley via dev-security-policy]

The CTJ one was issued in 2013 and is a five year cert (which was also 
prohibited under the BRs at that time_.  It should have been revoked much 
earlier, of course.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Saturday, August 12, 2017 7:53 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Certificates with reserved IP addresses

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
containing IANA reserved IP addresses and any certificates containing them 
should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and 
trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates 
contain dnsNames with internal names, which are prohibited under the same BR 
section.

Jonathan
___
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: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

[Eric Mill via dev-security-policy]

On Fri, Aug 11, 2017 at 5:20 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> If one integrates a project like certlint/cablint into the cert issuance
> pipeline, one suddenly takes on supplemental responsibility for certlint's
> bugs or changes.
>

That's the case for any source code Let's Encrypt uses that was written by
someone else. Like all software, there are third party dependencies in
there somewhere, whether closed source or open source. (In Let's Encrypt's
case, they are generally open source, which helps the team's ability to
review it.)


> The pace of change in certlint, just glancing at the git commits, is not
> slow.  New tests are added.  Tests are revised.
>

That's a good thing.

Even still... anywhere along the way, Mr. Bowen could go totally evil (I
> seriously doubt this would happen) and decide that certlint should flag "E:
> This CA is run by nasty people" anytime Issuer CN contains 'Maligned CA X1'.
>

You seem to be assuming that Let's Encrypt would just automatically pull
down new code into its critical issuance code path without review. I would
definitely not assume that. That code will be reviewed before deployment.


> It seems reasonable to me that an implementing CA might want to add some
> buffer between the initial commit/merge and their opportunity to perform
> some manual review of the changes prior to incorporating into their
> issuance environment.
>

Yes, of course.

This is a lot of time to spend discussing the basics of project dependency
management. There are definitely tradeoffs for Let's Encrypt to evaluate
when considering something like integrating certlint into the issuance
pipeline -- performance of the certlint tool, potential memory leaks, as
well as the operations necessary to support a hosted service that keeps
certlint in memory for rapid processing.

If certlint proves to be too slow or take too much memory, then an
integration push could either cause those issues to be fixed, or cause a
new tool to be written that performs the same checks certlint does (now
that the work has been done to map and isolate the BRs into specific
technical checks).

We should be understanding if engineering tradeoffs preclude immediate
integration, but we should not dismiss the idea of relying on "someone
else's code" in the issuance pipeline. I'm sure that's already the case for
every CA in operation today.

-- Eric


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



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

Re: Certificates with reserved IP addresses

[Peter Bowen via dev-security-policy]

Congratulations on finding something not caught by certlint.  It turns
out that cabtlint does zero checks for reserved IPs.  Something else
for my TODO list.

On Sat, Aug 12, 2017 at 6:52 PM, Jonathan Rudenberg via
dev-security-policy  wrote:
> Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
> containing IANA reserved IP addresses and any certificates containing them 
> should have been revoked by 2016-10-01.
>
> There are seven unexpired unrevoked certificates that are known to CT and 
> trusted by NSS containing reserved IP addresses.
>
> The full list can be found at: https://misissued.com/batch/7/
>
> DigiCert
> TI Trust Technologies Global CA (5)
> Cybertrust Japan Public CA G2 (1)
>
> PROCERT
> PSCProcert (1)
>
> It’s also worth noting that three of the "TI Trust Technologies” certificates 
> contain dnsNames with internal names, which are prohibited under the same BR 
> section.
>
> Jonathan
> ___
> 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

RE: Certificates with reserved IP addresses

[Ben Wilson via dev-security-policy]

Thanks.  We've sent an email to the operators of the first two CAs (TI Trust 
Technologies and Cybertrust Japan) that they need to revoke those certificates.
Thanks again,
Ben

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Saturday, August 12, 2017 7:53 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Certificates with reserved IP addresses

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
containing IANA reserved IP addresses and any certificates containing them 
should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and 
trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates 
contain dnsNames with internal names, which are prohibited under the same BR 
section.

Jonathan
___
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

Certificates with reserved IP addresses

[Jonathan Rudenberg via dev-security-policy]

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
containing IANA reserved IP addresses and any certificates containing them 
should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and 
trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates 
contain dnsNames with internal names, which are prohibited under the same BR 
section.

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

Re: Symantec Update on SubCA Proposal

[Nick Lamb via dev-security-policy]

One good thing we should be able to hope for from a change in ownership even if 
the personnel and equipment are the same or a great deal in common: improved 
management oversight. In my view the most worrying underlying problem at 
Symantec was the inadequate oversight. Senior management at the corporation 
just can't have been giving this the attention it needs. The sale takes them 
out of the picture. That's not a great story for Symantec's shareholders, who 
might reasonably assume that similarly inadequate oversight will continue for 
the other activities of the business - but it's good news for the Relying 
Parties.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

Andrew. 

Thank you for the review, comments and questions on TrustCor's policy 
documents.  

We are in the process of reviewing your comments and formulating a response to 
each.  We will provide our response and updates before EOB Tuesday, August 
15th, published to this discussion list.

Have a great weekend,

Neil Dunbar,
TrustCor CA Administrator

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> Greetings,
> 
> I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
> following notes:
> 
> *CP* (http://www.trustcor.ca/resources/cp.pdf)
> 
> 1.6.3
> 1.6.4
> Nit:
> Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
> TrustCor CA makes no authoritative statement, will have either the text “No
> stipulation” or “Not Applicable”." but these sections are just blank.
> 
> 3.3.1
> "Level 2 Client certificates - demonstration of a pre-shared key and OTP
> validation as described in Section 3.2.3 is sufficient to allow re- key."
> however section 3.2.3 makes no mention of pre-shared key and OTP validation.
> 
> 4.4.2 Publication of the certificate by the CA
> Note that is at odds with any future CT requirement.
> 
> 6.1.5
> "OCSP responses may respond using the SHA-1 hash if the request used
> SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
> (section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
> TrustCor does not, and never has, used SHA-1 as a component of any
> signature algorithm on a certificate.
> 
> 6.1.6
> This section references version 1.3.0 of the BRs, which date from 2015.
> 
> *CPS* (http://www.trustcor.ca/resources/cps.pdf)
> 
> 1.4.1
> The maximum validity of the different certificate types, while within
> what's allowed by the BRs, aren't consistent with the limits specified in
> section 6.3.2 of the CP (e.g. 12 months vs 398 days).
> 
> 2.2
> https://catest1-revoked.trustcor.ca/ is not resolving.
> https://catest1-expired.trustcor.ca/ is not resolving.
> https://catest2-revoked.trustcor.ca/ is not resolving.
> https://catest2-expired.trustcor.ca/ is not resolving.
> 
> 2.2.1
> Commitment to make incident reports public - very good.
> (Note that at the moment
> https://www.trustcor.ca/resources/issuance-incidents/ currently just
> redirects to the home page)
> 
> 3.2.2.4.7
> Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
> will *query* the authoritative DNS servers"
> 
> 3.2.2.8
> Fail shut CAA - good
> 
> 3.2.6
> While it's good that TrustCor will publish cross-signed certificates it
> issues to other CAs, my understanding of section 3.2.6 of the BRs is that
> it requires cross certifications that a CA obtains from other CAs (i.e.
> where it is the Subject of the cert) to be published.
> 
> 4.9.1.1
> Even though section 4.9.2 states that a subscriber can request revocation
> of their certificate, 4.9.1.1 does not list a subscriber request as a
> reason for revocation.
> 
> 4.9.1.2
> I would like to hope that there are technical, not just business, controls
> in place to limit the actions an "insufficiently aware staff member" could
> perform.
> 
> 7.1.2.2
> Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
> MUST be present and SHOULD NOT be marked critical." for Subordinate CA
> Certificates, however this section implies that certificatePolicies is only
> specified for Enterprise Subordinate CAs.
> 
> 7.1.2.3
> For the Secure Mail profiles, the subjectAlternativeName is defined as
> containing an "emailAddress". Should this not be rfc822Name?
> 
> 7.1.2.4
> It seems odd that this section references itself and 7.1.2.5.  Where these
> meant to be 7.1.2.2 and 7.1.2.3?
> 
> The CP requires the subject key identifier and authority key identifier
> extensions, but these are not specified in the cert profiles in the CPS.
> 
> 7.1.6.3
> This seems at odds with 7.1.2.2 of the BRs.
> 
> Those comments aside, I found both documents clear, well written, and they
> provided sufficient detail to assess the policies in place.
> 
> Many thanks,
> 
> Andrew
> ___
> 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

Re: Symantec Update on SubCA Proposal

[wizard--- via dev-security-policy]

Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla. 

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan. 

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated. 

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Devon O'Brien via dev-security-policy
> > Sent: Wednesday, August 09, 2017 12:24 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec Update on SubCA Proposal
> >
> > Hello m.d.s.p.,
> >
> > I'd just like to give the community a heads up that Chrome’s plan remains to
> > put up a blog post echoing our recent announcement on blink-dev [1], but
> > in the meantime, we are reviewing the facts related to Symantec’s sale of
> > their PKI business to DigiCert [2].
> >
> > Recently, it has come to our attention that Symantec may have selected
> > DigiCert from the RFP process to become a Managed CA Partner. As defined
> > in Google’s first Managed CA proposal [3], then supported by Symantec’s
> > commitment to “[cover] all aspects of the SubCA proposal” [4], and finally
> > reiterated in Google’s final proposal [1], the requirement has always been
> > that the Managed Partner Infrastructure be operated by an independent
> > and non-affiliated CA while Symantec worked to rebuild the web
> > community's confidence.
> >
> > Based on this information, we have a series of questions that we’d like
> > Symantec to address for public discussion:
> >
> > 1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner
> > under the RFP process? If so, in light of DigiCert’s acquisition of 
> > Symantec’s
> > PKI business and Symantec’s substantial equity investment in DigiCert, can
> > you explain how you believe selecting DigiCert as the Managed CA Partner
> > meets the stated requirement of being an independent and non-affiliated
> > organization?
> >
> 
> Before we initiated our SubCA RFP process in May, Google provided Symantec 
> with a list of Certificate Authorities, including DigiCert, which met the 
> eligibility requirements of a Managed CA under the SubCA proposal.   Symantec 
> conducted a thorough SubCA RFP process and believes DigiCert can credibly 
> meet browser requirements and timelines.
> 
> Symantec decided it was in the best interests of all of its stakeholders to 
> sell its Website Security and related PKI solutions to DigiCert. To ensure 
> business continuity for customers, Symantec entered into a SubCA arrangement 
> with DigiCert simultaneous with entry into the definitive acquisition 
> agreement to account for the possibility that the acquisition may not close 
> by December 1, 2017.
> 
> Regardless of whether the acquisition closes before December 1, 2017 or not, 
> there is never a circumstance under which DigiCert will be an 'affiliate' of 
> Symantec with respect to acting as Symantec's Managed CA under the SubCA 
> proposal.  Symantec currently has no ownership interest in or ability 
> (contractual or otherwise) to control the operations of DigiCert, nor does 
> either party otherwise constitute an 'affiliate' of the other, as such term 
> is defined in the CA-Browser Forum Baseline Requirements (v 1.4.9).
> 
> At the closing of the acquisition, Symantec is being paid in both cash and 
> stock, with the latter comprising a 30% ownership interest in the common 
> equity of DigiCert, which allows for Symantec stockholders to benefit from 
> the potential value created by the DigiCert business after 

Re: TrustCor root inclusion request

[Neil Dunbar via dev-security-policy]

Andrew. 

Thank you for the review, comments and questions on TrustCor's policy 
documents.  

We are in the process of reviewing your comments and formulating a response to 
each.  We will provide our response and updates before EOB Tuesday, August 
15th, published to this discussion list.

Have a great weekend,

Neil Dunbar,
TrustCor CA Administrator

> On 10 Aug 2017, at 23:54, Andrew R. Whalley via dev-security-policy 
>  wrote:
> 
> Greetings,
> 
> I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
> following notes:
> 
> *CP* (http://www.trustcor.ca/resources/cp.pdf)
> 
> 1.6.3
> 1.6.4
> Nit:
> Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
> TrustCor CA makes no authoritative statement, will have either the text “No
> stipulation” or “Not Applicable”." but these sections are just blank.
> 
> 3.3.1
> "Level 2 Client certificates - demonstration of a pre-shared key and OTP
> validation as described in Section 3.2.3 is sufficient to allow re- key."
> however section 3.2.3 makes no mention of pre-shared key and OTP validation.
> 
> 4.4.2 Publication of the certificate by the CA
> Note that is at odds with any future CT requirement.
> 
> 6.1.5
> "OCSP responses may respond using the SHA-1 hash if the request used
> SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
> (section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
> TrustCor does not, and never has, used SHA-1 as a component of any
> signature algorithm on a certificate.
> 
> 6.1.6
> This section references version 1.3.0 of the BRs, which date from 2015.
> 
> *CPS* (http://www.trustcor.ca/resources/cps.pdf)
> 
> 1.4.1
> The maximum validity of the different certificate types, while within
> what's allowed by the BRs, aren't consistent with the limits specified in
> section 6.3.2 of the CP (e.g. 12 months vs 398 days).
> 
> 2.2
> https://catest1-revoked.trustcor.ca/ is not resolving.
> https://catest1-expired.trustcor.ca/ is not resolving.
> https://catest2-revoked.trustcor.ca/ is not resolving.
> https://catest2-expired.trustcor.ca/ is not resolving.
> 
> 2.2.1
> Commitment to make incident reports public - very good.
> (Note that at the moment
> https://www.trustcor.ca/resources/issuance-incidents/ currently just
> redirects to the home page)
> 
> 3.2.2.4.7
> Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
> will *query* the authoritative DNS servers"
> 
> 3.2.2.8
> Fail shut CAA - good
> 
> 3.2.6
> While it's good that TrustCor will publish cross-signed certificates it
> issues to other CAs, my understanding of section 3.2.6 of the BRs is that
> it requires cross certifications that a CA obtains from other CAs (i.e.
> where it is the Subject of the cert) to be published.
> 
> 4.9.1.1
> Even though section 4.9.2 states that a subscriber can request revocation
> of their certificate, 4.9.1.1 does not list a subscriber request as a
> reason for revocation.
> 
> 4.9.1.2
> I would like to hope that there are technical, not just business, controls
> in place to limit the actions an "insufficiently aware staff member" could
> perform.
> 
> 7.1.2.2
> Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
> MUST be present and SHOULD NOT be marked critical." for Subordinate CA
> Certificates, however this section implies that certificatePolicies is only
> specified for Enterprise Subordinate CAs.
> 
> 7.1.2.3
> For the Secure Mail profiles, the subjectAlternativeName is defined as
> containing an "emailAddress". Should this not be rfc822Name?
> 
> 7.1.2.4
> It seems odd that this section references itself and 7.1.2.5.  Where these
> meant to be 7.1.2.2 and 7.1.2.3?
> 
> The CP requires the subject key identifier and authority key identifier
> extensions, but these are not specified in the cert profiles in the CPS.
> 
> 7.1.6.3
> This seems at odds with 7.1.2.2 of the BRs.
> 
> Those comments aside, I found both documents clear, well written, and they
> provided sufficient detail to assess the policies in place.
> 
> Many thanks,
> 
> Andrew
> ___
> 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