RE: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Nick and Mozilla Community,

Here is the response from Intesa Sanpaolo concerning the disruption that
revocation will cause to their banking operations:

Good Evening Ben,

   About the problem with the certificate you recently notified us, I
confirm you that we have replaced the certificates today, so we have now
revoked the wrong one.

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

We are available to set up a call conference with you to discuss the matter.
Looking forward to hear from you.

Best regards,
Riccardo D'Agostini


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM
To: Nick Lamb <tialara...@gmail.com>;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Certificate with invalid dnsName issued from Baltimore
intermediate

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-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: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing 
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

There are over 300 publicly visible servers, according to Censys.IO.



From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, August 3, 2017 8:42 AM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Nick Lamb <tialara...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore 
intermediate



If I'm reading this correctly, these certificates are for internal services, 
not publicly accessible. Could they add their intermediate directly to these 
trust stores, allowing you to revoke it?



Failing that, it sounds like OneCRL would be an appropriate remedy.



Alex



On Thu, Aug 3, 2017 at 10:38 AM, Ben Wilson via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Nick and Mozilla Community,

Here is the response from Intesa Sanpaolo concerning the disruption that
revocation will cause to their banking operations:

Good Evening Ben,

   About the problem with the certificate you recently notified us, I
confirm you that we have replaced the certificates today, so we have now
revoked the wrong one.

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

We are available to set up a call conference with you to discuss the matter.
Looking forward to hear from you.

Best regards,
Riccardo D'Agostini


-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 Ben Wilson via dev-security-policy
Sent: Thursday, August 3, 2017 7:33 AM
To: Nick Lamb <tialara...@gmail.com <mailto:tialara...@gmail.com> >;
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: Certificate with invalid dnsName issued from Baltimore
intermediate

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-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: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
revocation date of 15 August 2017, and I'm waiting to hear back.

-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: Wednesday, August 2, 2017 10:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing 
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

No, not yet.  We're currently in negotiations/discussions with them.  

Here is a snippet from a communication from them:

Concerning the CA revocation, first of all, I want to underline that for us
it would be a major issue: we don't have enough time and resources to
replace all the certificates before the end of the year and the revocation
of the CA will cause us several critical operating problems with our
infrastructural services.

Moreover, I would like to inform you that in order to rationalize our
infrastructure and create new synergy between our suppliers, we've planned
to move our certificates to an Italian CA outsourcer. We have already
started this activity and our intent is to complete the migration before the
end of the year, to respect the contract we have settled, with deadline
December, 31st 2017.

Therefore I have to kindly recommend you not to revoke the CA, before the
end of the contract, because it will cause several problems to the Bank and
to our users (customers and colleagues).

Sincerely yours,

Ben

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:44 AM
To: Ben Wilson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore 
intermediate

Hi Ben,

On 03/08/17 14:32, Ben Wilson wrote:
> That would be fine.  Also, we have given Intesa Sanpaolo a scheduled
> revocation date of 15 August 2017, and I'm waiting to hear back.

That's today; is it still the plan to revoke their intermediate?

Gerv


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: Certificates with reserved IP addresses

[Ben Wilson via dev-security-policy]

Gerv,

Yes.  We'll be revoking both of those.  A date is yet to be determined.

Ben


Gerv wrote:

TI Trust Technologies has two intermediate certificates in the CCADB - the one 
mentioned above:

https://ccadb.my.salesforce.com/001o00cdd4t

and this one, serial number 0727bfc4:

https://ccadb.my.salesforce.com/001o00cdd61

Is the plan to revoke that one also?



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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Attached is an audit from 2016.  They are due for another one for 2017.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, August 15, 2017 6:55 AM
To: Ben Wilson ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

Hi Ben,

On 03/08/17 15:38, Ben Wilson wrote:
> Here is the response from Intesa Sanpaolo concerning the disruption
> that revocation will cause to their banking operations:

I've looked up the certs relating to this sub-CA in the CCADB. The key in
question:

https://crt.sh/?caid=1698=cablint,x509lint

appears to be in two certs, which are:

https://crt.sh/?id=18068159=cablint,x509lint
and
https://crt.sh/?id=6158202=cablint,x509lint

They have CCADB entries here (note: these links work for me, but AIUI CA links
are different):

https://ccadb.my.salesforce.com/001o00dsANG
https://ccadb.my.salesforce.com/001o00dsAlD

The audit fields for both of these say "Available on request". I'm not sure
that's a valid value for that field; it's supposed to link to the actual
audit. Nevertheless, I am now requesting. Can you please provide the audits
for this subCA?

Thanks,

Gerv



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: Certificates with reserved IP addresses

[Ben Wilson via dev-security-policy]

Dear Ryan,

 

Here is an initial, interim response to your email as it relates to 
certificates issued by the TI Trust Technologies Global CA.  (Jeremy Rowley or 
I will be sending you a separate email shortly that reports on this issue with 
regard to Cybertrust Japan.)  I will supplement this response as more 
information becomes available.

 

Explanation to the community about how/why this happened:  Apparently Telecom 
Italia Trust Technologies does not have adequate Baseline-Requirements filters 
in place to catch these.

 

How many certificates it affected:  Only the 5 listed at  
<https://misissued.com/batch/7/> https://misissued.com/batch/7/, as far as we 
know.

 

What steps DigiCert is taking to prevent these issues in the future?:  As a 
result of this and other recent issues, DigiCert is bringing certificate 
issuance for TI Trust Technologies in-house.  We will be revoking CA 
certificate serial no. ‎07279ca7 issued to TI Trust Technologies Global CA.  
The key ceremony to create a new in-house CA is scheduled for Wednesday, 23 
August, 2017.  

 

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?  DigiCert 
uses some of the same tools used by others to monitor and detect mis-issuance 
by external, cross-certified CAs.  These include crt.sh, cablint, and 
Censys.IO.  As illustrated in this case, external CAs may be revoked if they do 
not comply.  Whenever DigiCert is made aware of the non-compliance of an 
external CA, it contacts the operator of that CA and requests that 
non-compliant certificates be revoked, that the CA scan its records for other 
certificates with the same infirmity, and that it patch its systems so that the 
issue does not recur.  On a proactive basis, DigiCert regularly advises 
external CAs of new requirements in the Baseline Requirements or browser root 
programs and asks these external CAs to ensure their ongoing compliance. 
Contracts with such entities also require compliance with the requirements. 

 

Sincerely yours,

 

Ben

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Saturday, August 12, 2017 8:56 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Jonathan Rudenberg <jonat...@titanous.com>; 
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 
<dev-security-policy@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy-bounces%2Bben> =digicert@lists.mozilla.org 
<mailto: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 
<mailto: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 
<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: Certificates with less than 64 bits of entropy

[Ben Wilson via dev-security-policy]

As previously noted on this list, there are two Siemens CAs that have issued
certificates with less than 64 bits of entropy.  See
https://misissued.com/batch/6/ 
The Siemens Issuing CA Internet 2013 is subordinate to a DigiCert-owned
root, and the Siemens Issuing CA Internet 2016 is signed by Quo Vadis.  

This email is meant to only address and respond as to certificates issued by
the Siemens Issuing CA Internet 2013, which ceased issuing certificates in
2016, although it also contains information regarding the Siemens Issuing CA
Internet 2016.  We suspect that further response regarding the 2016 CA will
be forthcoming from either QuoVadis or Siemens.
 
Siemens reported the following to us earlier today:

-

We have discovered an implementation error in our in-house CA software which
meant it was using 32bit serials, although they were non sequential. 
Siemens Issuing CA Internet 2013 was then already offline, because we
started on 2nd November 2016 the issuing with the Siemens Issuing CA
Internet 2016 which is cross-signed by QuoVadis.
Furthermore, the Siemens Issuing CA Internet 2016 was taken offline
immediately upon report to us and this was reported by Stephen Davidson from
QuoVadis to the listserv on 7/20. 
The Issuing CA Internet 2016 remains offline and we issue now certificates
from the external market. We also informed our external Auditor about that
issue immediately.  

For the future, all problems are fixed. Originally it was planned to start
on 4th of October 2017 with a new CA System (EJBCA) with full CT Logging.
When we noticed the serial number issue, we doubled up our resources and
moved the Go Live roughly one month earlier now to 8th of September 2017.

In the past, we issued 137 certificates from the Siemens Issuing CA 2013 and
the validity period of the certificates ends:

1 in September 2017
120 in October 2017 
15 in November 2017

Except these, there are three certificates with a longer validity period:

CN=circuit.siemens.com,L=Muenchen,SP=Bayern,C=DE,O=Siemens-Internet,OU=GS IT
IN SPLM SDC US  2018-02-20 13:32:43.000

We are discussing with the customer to exchange the certificate, here some
technical points must be clarified.

The other two certificates are infrastructure certificates and cannot be
replaced due the need of the function of the OCSP Responder and the CA Test
site which is an ETSI Requirement

CN=2013-internet-valid.catestsite.siemens.com,L=Muenchen,SP=Bayern,C=DE,O=Si
emens-Internet,OU=GS IT HR 74,SN=ETSI0002   2018-02-20 14:01:05.000
CN=Siemens PKI OCSP Signer ZZY9,O=Siemens,C=DE  2018-04-10
10:24:31.000

The replacement is complicated as, although the PKI is centralized, the
certificates are issued to Siemens group companies around the world.
We´re working on a replacement plan to do this in a proper time. As the
certificates are already reaching their end of life, for most of them the
renewal process is already ongoing (60 days before expirations the
certificate holders are informed to renew).



Obviously we will continue to evaluate DigiCert's response to this
information from Siemens, but we figured that interim disclosure of this
information to this list was important.

Sincerely yours,

Ben Wilson


-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: Sunday, August 13, 2017 2:07 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with less than 64 bits of entropy

On Sunday, 13 August 2017 04:04:45 UTC+1, Eric Mill  wrote:
> 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.

In my opinion the correct incentive structure here is: We don't care whether
you ever start issuing again but if you have a limited time to stop the
problem, if you can't fix it quickly that will be by ceasing issuance.

Switching off the issuance pipeline in a timely fashion when a problem is
uncovered (so that things stop getting worse) needs to be something every CA
can do. It should always be within the skill set of personnel available "on
call" when things go wrong. But whether they have engineers able to actually
fix a problem the same day, the next day or a month later is an operational
detail for the CA leadership. For commercial CAs there is presumably some
trade-off between the need to be seen as a reliable supplier for repeat
subscribers and the cost of having on-call engineers. But it needn't concern
m.d.s.policy where they think best to draw the line, so long as they prevent
the problem recurring by switching off an affected issuance pipeline until
it's fixed.

I am minded to draw comparison to "emergency 

RE: Certificates with less than 64 bits of entropy

[Ben Wilson via dev-security-policy]

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
Subject: Re: Certificates with less than 64 bits of entropy


> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy 
>  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
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: Certificates with less than 64 bits of entropy

[Ben Wilson via dev-security-policy]

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 <ben.wil...@digicert.com>
Cc: Jeremy Rowley <jeremy.row...@digicert.com>; 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 
<mailto:dev-security-policy@lists.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 
<mailto:dev-security-policy-bounces%2Bben> =digicert@lists.mozilla.org 
<mailto:digicert@lists.mozilla.org> ] On Behalf Of Jeremy Rowley via 
dev-security-policy
Sent: Thursday, August 10, 2017 12:01 PM
To: Jonathan Rudenberg <jonat...@titanous.com <mailto:jonat...@titanous.com> >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> 
=digicert@lists.mozilla.org <mailto: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 
<mailto: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 
> <mailto:dev-security-policy@lists.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 
<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: 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

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 <ben.wil...@digicert.com>
Cc: Jonathan Rudenberg <jonat...@titanous.com>; 
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 
<dev-security-policy@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy-bounces%2Bben> =digicert@lists.mozilla.org 
<mailto: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 
<mailto: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 
<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: 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 <ben.wil...@digicert.com>
Cc: Alex Gaynor <agay...@mozilla.com>; Jonathan Rudenberg 
<jonat...@titanous.com>; mozilla-dev-security-pol...@lists.mozilla.org; Jeremy 
Rowley <jeremy.row...@digicert.com>
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 
<dev-security-policy@lists.mozilla.org 
<mailto: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 <tel:%2B1%20801%20701%209678> 





From: Alex Gaynor [mailto:agay...@mozilla.com <mailto:agay...@mozilla.com> ]
Sent: Friday, August 11, 2017 8:31 AM
To: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >
Cc: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >; Jonathan Rudenberg 
<jonat...@titanous.com <mailto:jonat...@titanous.com> >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy@lists.mozilla.org>  
<mailto:dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.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 
<mailto:dev-security-policy-bounces%2Bben>  
<mailto:dev-security-policy-bounces%2Bben 
<mailto:dev-security-policy-bounces%252Bben> > =digicert@lists.mozilla.org 
<mailto:digicert@lists.mozilla.org>  <mailto:digicert@lists.mozilla.org 
<mailto:digicert@lists.mozilla.org> > ] On Behalf Of Jeremy Rowley via 
dev-security-policy
Sent: Thursday, August 10, 2017 12:01 PM
To: Jonathan Rudenberg <jonat...@titanous.com <mailto:jonat...@titanous.com>  
<mailto:jonat...@titanous.com <mailto:jonat...@titanous.com> > >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org>  
<mailto:mozilla-dev-security-pol...@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley>  
<mailto:dev-security-policy-bounces%2Bjeremy.rowley 
<mailto:dev-security-policy-bounces%252Bjeremy.rowley> > 
=digicert@lists.mozilla.org <mailto:digicert@lists.mozilla.org>  
<mailto:digicert@lists.mozilla.org <mailto:digicert@li

RE: Certificates with less than 64 bits of entropy

[Ben Wilson via dev-security-policy]

QuoVadis Enterprise Trust CA 2 G3 signed the Siemens Issuing CA Internet Server 
2016. 

From: Jeremy Rowley 
Sent: Friday, August 11, 2017 8:36 AM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Alex Gaynor <agay...@mozilla.com>; Jonathan Rudenberg 
<jonat...@titanous.com>; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with less than 64 bits of entropy

 

They are no longer issuing from the digicert cross. The issue is within their 
PKI but  there should be no additional certificates chained to DigiCert roots 


On Aug 11, 2017, at 8:33 AM, Ben Wilson <ben.wil...@digicert.com 
<mailto:ben.wil...@digicert.com> > 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 <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >
Cc: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >; Jonathan Rudenberg 
<jonat...@titanous.com <mailto:jonat...@titanous.com> >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy@lists.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 
<mailto:dev-security-policy-bounces%2Bben> =digicert@lists.mozilla.org 
<mailto:digicert@lists.mozilla.org> ] On Behalf Of Jeremy Rowley via 
dev-security-policy
Sent: Thursday, August 10, 2017 12:01 PM
To: Jonathan Rudenberg <jonat...@titanous.com <mailto:jonat...@titanous.com> >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> 
=digicert@lists.mozilla.org <mailto: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 
<mailto: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 
> <mailto:dev-security-policy@lists.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 
<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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Dear Jonathan,

Thank you for bringing this to our attention.  We have contacted Intesa 
Sanpaolo regarding this error and have asked them to correct it as soon as 
possible.
Sincerely yours,

Ben Wilson, JD, CISA, CISSP
DigiCert VP of Compliance

-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: Monday, July 17, 2017 9:15 AM
To: dev-security-policy@lists.mozilla.org
Subject: Certificate with invalid dnsName issued from Baltimore intermediate

This certificate, issued by “Intesa Sanpaolo CA Servizi Esterni Enhanced” which 
chains up to a Baltimore CyberTrust root, contains an invalid dnsName of 
“www.intesasanpaolovita..biz” (note the two dots): 

https://crt.sh/?q=2B95B474A2646CA28DC244F1AE829C850EA41CF64C75E11A94FE8D228735977B=cablint,x509lint

This raises some questions about the technical controls in place for issuance 
from this CA.

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: 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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Just as a follow up, these two certificates (with
www.intesasanpaolovita..biz) were revoked on 19 July 2017.  See
http://ca.intesasanpaolo.com/portalCais0/crl/servext2.crl.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Tuesday, July 18, 2017 9:54 AM
To: Jakob Bohm ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Tue, Jul 18, 2017 at 8:05 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/07/2017 21:27, Nick Lamb wrote:
> > On Monday, 17 July 2017 16:22:22 UTC+1, Ben Wilson  wrote:
> >> Thank you for bringing this to our attention.  We have contacted 
> >> Intesa
> Sanpaolo regarding this error and have asked them to correct it as 
> soon as possible.
> >
> > "Correcting" the error is surely the smaller of the two tasks ahead.
> >
>
> Depends if the only error is allowing double dots (while correctly 
> validating the domain as if spelled without the extra dot).  Things 
> are much worse if double dots bypass domain validation completely.
>
> Since at least two CA systems have now been found to accept double 
> dots, where only single dots should be allowed, it is reasonable to 
> assume that some relying parties also allow double dots.


It is not reasonable to conclude there is a pattern based on two samples,
nor is it reasonable to conclude there is a pattern in an unrelated system.
If you are aware of any relying party libraries based on CA validation
libraries, that would be useful in establishing the reasonableness of the
conclusion.


This makes it
> essential that any certificates with this syntax error have been 
> completely validated for the equivalent single-dotted name.
>
> I also notice that this is apparently an unconstrained 
> intermediate/SubCA.
>
> Since this appears to be a certificate for the cert holders own 
> domains, it is also possible domain validation was done manually, as 
> in "we know first hand that we control these domains", making this an 
> OV cert, not a DV cert.


All OV certs are DV certs - they are subsets.

Perhaps you're confusing DNS validation done at an Authorization Domain
Name, rather than FQDN. That would be consistent with allowing the customer
to enter labels below the validated domain (under 3.2.5 of the BRs), but not
validating it's a valid DNS label or well formed domain name.
___
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: Certificate with invalid dnsName issued from Baltimore intermediate

[Ben Wilson via dev-security-policy]

Nick,
We are in discussions with Intesa Sanpaolo about implementing/pursuing
OneCRL or a similar approach (e.g. outright revocation of the CAs).
Thanks,
Ben 

-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: Sunday, July 23, 2017 2:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore
intermediate

On Sunday, 23 July 2017 20:12:18 UTC+1, Charles Reiss  wrote:
> This CA also issued a recent certificate for the unqualified dNSName 
> 'webinterfacestrong': https://crt.sh/?id=177606495

Another name that it shouldn't be possible to issue for, but this time one
which can actually exist in local networks and therefore is put at risk by
the existence of such bogus certificates.

>From the view on https://crt.sh/ it appears that this CA does not
automatically log all the certificates it issues which Mozilla will end up
trusting. It may have issued certificates we haven't seen yet.

DigiCert / Ben is that statement correct?

If we cannot today see the "whole iceberg" of certificates issued by this
subCA, and we know it can and does issue problematic certificates I think
it's a good candidate for distrust in OneCRL.
___
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: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Ben Wilson via dev-security-policy]

We've now uploaded the self-signed root into the CCADB as a subordinate CA
to the same self-signed root, if that makes sense.


-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: Monday, July 3, 2017 4:05 PM
To: Nick Lamb ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

"Previously accepted without comment" is hardly accurate. There's lots of
comments on the Mozilla policy (including Ben's comment on this very term).
And it's hardly fair to deride my lack of understanding on what transitive
trust entails in the digital certificate space considering it's outside of
the usual trust paths, not defined in the standard RFCs, and not the same as
the mathematical expression.  Instead, you're substituting one signed object
with another.  I'd figure two-way cross-signed objects would be more akin to
transitive trust than this scenario. After all, they are substitute trust
anchors instead of here where one isn't intended for trust in Mozilla.  It'd
be more helpful to provide additional educational resources rather than
snide comments.  I'd rather understand how it works than argue about what it
means. 

Yes - we pass all policy without comment on to the Sub CA.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, July 3, 2017 3:22 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

On Monday, 3 July 2017 22:00:00 UTC+1, Jeremy Rowley  wrote:
> Link please to a formal definition? As your email alleges a policy
violation by one a cross-signed CAs, we take the investigation and response
very seriously. I'd like to know the basis for the definition before
formulating an official report and potentially penalizing the Sub CA for
non-compliance.

You're asking for a "formal definition" of the word transitively. A word
which was in a policy you have previously accepted without comment, but NOW
you assert you aren't sure what it means. Transitivity is a normal concept
of mathematics and logic, its meaning here seems pretty transparent to me,
it's something we introduce (albeit not with trying to process cyclic
graphs) to secondary school children as part of their normal background in
arithmetic.

Was this policy, which you apparently didn't understand, passed without
comment to the affected Sub CA? Or did you figure that despite not
understanding what it meant you'd be able to somehow implement it?
___
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: Certificates with invalidly long serial numbers

[Ben Wilson via dev-security-policy]

FWIW - In the case of Telecom Italia, they have a commercial CA product has
a bug in it that occasionally causes this issue.  They may need some time
for the software to be fixed/replaced. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Matthew Hardeman via dev-security-policy
Sent: Monday, August 7, 2017 9:52 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

It is what it is, I'm sure, but that definition in RFC5280 is rather
tortured and leads to ambiguity as to whether or not the leading 0x00 is.
In fact, I would say that it is not part of the integer value but rather an
explicit sign flag required by the encoding mechanism.

Wouldn't it have been easier just to say that despite what the ASN.1 INTEGER
type says, serial number shall be regarded as an explicitly unsigned integer
of up to 20 bytes length, to be represented as a positive integral value?

Pragmatically, does anything known break on the extra byte there?
___
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: Hunting for intermediates that still haven't been disclosed to CCADB

[Ben Wilson via dev-security-policy]

Both sets had been publicly disclosed through affirmative publishing in the
repositories of the respective CAs--that's probably how your crawler found
them, because I don't believe they are issuing SSL/TLS certificates.  I
thought I had disclosed the ones chaining to the DigiCert Orion Health
intermediate a while ago (when I first populated the CCADB with our
certificates), but apparently I missed those. The Belgian ones were posted
just recently, I believe, because I do try to keep the CCADB up to date.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Thursday, May 11, 2017 5:47 AM
To: Kurt Roeckx ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Hunting for intermediates that still haven't been disclosed to
CCADB

On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote:
> On 2017-05-11 13:07, Rob Stradling wrote:
>> It would seem that DigiCert noticed these 19 intermediates appear on 
>> https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, 
>> because they've all now been disclosed to the CCADB.
>>
>> They should've been disclosed some time ago, however.
> 
> Does the CCADB keep track of when something was disclosed? A history?

There's a "Created by" field (Username, Timestamp) and a "Last Modified By"
field (Username, Timestamp) in the CCADB, but neither of these fields are
currently provided in the public CSV reports that Mozilla publishes.

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


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: New undisclosed intermediates

[Ben Wilson via dev-security-policy]

I don't believe that disclosure of root certificates is the responsibility
of a CA that has cross-certified a key.  For instance, the CCADB interface
talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
browsers to upload.  I don't even have access to upload a "root"
certificate.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Kurt Roeckx via dev-security-policy
Sent: Thursday, June 8, 2017 6:40 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On 2017-06-08 14:09, wiz...@ida.net wrote:
> But Censys lists it as a trusted intermediate chaining to a root (
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:
> 
> https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a
> 9ef1aa5baa9cc64b38b6c01ca/validation

I got confused by crt.sh, it's not obvious if a certificate is in some root
store or not. They have an other certificate
(https://crt.sh/?q=ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab55738941
79b93fa)
for the same CA that is in the root store.

I have no idea what common implementations do when trying to validate a
chain with such certificate in the middle.

> With respect to Gerv's question: given the ample time to disclose
intermediates, and given all CAs in the program indicated that they had,
seems reasonable to immediately add undisclosed ones that are discovered to
OneCRL. Other than some breakage, as already noted, main downside would seem
to be potentially large growth in OneCRL.

I think there are 2 solutions: OneCRL or a whitelist. OneCRL is probably
easier to do, no new code would need to be written in the browser or NSS. A
whitelist would mean that that list would need to get updated regularly and
that list is probably larger.


Kurt
___
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: New undisclosed intermediates

[Ben Wilson via dev-security-policy]

That's right, Peter.  They should be out of scope unless browsers want to trust 
them and/or they are submitted to browsers for that purpose, in which case 
browsers should be responsible for inputting them into the CCADB.  

Aside from treating these as "intermediates" or "subordinates", there are two 
other ways to look at a self-signed root certificate.  First and more commonly, 
it is a certificate that someone created for submission as a trust anchor (and 
it is usually created prior to submitting the public key for 
cross-certification),  and, second, it is basically a stub branch--because it 
is signing itself--that is one way that these kinds of certificates appear in 
the CCADB.  I've gone ahead and uploaded these two root CA certificates as 
"intermediates" 
(https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
 and 
https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca),
 but I don't think that that is the right approach, IMO, and it would be nice 
if a policy existed that recognized my concerns.  

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, June 8, 2017 8:17 PM
To: Jonathan Rudenberg <jonat...@titanous.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
>
>> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
>> <dev-security-policy@lists.mozilla.org> wrote:
>>
>> I don't believe that disclosure of root certificates is the 
>> responsibility of a CA that has cross-certified a key.  For instance, 
>> the CCADB interface talks in terms of "Intermediate CAs".  Root CAs 
>> are the responsibility of browsers to upload.  I don't even have access to 
>> upload a "root"
>> certificate.
>
> I think the Mozilla Root Store policy is pretty clear on this point:
>
>> All certificates that are capable of being used to issue new certificates, 
>> and which directly or transitively chain to a certificate included in 
>> Mozilla’s CA Certificate Program, MUST be operated in accordance with this 
>> policy and MUST either be technically constrained or be publicly disclosed 
>> and audited.
>
> The self-signed certificates in the present set are all in scope for the 
> disclosure policy because they are capable of being used to issue new 
> certificates and chain to a certificate included in Mozilla’s CA Certificate 
> Program. From the perspective of the Mozilla root store they look like 
> intermediates because they can be used as intermediates in a valid path to a 
> root certificate trusted by Mozilla.

There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different restrictions.  
Self-issued certificates do not provide alternative paths that may have fewer 
constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the "child" 
CA can issue self-issued certificates all day long.  If they are self-signed 
there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are out of 
scope.

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: Old roots to new roots best practice?

[Ben Wilson via dev-security-policy]

Ryan, 
Could you please explain what you mean by saying that if you revoke a single
certificate that it is akin to revoking all variations of that certificate?
I don't think I agree.  There are situations where the certificate is
revoked for reasons (e.g. issues of certificate format/content) that have
nothing to do with distrusting the underlying key pair.
Thanks,
Ben


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Sunday, September 17, 2017 7:57 PM
To: userwithuid 
Cc: mozilla-dev-security-policy

Subject: Re: Old roots to new roots best practice?

Hi there,

I agree, Gerv's remarks are a bit confusing with respect to the concern.
You are correct that the process of establishing a new root generally
involves the creation of a self-signed certificate, and then any
cross-signing that happens conceptually creates an 'intermediate' - so you
have a key shared by a root and an intermediate.

This is not forbidden; indeed, you can see in my recent suggestions to
Symantec/DigiCert, it can and often is the best way for both compatibility
and interoperability. Method #2 that you mentioned, while valid, can bring
much greater compatibility challenges, and thus requires far more careful
planning and execution (and collaboration both with servers and in
configuring AIA endpoints)

However, there is a criticism to be landed here - and that's using the same
name/keypair for multiple intermediates and revoking one/some of them. This
creates all sorts of compatibility problems in the ecosystem, and is thus
unwise practice.

As an example of a compatibility problem it creates, note that RFC5280
states how to verify a constructed path, but doesn't necessarily specify how
to discover that path (RFC 4158 covers many of the strategies that might be
used, but note, it's Informational). Some clients (such as macOS and iOS, up
to I believe 10.11) construct a path first, and then perform revocation
checking. If any certificate in the path is rejected, the leaf is rejected -
regardless of other paths existing. This is similar to the behaviour of a
number of OpenSSL and other (embedded) PKI stacks.
Similarly, applications which process their own revocation checks may only
be able to apply it to the constructed path (Chrome's CRLSets are somewhat
like this, particularly on macOS platforms). Add in caching of intermediates
(like mentioned in 4158), and it quickly becomes complicated.

For this reason - if you have a same name/key pair, it should generally be
expected that revoking a single one of those is akin to revoking all
variations of that certificate (including the root!)

Note that all of this presumes the use of two organizations here, and
cross-signing. If there is a single organization present, or if the
'intermediate' *isn't* intended to be a root, it's generally seen as an
unnecessary risk (for the reasons above).

Does that help explain?


On Sun, Sep 17, 2017 at 11:37 AM, userwithuid via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Forgot the links:
>
> [1] https://groups.google.com/forum/#!topic/mozilla.dev.
> security.policy/hNOJJrN6WfE
> [2] https://groups.google.com/forum/#!msg/mozilla.dev.
> security.policy/RJHPWUd93xE/RqnC3brRBQAJ
> [3] https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7
> d1c45c2f47f93be372a17b96b50757d5a2
> [4] https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aef
> a40a53406a3aec26039efa6b2e0e7244c1
> [5] https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf
> 597f12d2cad2f63d1a4aa37493800ffb80
> [6] https://crt.sh/?spkisha256=f7cd08a27aa9df0918b4df5265580c
> cee590cc9b5ad677f134fc137a6d57d2e7
> [7] https://crt.sh/?spkisha256=60b87575447dcba2a36b7d11ac09fb
> 24a9db406fee12d2cc90180517616e8a18
> [8] https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a
> 4fcce203d4c2eddcaa4013763b5a23d81f
> [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1311832
> ___
> 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: CAs not compliant with CAA CP/CPS requirement

[Ben Wilson via dev-security-policy]

Those are typos.  See section 4.2.1 of our CPS posted here:
https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf 


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Samuel Pinder via dev-security-policy
Sent: Friday, September 8, 2017 4:08 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Andrew Ayer

Subject: CAs not compliant with CAA CP/CPS requirement

Is there a typo here? Digicert.net.jp and Cybertrust.net.jp do not resolve,
Japan tends to use the .NE.jp suffix, not .net.jp . Therefore shouldn't
these be Digicert.ne.jp and Cybertrust.ne.jp ? These two do indeed resolve.
On this subject, I am curious as to why it appears a lot of CA's do not tend
to be publicizing information about CAA nor the issuer domains that can be
used. There does appear to be a last-minute rush for compliance with CAA
validation requirements, as well as confusion on how to interpret the
regulations, but that's just my opinion. I very much support the idea in
principle but adoption is probably being hampered by the lack of information
on correct issuer domains.
Sam


On Fri, Sep 8, 2017 at 10:57 PM, Jeremy Rowley via dev-security-policy
 wrote:
> Hi Andrew,
>
> I'm not certain how to update the previous Mozilla response with 
> respect to CAA, but we added the following as authorized CAA records:
> Digicert.com
> *.digicert
> Digicert.net.jp
> Cybertrust.net.jp
>
> I wasn't sure if adding a wildcard to the CAA record is kosher, but I 
> didn't seem anything prohibiting use of wildcard characters in CAA 
> records.  We saw quite a few records similar to CAA.digiert.com during 
> the testing and added this to the list.
>
> Jeremy
>
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> ozilla .org] On Behalf Of Andrew Ayer via dev-security-policy
> Sent: Friday, September 8, 2017 1:25 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: CAs not compliant with CAA CP/CPS requirement
>
> The BRs state:
>
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate 
> Policy and/or Certification Practice Statement (section 4.1 for CAs 
> still conforming to RFC 2527) SHALL state the CA's policy or practice 
> on processing CAA Records for Fully Qualified Domain Names; that 
> policy shall be consistent with these Requirements. It shall clearly 
> specify the set of Issuer Domain Names that the CA recognises in CAA
'issue' or 'issuewild'
> records as permitting it to issue. The CA SHALL log all actions taken, 
> if any, consistent with its processing practice."
>
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes 
> of some CAs.
>
> At time of writing, the latest published CP/CPSes of the following CAs 
> are not compliant with the above provision of the BRs:
>
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
>
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not 
> specify issuer domain names
>
> DigiCert (https://www.digicert.com/legal-repository/) - Does not 
> specify issuer domain names, and processing is not compliant with BRs 
> ("If a CAA record exists that does not list DigiCert as an authorized 
> CA, DigiCert verifies that the applicant has authorized issuance, 
> despite the CAA
> record.")
>
> Google Trust Services (https://pki.goog/) - Does not check CAA
>
> Identrust (https://secure.identrust.com/certificates/policy/ts/) - 
> Does not check CAA
>
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_
> certif
> icados/es_url/index.shtml)
> - Does not specify issuer domain names
>
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
>
> Symantec / GeoTrust 
> (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
>
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - 
> No mention of CAA
>
> Visa (http://www.visa.com/pki/) - Does not check CAA
>
>
> These CAs have compliant CP/CPSes:
>
> Entrust
>
> GlobalSign
>
> GoDaddy
>
> Let's Encrypt
>
> QuoVadis
>
> Trustwave
>
>
> It would be nice to hear confirmation from the non-compliant CAs that 
> they really are checking CAA as required, and if so, why they 
> overlooked the requirement to update their CP/CPS.
>
> Regards,
> 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
>
___
dev-security-policy mailing list

RE: Violations of Baseline Requirements 4.9.10

[Ben Wilson via dev-security-policy]

Hi Paul,

In case you're not on the distribution for the DigiCert bug for this, here is 
my recent post.

https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c2 

Cheers,

Ben


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Paul Kehrer via dev-security-policy
Sent: Friday, September 8, 2017 6:19 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Violations of Baseline Requirements 4.9.10

On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy
(dev-security-policy@lists.mozilla.org) wrote:

Bugs filed…



~

Thanks,
Kathleen


Thank you very much Kathleen! If I receive additional responses I will update 
the bugs directly.

-Paul
___
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: Violations of Baseline Requirements 4.9.10

[Ben Wilson via dev-security-policy]

This CA only issues client certificates:

 

DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação 
Electrónica do Estado, C=PT

 

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678



 

From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] 
Sent: Tuesday, August 29, 2017 6:48 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Violations of Baseline Requirements 4.9.10

 

I've recently completed a scan of OCSP responders with a focus on checking 
whether they are compliant with BR section 4.9.10's requirement: "Effective 1 
August 2013, OCSP responders for CAs which are not Technically Constrained in 
line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such 
certificates." This rule was put in place in the wake of the DigiNotar incident 
as an additional method of ensuring the CA is aware of all issuances in its 
infrastructure and has been a requirement for over 4 years now.

 

The scan was performed by taking the list of responders (and valid issuer name 
hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP 
request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial 
is extremely unlikely to have been issued legitimately.

 

The following OCSP responders appear to be non-compliant with the BRs (they 
respond GOOD and are not listed as technically constrained by crt.sh) but are 
embedded in certificates issued in paths that chain up to trusted roots in the 
Mozilla store. I have grouped them by owner where possible and put notes about 
whether they've been contacted:

 

AS Sertifitseerimiskeskuse (SK)

 

CCADB does not list an email address. Not CC'd.

 

DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, 
emailAddress=p...@sk.ee  

Example cert: 
https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f

OCSP URI: http://ocsp.sk.ee/CA

 

Autoridad de Certificacion Firmaprofesional

 

Email sent to i...@firmaprofesional.com  

 

DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068

Example cert: 
https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35

OCSP URI: http://ocsp.firmaprofesional.com

 

DN: C=ES, emailAddress=c...@firmaprofesional.com 
 , L=C/ Muntaner 244 Barcelona, OU=Consulte 
http://www.firmaprofesional.com, OU=Jerarquia de Certificacion 
Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC 
Firmaprofesional - CA1

Example cert: 
https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796

OCSP URI: http://ocsp.firmaprofesional.com

 

DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la 
Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP

Example cert: 
https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7

OCSP URI: http://ocsp.firmaprofesional.com

 

CA Disig a.s.

 

Email sent to tspnot...@disig.sk  

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service

Example cert: 
https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2

OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service

Example cert: 
https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417

OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1

Example cert: 
https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947

OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2

Example cert: 
https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341

OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2

 

certSIGN

 

Email sent to off...@certsign.ro  

 

DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN 
Enterprise CA Class 3 G2

Example cert: 
https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355

OCSP URI: http://ocsp.certsign.ro

 

DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA

Example cert: 
https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c

OCSP URI: http://ocsp.certsign.ro

 

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)

 

CCADB does not list an email address. Not CC'd.

 

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de 
la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, 
OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions Locals de 
Catalunya, CN=EC-AL

Example cert: 
https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4

OCSP URI: 

RE: Violations of Baseline Requirements 4.9.10

[Ben Wilson via dev-security-policy]

This CA is technically constrained:

 

DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6

 

 

From: Paul Kehrer [mailto:paul.l.keh...@gmail.com] 
Sent: Tuesday, August 29, 2017 6:48 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Violations of Baseline Requirements 4.9.10

 

I've recently completed a scan of OCSP responders with a focus on checking 
whether they are compliant with BR section 4.9.10's requirement: "Effective 1 
August 2013, OCSP responders for CAs which are not Technically Constrained in 
line with Section 7.1.5 MUST NOT respond with a "GOOD" status for such 
certificates." This rule was put in place in the wake of the DigiNotar incident 
as an additional method of ensuring the CA is aware of all issuances in its 
infrastructure and has been a requirement for over 4 years now.

 

The scan was performed by taking the list of responders (and valid issuer name 
hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP 
request for the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial 
is extremely unlikely to have been issued legitimately.

 

The following OCSP responders appear to be non-compliant with the BRs (they 
respond GOOD and are not listed as technically constrained by crt.sh) but are 
embedded in certificates issued in paths that chain up to trusted roots in the 
Mozilla store. I have grouped them by owner where possible and put notes about 
whether they've been contacted:

 

AS Sertifitseerimiskeskuse (SK)

 

CCADB does not list an email address. Not CC'd.

 

DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, 
emailAddress=p...@sk.ee  

Example cert: 
https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f

OCSP URI: http://ocsp.sk.ee/CA

 

Autoridad de Certificacion Firmaprofesional

 

Email sent to i...@firmaprofesional.com  

 

DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068

Example cert: 
https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35

OCSP URI: http://ocsp.firmaprofesional.com

 

DN: C=ES, emailAddress=c...@firmaprofesional.com 
 , L=C/ Muntaner 244 Barcelona, OU=Consulte 
http://www.firmaprofesional.com, OU=Jerarquia de Certificacion 
Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068, CN=AC 
Firmaprofesional - CA1

Example cert: 
https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796

OCSP URI: http://ocsp.firmaprofesional.com

 

DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la 
Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional - AAPP

Example cert: 
https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7

OCSP URI: http://ocsp.firmaprofesional.com

 

CA Disig a.s.

 

Email sent to tspnot...@disig.sk  

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service

Example cert: 
https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2

OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service

Example cert: 
https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417

OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1

Example cert: 
https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947

OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1

 

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2

Example cert: 
https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341

OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2

 

certSIGN

 

Email sent to off...@certsign.ro  

 

DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN 
Enterprise CA Class 3 G2

Example cert: 
https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355

OCSP URI: http://ocsp.certsign.ro

 

DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA

Example cert: 
https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c

OCSP URI: http://ocsp.certsign.ro

 

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)

 

CCADB does not list an email address. Not CC'd.

 

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de 
la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio ECV-2, 
OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions Locals de 
Catalunya, CN=EC-AL

Example cert: 
https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4

OCSP URI: http://ocsp.catcert.net

 

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge de 
la Concepcio 11 08008 Barcelona, 

RE: Violations of Baseline Requirements 4.9.10

[Ben Wilson via dev-security-policy]

Could someone re-check Multicert and SCEE? (See below.)  They have indicated to 
us that they have now patched their OCSP responder systems.



DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação 
Electrónica do Estado, C=PT

Example cert: https://crt.sh/?id=12729446

OCSP URI: http://ocsp.root.cartaodecidadao.pt/publico/ocsp



DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., 
OU=Accredited Certification Authority, CN=MULTICERT Certification Authority 002

Example cert: https://crt.sh/?id=117934576

OCSP URI: http://ocsp.multicert.com/ocsp

OCSP URI: http://ocsp.multicert.com/procsp



DN: C=PT, O=MULTICERT - Serviços de Certificação Electrónica S.A., OU=Entidade 
de Certificação Credenciada, CN=MULTICERT - Entidade de Certificação 001

Example cert: https://crt.sh/?id=11653177

OCSP URI: http://ocsp.multicert.com/ocsp



DigiCert/Government of Portugal, Sistema de Certificação Electrónica do Estado 
(SCEE) / Electronic Certification System of the State:



DN: C=PT, O=SCEE, CN=ECRaizEstado

Example cert: https://crt.sh/?id=8322256

OCSP URI: http://ocsp.ecee.gov.pt



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

New Sub CAs under the DigiCert RSA and ECC Transition Roots

[Ben Wilson via dev-security-policy]

In the spirit of full transparency and in attempt to comply to the extent we
can with Mozilla policy, on Thursday, Nov. 2, we created several sub CAs
under two new "transition" roots (yet to be submitted as roots).  These sub
CAs haven't been uploaded yet to the CCADB because no instances of the roots
have been created in the CCADB.  Also, I don't have access, yet, to the
Symantec roots in the CCADB, so while these sub CAs chain to the DigiCert
RSA and ECC transition roots (which have been cross-certified by the
Symantec roots - see https://ccadb.force.com/0011J1BtNYx and
https://ccadb.force.com/0011J1BtNaF), they are not listed yet in the
CCADB (because as a technical matter, I have no access - I get an error when
I attempt to do so).  No end entity certificates have been issued by the new
sub CAs.  We'll get those sub CAs uploaded to the CCADB when I get access
first thing next week. 

 

Ben Wilson, JD, CISA, CISSP

VP Compliance



 



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: Proposed policy change: require private pre-notification of 3rd party subCAs

[Ben Wilson via dev-security-policy]

I’ll leave Jeremy’s comments as DigiCert’s most recent.

 

From: Eric Mill [mailto:e...@konklone.com] 
Sent: Tuesday, October 24, 2017 2:34 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: Doug Beattie <doug.beat...@globalsign.com>; Gervase Markham 
<g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Proposed policy change: require private pre-notification of 3rd 
party subCAs

 

Ben, I think Gerv addressed Doug's concern and indicated that situation 
wouldn't fall under this policy. If that's not accurate, it'd be worth an 
on-list clarification.

 

On Tue, Oct 24, 2017 at 9:01 AM, Ben Wilson via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

I echo Doug's concerns.  I can see this process as being useful/helpful
where the private key is off-premises, but for vanity CAs where the operator
of the root CA maintains control of the private key the same as it does for
all other issuing CAs, I think this would introduce unnecessary additional
steps.


-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 Doug Beattie via dev-security-policy
Sent: Tuesday, October 24, 2017 9:44 AM
To: Gervase Markham <g...@mozilla.org <mailto:g...@mozilla.org> >;
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: RE: Proposed policy change: require private pre-notification of 3rd
party subCAs

Gerv,

I assume this applies equally to cross signing, but not to "Vanity" CAs that
are set up and run by the CA on behalf of a customer.  Is that accurate?

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy- 
> <mailto:dev-security-policy-> 
> bounces+doug.beattie=globalsign@lists.mozilla.org 
> <mailto:globalsign@lists.mozilla.org> ] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Tuesday, October 24, 2017 11:28 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
> <mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
> Subject: Proposed policy change: require private pre-notification of
> 3rd party subCAs
>
> One of the ways in which the number of organizations trusted to issue
> for the WebPKI is extended is by an existing CA bestowing the power of
> issuance upon a third party in the form of control of a
> non-technically-constrained subCA. Examples of such are the Google and
> Apple subCAs under GeoTrust, but there are others.
>
> Adding new organizations to the list of those trusted is a big deal,
> and currently Mozilla has little pre-insight into and not much control
> over this process. CAs may choose to do this for whoever they like,
> the CA then bears primary responsibility for managing that customer,
> and as long as they are able to file clean audits, things proceed as
normal.
>
> Mozilla is considering a policy change whereby we require private pre-
> notification of such delegations (or renewals of such delegations).
> We would not undertake to necessarily do anything with such
> notifications, but lack of action should not be considered permissive in
an estoppel sense.
> We would reserve the right to object either pre- or post-issuance of
> the intermediate. (Once the intermediate is issued, of course, the CA
> has seven days to put it in CCADB, and then the relationship would
> probably become known unless the fields in the cert were misleading.)
>
> This may not be where we finally want to get to in terms of regulating
> such delegations of trust, but it is a small step which brings a bit
> more transparency while acknowledging the limited capacity of our team
> for additional tasks.
>
> Comments are welcome.
>
> Gerv
> ___
> 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


___
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





 

-- 

konklone.com <https://konklone.com>  | @konklone <https://twitter.com/konklone> 



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

5.3.1 Technically Constrained

[Ben Wilson via dev-security-policy]

Which "above paragraph" is being referenced in the following excerpt from 
Section 5.3.1 of the Mozilla Root Store Policy v.2.5 
(https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)?



"Instead of complying with the above paragraph, intermediate certificates 
issued before 22nd June 2017 may, until 15th January 2018, comply with the 
following paragraph:



If the certificate includes the id-kp-emailProtection extended key usage, then 
all end-entity certificates MUST only include e-mail addresses or mailboxes 
that the issuing CA has confirmed (via technical and/or business controls) that 
the subordinate CA is authorized to use."



I interpret that "the above paragraph" means the following paragraph:  "5.3 
Intermediate CertificatesAll certificates that are capable of being used to 
issue new certificates, and which directly or transitively chain to a 
certificate included in Mozilla's CA Certificate Program, MUST be operated in 
accordance with this policy and MUST either be technically constrained or be 
publicly disclosed and audited."



Thanks,



Ben Wilson



Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678





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

RE: 5.3.1 Technically Constrained

[Ben Wilson via dev-security-policy]

The problem with the wording of the paragraphs in section 5.3.1 is that they
should have said "..., in order to be considered Technically Constrained,
..." .  Right now they read like absolutes.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Ben Wilson via dev-security-policy
Sent: Monday, January 8, 2018 3:42 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: 5.3.1 Technically Constrained

Which "above paragraph" is being referenced in the following excerpt from
Section 5.3.1 of the Mozilla Root Store Policy v.2.5
(https://www.mozilla.org/en-US/about/governance/policies/security-group/cert
s/policy/)?



"Instead of complying with the above paragraph, intermediate certificates
issued before 22nd June 2017 may, until 15th January 2018, comply with the
following paragraph:



If the certificate includes the id-kp-emailProtection extended key usage,
then all end-entity certificates MUST only include e-mail addresses or
mailboxes that the issuing CA has confirmed (via technical and/or business
controls) that the subordinate CA is authorized to use."



I interpret that "the above paragraph" means the following paragraph:  "5.3
Intermediate CertificatesAll certificates that are capable of being used
to issue new certificates, and which directly or transitively chain to a
certificate included in Mozilla's CA Certificate Program, MUST be operated
in accordance with this policy and MUST either be technically constrained or
be publicly disclosed and audited."



Thanks,



Ben Wilson



Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678





___
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: CCADB disclosure of id-kp-emailProtection intermediates

[Ben Wilson via dev-security-policy]

What about the Mozilla CA communication that said that CAs had until 15
April 2018?

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Tuesday, January 16, 2018 2:29 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: CCADB disclosure of id-kp-emailProtection intermediates

[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents
Mozilla's policy and/or current expectations.  Thanks!]

Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the
non-disclosure (and, IINM, non-audit) of certain non-technically-constrained
id-kp-emailProtection intermediate certificates...until yesterday:
"Instead of complying with the above paragraph, intermediate certificates
issued before 22nd June 2017 may, until 15th January 2018..."

According to [2], there are currently 223 non-technically-constrained
intermediate certificates known to crt.sh that chain to an NSS built-in root
(that has the Email trust bit set) and are capable of issuing
id-kp-emailProtection certificates but not id-kp-serverAuthentication
certificates.

IIUC, the Mozilla policy now requires these intermediate certificates to
have already been disclosed to the CCADB and to be audited.


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: localhost.megasyncloopback.mega.nz private key in client

[Ben Wilson via dev-security-policy]

Norbert,
I've tried to verify this with and without spaces in the msg.asc below.  I
get "Signature Verification Failure".  Please contact me off-list to provide
me clearer information related to your proof of private key possession.
Thanks,
Ben Wilson

-Original Message-
From: dev-security-policy
 On Behalf
Of summern1538--- via dev-security-policy
Sent: Thursday, August 2, 2018 4:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: localhost.megasyncloopback.mega.nz private key in client

Hello everyone,

I'm not sure where to report this issue, this is my fist cert issue report.

I tried to report it to GeoTrust, but they don't know about this domain.

Replay from GeoTrust
> Good day,
> 
> Thank you very much for the friendly request. 
> 
> Unfortunately I was not able to find anything for the provided Domain
localhost.megasyncloopback.mega.nz in our records. 

I'm also not sure what is the difference from RapidSSL and GeoTrust.


## Affected certificate:

https://clicktime.symantec.com/a/1/Y-bjBMElqYp0KwPlm3OjZXUTkdVJDsIqjXFYgZhQa
aY=?d=MgL9dpfm4sY-fi4UP-itDohKjJyuuFPnW2-lyzRErTErGtuNlmb-TdlrMvR7Vzqmu0LJHx
YnLwBpQQI_w9UKOT-1jgPA-YDbaS2QaTIGNCKpZnCH91Q9RHiVH-Wz0P8ugpWF2ygRb442WoABFb
9W-AzK2ATlQ4b_JJJwHZxoIz_5L48rEGNkHhagvyOTJYOIwa_KSmBRd-1DMWTNKpEX8y_FcGWEix
r-_8WJLSMWnBQEzUp7dJBcMwQhU1sgzxZV0bKJYFCkGeukWPTptwwc6UTQ7yjxx-pgBdcbqNArTG
FZYqas7evKXRU7OmEH22VdY5pNqZHlQFCA14KSVNRIy5vGqjc2VnCiGRHYRHMP0xK9SevGSNF63A
sbjGSk1KxbOFgwEn9SLkoNsvf37Qnw_hi9q6seQyIzCmsmr9WshXfn8Ln_Qp_pgD3jjxgGR-qG1Y
lEQbcIuHCsJOR2NNdkHn4R=https%3A%2F%2Fcensys.io%2Fcertificates%2F87d92f12e1
fa4ab0a1460834067d161d085c013d14ca98489c807ce40521b981
https://clicktime.symantec.com/a/1/Ytht2fzBFvZghjVVypfCTp53dGvjsKwwh4w7tgJap
to=?d=MgL9dpfm4sY-fi4UP-itDohKjJyuuFPnW2-lyzRErTErGtuNlmb-TdlrMvR7Vzqmu0LJHx
YnLwBpQQI_w9UKOT-1jgPA-YDbaS2QaTIGNCKpZnCH91Q9RHiVH-Wz0P8ugpWF2ygRb442WoABFb
9W-AzK2ATlQ4b_JJJwHZxoIz_5L48rEGNkHhagvyOTJYOIwa_KSmBRd-1DMWTNKpEX8y_FcGWEix
r-_8WJLSMWnBQEzUp7dJBcMwQhU1sgzxZV0bKJYFCkGeukWPTptwwc6UTQ7yjxx-pgBdcbqNArTG
FZYqas7evKXRU7OmEH22VdY5pNqZHlQFCA14KSVNRIy5vGqjc2VnCiGRHYRHMP0xK9SevGSNF63A
sbjGSk1KxbOFgwEn9SLkoNsvf37Qnw_hi9q6seQyIzCmsmr9WshXfn8Ln_Qp_pgD3jjxgGR-qG1Y
lEQbcIuHCsJOR2NNdkHn4R=https%3A%2F%2Fcrt.sh%2F%3Fid%3D112840296


## Background:

Mega.nz has a sync client, that starts a HTTPS server on port 6342.
Whenever you visit a site on `mega.nz`, the browser tries to connect to
`https://clicktime.symantec.com/a/1/zJ35w_Pu7bpe0t2m0GRsF2ePu0VsvDNruXgyii0T
bDs=?d=MgL9dpfm4sY-fi4UP-itDohKjJyuuFPnW2-lyzRErTErGtuNlmb-TdlrMvR7Vzqmu0LJH
xYnLwBpQQI_w9UKOT-1jgPA-YDbaS2QaTIGNCKpZnCH91Q9RHiVH-Wz0P8ugpWF2ygRb442WoABF
b9W-AzK2ATlQ4b_JJJwHZxoIz_5L48rEGNkHhagvyOTJYOIwa_KSmBRd-1DMWTNKpEX8y_FcGWEi
xr-_8WJLSMWnBQEzUp7dJBcMwQhU1sgzxZV0bKJYFCkGeukWPTptwwc6UTQ7yjxx-pgBdcbqNArT
GFZYqas7evKXRU7OmEH22VdY5pNqZHlQFCA14KSVNRIy5vGqjc2VnCiGRHYRHMP0xK9SevGSNF63
AsbjGSk1KxbOFgwEn9SLkoNsvf37Qnw_hi9q6seQyIzCmsmr9WshXfn8Ln_Qp_pgD3jjxgGR-qG1
YlEQbcIuHCsJOR2NNdkHn4R=https%3A%2F%2Flocalhost.megasyncloopback.mega.nz%3
A6342%2F`.

Obviously the client need the private key to start that HTTPS server.
After a bit debugging from the client, I was able to recover the private key
from that certificate.


## Proof:

msg: (msg.txt)
TW9uIEp1bCAyMyAxMzo1ODo1MiBDRVNUIDIwMTgKClBsZWFzZSByZXZva2UK

rsa signatur: (msg.asc)
VzijbZMHptbIdgOAACSeVLGLKyESeFK4aAKxOS3i/shHDSp53RJJJS0kbeOq7YDCrccqT6gaNXMa
46bcFxUvvwcYwQox6bh6s0+R+PHDgt0LVqutUJUlPLvOC9vDRHCy29hPMf6wXQckvy90KUvwkc2P
tb0GzFfH94DjjQxPfMWwEEZeyUvp2v+KcbFHQNwJp0UKFrfUWW5ooFTZA7E3EeHynW6sHCJS+r64
R5tUdrGGTh1ee6KRrBxOK1qXJVCRF2ftrwXo7rMYUf4MqWCntpD0YMZVkJ5j8VMKx3iVjcq+p++b
boDqCxaUEnHvY96UMrbsrv/z2rWY2V0oVoAZeA==

To proof decode the base64 to the files in the braket ():
Extract the pubkey from the cert:
`$ openssl x509 -in 112840296.crt -pubkey -noout > pub.pem`

and run the following command to verify the message:
`$ openssl pkeyutl -verify -pubin -inkey pub.pem -in msg.txt -sigfile
msg.asc`

Is there an easy way to create a cert revoke from the private key?
How to revoke the certificate?

Best Regards
Norbert Summer



certificate as pem (112840296.crt):

-BEGIN CERTIFICATE-
MIIElTCCA32gAwIBAgIQL41amoCH4B2agSUpD8Wd2DANBgkqhkiG9w0BAQsFADBC
MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMS
UmFwaWRTU0wgU0hBMjU2IENBMB4XDTE3MDQwNTAwMDAwMFoXDTE5MDcwNTIzNTk1
OVowLTErMCkGA1UEAwwibG9jYWxob3N0Lm1lZ2FzeW5jbG9vcGJhY2subWVnYS5u
ejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALGT0FSySDLZ0c252+vO
qyPfrXhSeJeMDDeyQw/7FRQsGBpNwaBCRhEwzojuuj/1GimrnKkrmnxyZSpNiG7/
1nhE/9qwcMgwLuUioi+ChldBZ0kcCEn0oGCdiL6NA3RDohAFp31ZH90oxy6Wc3Sg
zKfzas72jBXjt1hXN1Cc8TWTXPUerMrKqsGMe8Z9JDIwDZgK5KXUrcTNBjw0Vhd6
7dmPAUI++4OZGkuqSAoGu/Ac+7TNpA3taWI0HP7wmcG3o9Q029NnTL+JhRFPeThI
eWGL/Fd1X2OqMA3jfdEwisYhakWcGgmlpMVtOxTfPo2PkFT9NhCloE6J6JN87bVp
yXsCAwEAAaOCAZowggGWMC0GA1UdEQQmMCSCImxvY2FsaG9zdC5tZWdhc3luY2xv
b3BiYWNrLm1lZ2EubnowCQYDVR0TBAIwADArBgNVHR8EJDAiMCCgHqAchhpodHRw

RE: Misissuance and BR Audit Statements

[Ben Wilson via dev-security-policy]

Re-sending

-Original Message-
From: Ben Wilson 
Sent: Wednesday, August 15, 2018 8:34 AM
To: 'r...@sleevi.com' ; Wayne Thayer 
Cc: mozilla-dev-security-policy 
Subject: RE: Misissuance and BR Audit Statements

Thanks, Ryan and Wayne,

Going forward we'll work to improve our management letter disclosures to 
include reported mis-issuances during the audit period.

Sincerely yours,

Ben 

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, August 13, 2018 3:57 PM
To: Wayne Thayer 
Cc: mozilla-dev-security-policy 
Subject: Re: Misissuance and BR Audit Statements

Wayne,

Thanks for raising this. I definitely find it surprising to see nothing noted 
on Comodo's report, as you call out.

As another datapoint, consider this recent audit that is reported to be from 
DigiCert, by way of Amazon Trust Services' providing the audits for their 
externally operated sub-CAs in [A]. The scope of the WebTrust BR audit report 
in [B] contains in its scope "DigiCert ECC Extended Validation Server CA" of 
hash FDC8986CFAC4F35F1ACD517E0F61B879882AE076E2BA80B77BD3F0FE5CEF8862,
which [C]. During that time, this CA issued a cert [D] as part of their 
improperly configured Onion issuance in [E], which was remediated in early 
March, within the audit period for [B]. I couldn't find it listed in the report.

Looking over that period, there were two other (resolved) DigiCert issues, [F] 
and [G], which affect the CAs listed in scope of [B].

I was a bit surprised by this, as like you, I would have expected these to be 
called out by both Management's Assertion and the auditor.
http://www.webtrust.org/practitioner-qualifications/docs/item85808.pdf
provides some of the illustrative reports, but it appears to only provide 
templates for management on the result of obtaining a qualified report.

[A] https://bugzilla.mozilla.org/show_bug.cgi?id=1482930
[B] https://bug1482930.bmoattachments.org/attachment.cgi?id=8999669
[C] https://crt.sh/?id=23432431
[D] https://crt.sh/?id=351449246
[E] https://bugzilla.mozilla.org/show_bug.cgi?id=1447192
[F] https://bugzilla.mozilla.org/show_bug.cgi?id=1465600
[G] https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c29

On Tue, Aug 7, 2018 at 1:32 PM, Wayne Thayer via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Given the number of incidents documented over the past year [1][2] for 
> misissuance and other nonconformities, I would expect many of the 2018 
> period-of-time WebTrust audit statements being submitted by CAs to 
> include qualifications describing these matters. In some cases, that 
> is exactly what we’re seeing. One of many positive examples is 
> Deloitte’s report on Entrust [3] that includes 2 of the 3 issues documented 
> in Bugzilla.
>
> Unfortunately, we are also beginning to see some reports that don’t 
> meet my expectations. I was surprised by GlobalSign’s clean reports 
> [4] from Ernst & Young, but after examining their incident bugs, it 
> appears that the only documented misissuance that occurred during 
> their audit period was placing metadata in Subject fields. I can 
> understand how this could be regarded as a minor nonconformity rather 
> than a qualification, but I would have liked to at least see the issue noted 
> in the reports.
>
> Ernst & Young’s clean reports on Comodo CA [5] is the example that 
> prompted this message. We have documented the following issues that 
> occurred during Comodo’s last audit period:
> * Misissuance using "CNAME CSR Hash 2" method of domain control 
> validation (bug 1461391)
> * Assorted misissuances and failure to respond to an incident report 
> within
> 24 hours (bug 1390981)
> * CAA misissuance (bugs 1398545,1410834, 1420858, and 1423624 )
>
> I would like to know if Comodo reported these issues to EY. I asked 
> Comodo this question four weeks ago [6] but have not received a response.
>
> I will acknowledge that ETSI audits are an even bigger problem 
> (Actalis and SwissSign are recent examples [7][8][9]). Due to the 
> structure of those audits, there is no provision for issuing a 
> qualified report. WebTrust audits are theoretically much better in 
> this regard, but only if auditors actually find and report on issues! 
> I don’t think it is productive to expect auditors to search Bugzilla 
> for a list of issues to copy into their reports, but I do think it is 
> reasonable to question the competence and trustworthiness of the 
> auditor when so many known issues are absent from their report.
>
> In this particular example, unless additional facts are presented, I 
> plan to notate the auditor’s record in CCADB with this issue. We have 
> documented a number of other issues with Ernst & Young - including the 
> disqualification of their Hong Kong branch - but this is the first 
> issue I’m aware of from their New York office. We also recently 
> received a very “good” qualified audit report from EY’s Denmark office on 
> 

RE: Misissuance and BR Audit Statements

[Ben Wilson via dev-security-policy]

Thanks, Ryan and Wayne,

Going forward we'll work to improve our management letter disclosures to 
include reported mis-issuances during the audit period.

Sincerely yours,

Ben 

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, August 13, 2018 3:57 PM
To: Wayne Thayer 
Cc: mozilla-dev-security-policy 
Subject: Re: Misissuance and BR Audit Statements

Wayne,

Thanks for raising this. I definitely find it surprising to see nothing noted 
on Comodo's report, as you call out.

As another datapoint, consider this recent audit that is reported to be from 
DigiCert, by way of Amazon Trust Services' providing the audits for their 
externally operated sub-CAs in [A]. The scope of the WebTrust BR audit report 
in [B] contains in its scope "DigiCert ECC Extended Validation Server CA" of 
hash FDC8986CFAC4F35F1ACD517E0F61B879882AE076E2BA80B77BD3F0FE5CEF8862,
which [C]. During that time, this CA issued a cert [D] as part of their 
improperly configured Onion issuance in [E], which was remediated in early 
March, within the audit period for [B]. I couldn't find it listed in the report.

Looking over that period, there were two other (resolved) DigiCert issues, [F] 
and [G], which affect the CAs listed in scope of [B].

I was a bit surprised by this, as like you, I would have expected these to be 
called out by both Management's Assertion and the auditor.
http://www.webtrust.org/practitioner-qualifications/docs/item85808.pdf
provides some of the illustrative reports, but it appears to only provide 
templates for management on the result of obtaining a qualified report.

[A] https://bugzilla.mozilla.org/show_bug.cgi?id=1482930
[B] https://bug1482930.bmoattachments.org/attachment.cgi?id=8999669
[C] https://crt.sh/?id=23432431
[D] https://crt.sh/?id=351449246
[E] https://bugzilla.mozilla.org/show_bug.cgi?id=1447192
[F] https://bugzilla.mozilla.org/show_bug.cgi?id=1465600
[G] https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c29

On Tue, Aug 7, 2018 at 1:32 PM, Wayne Thayer via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Given the number of incidents documented over the past year [1][2] for 
> misissuance and other nonconformities, I would expect many of the 2018 
> period-of-time WebTrust audit statements being submitted by CAs to 
> include qualifications describing these matters. In some cases, that 
> is exactly what we’re seeing. One of many positive examples is 
> Deloitte’s report on Entrust [3] that includes 2 of the 3 issues documented 
> in Bugzilla.
>
> Unfortunately, we are also beginning to see some reports that don’t 
> meet my expectations. I was surprised by GlobalSign’s clean reports 
> [4] from Ernst & Young, but after examining their incident bugs, it 
> appears that the only documented misissuance that occurred during 
> their audit period was placing metadata in Subject fields. I can 
> understand how this could be regarded as a minor nonconformity rather 
> than a qualification, but I would have liked to at least see the issue noted 
> in the reports.
>
> Ernst & Young’s clean reports on Comodo CA [5] is the example that 
> prompted this message. We have documented the following issues that 
> occurred during Comodo’s last audit period:
> * Misissuance using "CNAME CSR Hash 2" method of domain control 
> validation (bug 1461391)
> * Assorted misissuances and failure to respond to an incident report 
> within
> 24 hours (bug 1390981)
> * CAA misissuance (bugs 1398545,1410834, 1420858, and 1423624 )
>
> I would like to know if Comodo reported these issues to EY. I asked 
> Comodo this question four weeks ago [6] but have not received a response.
>
> I will acknowledge that ETSI audits are an even bigger problem 
> (Actalis and SwissSign are recent examples [7][8][9]). Due to the 
> structure of those audits, there is no provision for issuing a 
> qualified report. WebTrust audits are theoretically much better in 
> this regard, but only if auditors actually find and report on issues! 
> I don’t think it is productive to expect auditors to search Bugzilla 
> for a list of issues to copy into their reports, but I do think it is 
> reasonable to question the competence and trustworthiness of the 
> auditor when so many known issues are absent from their report.
>
> In this particular example, unless additional facts are presented, I 
> plan to notate the auditor’s record in CCADB with this issue. We have 
> documented a number of other issues with Ernst & Young - including the 
> disqualification of their Hong Kong branch - but this is the first 
> issue I’m aware of from their New York office. We also recently 
> received a very “good” qualified audit report from EY’s Denmark office on 
> Telia [10].
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Incident_Dashboard
> [2] https://wiki.mozilla.org/CA/Closed_Incidents
> [3]
> https://www.entrustdatacard.com/-/media/documentation/
> 

RE: Misissuance and BR Audit Statements

[Ben Wilson via dev-security-policy]

What about all of the other audit firms?  

 

From: Wayne Thayer  
Sent: Wednesday, August 15, 2018 1:09 PM
To: Ben Wilson 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 

Subject: Re: Misissuance and BR Audit Statements

 

I went ahead and noted these DigiCert audits as a concern on the CCADB record 
for Scott S. Perry CPA, PLLC.

 

I do think it's important for CAs to disclose these issues to their auditors, 
but I also expect auditors to discover them.

 

- Wayne

 

On Wed, Aug 15, 2018 at 8:21 AM Ben Wilson mailto:ben.wil...@digicert.com> > wrote:

Re-sending

-Original Message-
From: Ben Wilson 
Sent: Wednesday, August 15, 2018 8:34 AM
To: 'r...@sleevi.com  ' mailto:r...@sleevi.com> >; Wayne Thayer mailto:wtha...@mozilla.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: RE: Misissuance and BR Audit Statements

Thanks, Ryan and Wayne,

Going forward we'll work to improve our management letter disclosures to 
include reported mis-issuances during the audit period.

Sincerely yours,

Ben 

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Ryan 
Sleevi via dev-security-policy
Sent: Monday, August 13, 2018 3:57 PM
To: Wayne Thayer mailto:wtha...@mozilla.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Misissuance and BR Audit Statements

Wayne,

Thanks for raising this. I definitely find it surprising to see nothing noted 
on Comodo's report, as you call out.

As another datapoint, consider this recent audit that is reported to be from 
DigiCert, by way of Amazon Trust Services' providing the audits for their 
externally operated sub-CAs in [A]. The scope of the WebTrust BR audit report 
in [B] contains in its scope "DigiCert ECC Extended Validation Server CA" of 
hash FDC8986CFAC4F35F1ACD517E0F61B879882AE076E2BA80B77BD3F0FE5CEF8862,
which [C]. During that time, this CA issued a cert [D] as part of their 
improperly configured Onion issuance in [E], which was remediated in early 
March, within the audit period for [B]. I couldn't find it listed in the report.

Looking over that period, there were two other (resolved) DigiCert issues, [F] 
and [G], which affect the CAs listed in scope of [B].

I was a bit surprised by this, as like you, I would have expected these to be 
called out by both Management's Assertion and the auditor.
http://www.webtrust.org/practitioner-qualifications/docs/item85808.pdf
provides some of the illustrative reports, but it appears to only provide 
templates for management on the result of obtaining a qualified report.

[A] https://bugzilla.mozilla.org/show_bug.cgi?id=1482930
[B] https://bug1482930.bmoattachments.org/attachment.cgi?id=8999669
[C] https://crt.sh/?id=23432431
[D] https://crt.sh/?id=351449246
[E] https://bugzilla.mozilla.org/show_bug.cgi?id=1447192
[F] https://bugzilla.mozilla.org/show_bug.cgi?id=1465600
[G] https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c29

On Tue, Aug 7, 2018 at 1:32 PM, Wayne Thayer via dev-security-policy < 
dev-security-policy@lists.mozilla.org 
 > wrote:

> Given the number of incidents documented over the past year [1][2] for 
> misissuance and other nonconformities, I would expect many of the 2018 
> period-of-time WebTrust audit statements being submitted by CAs to 
> include qualifications describing these matters. In some cases, that 
> is exactly what we’re seeing. One of many positive examples is 
> Deloitte’s report on Entrust [3] that includes 2 of the 3 issues documented 
> in Bugzilla.
>
> Unfortunately, we are also beginning to see some reports that don’t 
> meet my expectations. I was surprised by GlobalSign’s clean reports 
> [4] from Ernst & Young, but after examining their incident bugs, it 
> appears that the only documented misissuance that occurred during 
> their audit period was placing metadata in Subject fields. I can 
> understand how this could be regarded as a minor nonconformity rather 
> than a qualification, but I would have liked to at least see the issue noted 
> in the reports.
>
> Ernst & Young’s clean reports on Comodo CA [5] is the example that 
> prompted this message. We have documented the following issues that 
> occurred during Comodo’s last audit period:
> * Misissuance using "CNAME CSR Hash 2" method of domain control 
> validation (bug 1461391)
> * Assorted misissuances and failure to respond to an incident report 
> within
> 24 hours (bug 1390981)
> * CAA misissuance (bugs 1398545,1410834, 1420858, and 1423624 )
>
> I would like to know if Comodo reported these issues to EY. I asked 
> Comodo this question four weeks ago [6] but have not received a response.
>
> I will acknowledge that ETSI audits are an even bigger problem 
> (Actalis and SwissSign are recent examples [7][8][9]). Due to the 
> structure of those audits, there is no 

Unrevocation of BT Class 2 CA - G2 CA Certificate

[Ben Wilson via dev-security-policy]

I've filed an incident report here:  
https://bugzilla.mozilla.org/show_bug.cgi?id=1442091

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

Mis-issuance of certificate with https in CN/SAN

[Ben Wilson via dev-security-policy]

This mis-issuance incident was reported by Cybertrust Japan (CTJ), an 
intermediate CA of DigiCert.  
(https://bugzilla.mozilla.org/show_bug.cgi?id=1445857)

Here's the incident report:

1.How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, via a discussion in 
mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

CTJ found a misissued certificate through its regular quality-control checking 
using cablint on cert.sh.
https://crt.sh/?id=353098570=cablint

2.A timeline of the actions your CA took in response.

A.  Mar 12, 2018 13:02:22 (JST) - The certificate was issued
B.  Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check 
on cert.sh
C.  Mar 13, 2018 11:00 (JST) - Contacted the customer
D.  Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
E.  Mar 14, 2018 - patched and tested issuance system

 3.Confirmation that your CA has stopped issuing TLS/SSL certificates with 
the problem.

CTJ patched its system to reject the problematic request on Mar 14.

4.A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem were issued.

Number of the affected certificate is one (1).  CTJ scanned all certificates 
issued in the past and only found the one reported above.

 5.The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.

Please see https://crt.sh/?id=353098570=cablint

6.Explanation about how and why the mistakes were made or bugs introduced, 
and how they avoided detection until now.

The bug was not previously found by CTJ QA. The affected certificate was issued 
through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN 
if request is for additional SAN(s) in certificate.  However, this checking 
function was missed for the CN.

7.List of steps your CA is taking to resolve the situation and ensure such 
issuance will not be repeated in the future, accompanied with a timeline of 
when your CA expects to accomplish these things.

A. CTJ scanned already-issued certificates to see if they contained the 
incorrect string in the FQDN and to investigate if any additional problematic 
certificates existed.
B. CTJ patched its system on Mar 14.

Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance


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

RE: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Ben Wilson via dev-security-policy]

That is a distinction without a difference.  If I create a subCA, it’s because 
I want to put it into production soon afterwards. This proposal is going to add 
hours per week that DigiCert is going to have to do, on top of reporting CAs to 
the CCADB, and everything else that CAs have to do.  What is the 
security-critical driver behind this?  Where is the risk-cost-benefit analysis? 
  

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Thursday, April 5, 2018 1:56 PM
To: Ben Wilson 
Cc: Dimitris Zacharopoulos ; r...@sleevi.com; 
mozilla-dev-security-policy 
Subject: Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

 

On Thu, Apr 5, 2018 at 12:05 PM, Ben Wilson  > wrote:

If I create a new sub CA on a weekly basis, will that mean that I have to 
republish my CPS every week?  That makes absolutely no sense.

As proposed, the requirement isn't based on when the subCA certificate is 
created - it requires the subCA to be added to the CP/CPS before being used to 
issue certificates. Refer to the following thread for background on this 
proposal: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/CAaC2a2HMiQ/IKimeW4NBgAJ



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: Policy 2.6 Proposal: Audit requirements for new subCA certificates

[Ben Wilson via dev-security-policy]

If I create a new sub CA on a weekly basis, will that mean that I have to 
republish my CPS every week?  That makes absolutely no sense.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Dimitris Zacharopoulos via dev-security-policy
Sent: Thursday, April 5, 2018 12:56 PM
To: r...@sleevi.com
Cc: mozilla-dev-security-policy 
; Wayne Thayer 

Subject: Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates



On 5/4/2018 9:00 μμ, Ryan Sleevi via dev-security-policy wrote:
> On Thu, Apr 5, 2018 at 5:20 AM, Dimitris Zacharopoulos via 
> dev-security-policy  wrote:
>
>> On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote:
>>
>>> In a recent discussion [1] we decided to clarify the audit 
>>> requirements for new subordinate CA certificates. I’ve  drafted a 
>>> change that requires the new certificate to appear in the next 
>>> periodic audits and in the CP/CPS prior to issuance:
>>>
>>> https://clicktime.symantec.com/a/1/uK18WYwZQOQJdKx7xZlajZuBM8yRGOSgy
>>> j1SoIDpakw=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt
>>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c
>>> Isp_BE0uutKBEGOnmgO6cd=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol
>>> icy%2Fcommit%2F09867ef4a0db3b1c
>>> ab162930c0326c84d272ec10
>>>
>>> We also discussed requiring root key generation ceremony (RKGC) 
>>> audit reports, but I have since realized that the BRs (section 
>>> 6.1.1.1) only require these audit reports for new root certificates. 
>>> I’m not convinced that we should begin requiring an auditor’s report 
>>> every time a new subordinate CA certificate is created.
>>>
>>> I would appreciate everyone's comments on this proposed change.
>>>
>>> This is: 
>>> https://clicktime.symantec.com/a/1/H6tO2jUY3sZd2sXgMqg8Ay069QdOne7oi
>>> y4J1W4xQsI=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt
>>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c
>>> Isp_BE0uutKBEGOnmgO6cd=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol
>>> icy%2Fissues%2F32
>>>
>>> [1]
>>> https://clicktime.symantec.com/a/1/wkXkHi0pu4wDxDHEw6Kx8SMY_1-Pcpybd
>>> w-Yf2WFJ7M=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt
>>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c
>>> Isp_BE0uutKBEGOnmgO6cd=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2
>>> Fmozilla.dev.security.policy%2F
>>> CAaC2a2HMiQ/IKimeW4NBgAJ
>>> ---
>>>
>>> This is a proposed update to Mozilla's root store policy for version 
>>> 2.6. Please keep discussion in this group rather than on GitHub. 
>>> Silence is consent.
>>>
>>> Policy 2.5 (current version):
>>> https://clicktime.symantec.com/a/1/5agl31kcRVdv5wJIFH5-P76QaiWh638Yf
>>> cxtaF8uZWQ=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 4QD_d6ibEP1WuTnxrft1qz_jJTrAoGJKnJvzZI_WgYGagK8hsCodpfgVKRdtZqb9gY-k
>>> TB8J9nzo1Cz2qs2os1GoxF05PH6Gqw6GQZq36x5HPrE3UqPHqcCmYT51fsijJ-RDYREG
>>> k0FuIONxQpg5euehDHMTwSi_uGuf5uGTENRcyA17jb6kKEKLMVVp4CcZqitUybUjyMYX
>>> eVXNvXSEsaCtvNI0riIlcGei3mMVMMhio00v5BPygp0QWx1OEYrsE3lZpMylswo-8Cjt
>>> _Xqg0SNpHK-cPOO0r52NCNO1YxcgDHY9sBQiAVMdb8O4hDZhonN37bP31tHyHFJl8d9c
>>> Isp_BE0uutKBEGOnmgO6cd=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipol
>>> icy%2Fblob%2F2.5%2Frootstore%2Fpolicy.md
>>> ___
>>> dev-security-policy mailing list
>>> dev-security-policy@lists.mozilla.org
>>> https://clicktime.symantec.com/a/1/p8d7MblLB4xZGE-0GeE31x3kiYA3Sm1js
>>> xtAab6FZFU=?d=D63GzWzwhoWeyF_kJnBb491EQqEtmVMk515cECZCjkvzPtf4ppGYNv
>>> Y3xQzWed2guj7FppkMjqslzeVCYi9dA46TCVayqu5Tk0o2EDxhFu5cVrwgIwYV6z3Qdy
>>> 

RE: Mis-issuance of certificate with https in CN/SAN

[Ben Wilson via dev-security-policy]

Matt and Jakob,

Cybertrust Japan asked me to relay the following response to the list.

Jakob, thank you very much for pointing this out.  We should have reported this 
link, https://crt.sh/?id=357203958=cablint

Matt, thank you very much also for asking about our remediation actions we did 
and will.
The patch we applied to our front end checking system is to fix the bug so that 
certificate request containing "https://; or "http://; is now rejected.

However, I hope if you could also read bugzilla 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1445857) about this incident.  
There, we addressed that CTJ would explore the viability of other pre-issuance 
mechanisms, things similar to cablint.

So, just like you mentioned, we are integrating pre-issuance checking via the 
established certificate linting program into our issuance pipeline.  It is 
scheduled to deploy by the end of next week.

Best regards,
Masaru (Mo) Sakamoto


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, March 15, 2018 11:18 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Mis-issuance of certificate with https in CN/SAN

On 16/03/2018 05:28, Ben Wilson wrote:
> This mis-issuance incident was reported by Cybertrust Japan (CTJ), an
> intermediate CA of DigiCert.
> (https://clicktime.symantec.com/a/1/qNaFf1d2FZ7nAtcI4QYFpyVzedhFds4tJj
> IkJYjacpw=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05Anwprg
> FDKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJM
> D8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9
> rVKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0e
> NJ6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfey
> ree9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_
> QfnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D=https%3A%2
> F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1445857)
>
> Here's the incident report:
>
> 1.How your CA first became aware of the problem (e.g. via a problem 
> report submitted to your Problem Reporting Mechanism, via a discussion in 
> mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
>
> CTJ found a misissued certificate through its regular quality-control 
> checking using cablint on cert.sh.
> https://clicktime.symantec.com/a/1/eUA2Ox-2OmTu2LMJ1-PeQnNKn85x02FRP7y
> zo_dn4Ww=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgF
> DKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD
> 8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9r
> VKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eN
> J6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyr
> ee9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_Q
> fnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D=https%3A%2F
> %2Fcrt.sh%2F%3Fid%3D353098570%26opt%3Dcablint
>
> 2.A timeline of the actions your CA took in response.
>
> A.  Mar 12, 2018 13:02:22 (JST) - The certificate was issued
> B.  Mar 13, 2018 10:38 (JST) - Found the certificate during our daily 
> check on cert.sh
> C.  Mar 13, 2018 11:00 (JST) - Contacted the customer
> D.  Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
> E.  Mar 14, 2018 - patched and tested issuance system
>
>   3.Confirmation that your CA has stopped issuing TLS/SSL certificates 
> with the problem.
>
> CTJ patched its system to reject the problematic request on Mar 14.
>
> 4.A summary of the problematic certificates. For each problem: number of 
> certs, and the date the first and last certs with that problem were issued.
>
> Number of the affected certificate is one (1).  CTJ scanned all certificates 
> issued in the past and only found the one reported above.
>
>   5.The complete certificate data for the problematic certificates. The 
> recommended way to provide this is to ensure each certificate is logged to CT 
> and then list the fingerprints or crt.sh IDs, either in the report or as an 
> attached spreadsheet, with one list per distinct problem.
>
> Please see
> https://clicktime.symantec.com/a/1/eUA2Ox-2OmTu2LMJ1-PeQnNKn85x02FRP7y
> zo_dn4Ww=?d=X1N6z3jI_YX4ujnrPBe4VWoD4QWiRXxiNDioLmiuhwgSmGyKm05AnwprgF
> DKobaZkGUaCC1bNO3I4-a5mkFYAn__E9Z5sgwJXS3HeB2S85c7cZEdUoe4j_Gsqj9mEJMD
> 8xA4yzilGNCBPDaPjuUFaeDtDCmkGvYSESVOt6pWAQMqMESgFKtCQe6rw0cdEntO1Jvr9r
> VKLM131eGkqEn5-N7RzAsZKuTo-LnCi7jhfOqoUEvD1hnEKGUHIqzssHb_wlLRQQA1Y0eN
> J6Fmzh57MenRwAeTg1SgoZGjU5MUSSEZTgLieB6bMn3EUx3G2Kvaz6H0yse93euLGIfeyr
> ee9gK84osb2RSMNSg-psXryY_PP1aunwBkOYaNYUQTvtvYCCLMK22Fb8wuaAZgX10vHD_Q
> fnoYBOMBHyaprWxfLuAnMmxCFjD9X4nB7BHepn05ESp42fTkaQ%3D%3D=https%3A%2F
> %2Fcrt.sh%2F%3Fid%3D353098570%26opt%3Dcablint
>

Note: This is the CT precertificate.

Note 2: According to crt.sh, the OCSP response for this precertificate is 

RE: How harsh (in general) should Mozilla be towards CAs?

[Ben Wilson via dev-security-policy]

Jakob Bohm wrote "Each of these arguments for maximum punishment and/or
maximum inconvenience for innocent bystanders is backed by a formal/legal
interpretation of existing rules as making this the only possible outcome."

I'd agree -  heavy-handed, strict enforcement of some rules unnecessarily 
punishes the
larger community and harms the Internet environment. I might be wrong, but I 
don't
believe that Mozilla or Google has an established set of "Sentencing 
Guidelines" or even
a set of procedural rights, but maybe these are needed?  And maybe we need 
additional
criteria on whether a proposed punishment is not just balanced, but also
whether it considers all of the effects (privacy, security, social, economic, 
etc.)
on subscribers and relying parties.




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: Incorrect OCSP status for revoked intermediates

[Ben Wilson via dev-security-policy]

Thanks, Corey.  As I said, we'll try to get this resolved as soon as
possible and file an incident report.

-Original Message-
From: dev-security-policy  On
Behalf Of Corey Bonnell via dev-security-policy
Sent: Sunday, January 27, 2019 2:21 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incorrect OCSP status for revoked intermediates

On Sunday, January 27, 2019 at 4:09:44 PM UTC-5, Ben Wilson wrote:
> I'll look into this immediate, but have you checked to see whether 
> these certificates have OCSP AIAs in them?  Or did you find these by 
> searching our CRLs.
> 
> -Original Message-
> From: dev-security-policy 
>  On Behalf Of Corey 
> Bonnell via dev-security-policy
> Sent: Sunday, January 27, 2019 8:50 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Incorrect OCSP status for revoked intermediates
> 
> Hello,
> I discovered that the following Baltimore CyberTrust Root-chained 
> intermediates are disclosed in CCADB and are revoked via CRL, but the 
> OCSP responder is returning "good":
> 
> DigiCert
> crt.sh URL(s),notBefore,notAfter,subject CN,issuer CN 
> https://clicktime.symantec.com/3GqSUWeMsiuccdDg8FV74mK7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D3528065 ,2014-02-12,2021-02-12,Bechtel External Policy 
> CA 1,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/3QitWkthhibn6J3dyv2WjMK7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D91478106 ,2014-04-16,2024-04-16,Dell Inc. Enterprise 
> CA,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/3GDackCrAv2JK3LE1ejLmCb7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D12625621 ,2014-04-16,2024-04-16,Dell Inc. Enterprise 
> CA,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/3CPUS2fftSKXmYYJpwrxa997Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D91478107 ,2014-04-16,2024-04-16,Dell Inc. Enterprise 
> CA,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/34vSegkxwLnEhzzA2c8n23e7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D12620974 ,2014-09-10,2024-09-10,Dell Inc. Enterprise 
> CA,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/32GsGFkYLsck8uJmXJc9Ky17Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D6906659 ,2015-03-03,2022-03-03,ABB Intermediate CA 
> 3,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/3Gbhskg8uybb9uykbTxfo1h7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D6976985 ,2015-03-18,2022-03-18,Bechtel External Policy 
> CA 1,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/3QaVKssB27cqRnuH6nnqUrX7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D35335507 ,2015-05-21,2022-05-21,ABB Intermediate CA 
> 3,Baltimore CyberTrust Root 
> https://clicktime.symantec.com/3TjvAB1yvCCo15dr1ecGvbd7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D78292184 ,2016-11-30,2020-11-30,Eurida Primary 
> CA,Baltimore CyberTrust Root
> 
> Given that software may rely on OCSP responses for revocation checking 
> (as opposed to CRLs or some other mechanism), I wanted to notify the 
> Mozilla community of this inconsistent revocation information.
> 
> Thanks,
> Corey
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/3XCAvWmYdPvvFEe9DtH7i3T7Vc?u=https%3A%2
> F%2Fli sts.mozilla.org%2Flistinfo%2Fdev-security-policy

Hi Ben,
Yes, I confirmed that all listed certificates have OCSP AIA pointers. You
can use the crt.sh links and click "Check" in the Revocation table's OCSP
column to have crt.sh perform the OCSP check for you.

For full disclosure, I found these certificates using Censys.io.

Thanks,
Corey
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/3EBy6mM3kSWChPTFEoHeZpq7Vc?u=https%3A%2F%2Fli
sts.mozilla.org%2Flistinfo%2Fdev-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: Incorrect OCSP status for revoked intermediates

[Ben Wilson via dev-security-policy]

I'll look into this immediate, but have you checked to see whether these
certificates have OCSP AIAs in them?  Or did you find these by searching our
CRLs.

-Original Message-
From: dev-security-policy  On
Behalf Of Corey Bonnell via dev-security-policy
Sent: Sunday, January 27, 2019 8:50 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Incorrect OCSP status for revoked intermediates

Hello,
I discovered that the following Baltimore CyberTrust Root-chained
intermediates are disclosed in CCADB and are revoked via CRL, but the OCSP
responder is returning "good":

DigiCert
crt.sh URL(s),notBefore,notAfter,subject CN,issuer CN
https://clicktime.symantec.com/3GqSUWeMsiuccdDg8FV74mK7Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D3528065 ,2014-02-12,2021-02-12,Bechtel External Policy CA
1,Baltimore CyberTrust Root
https://clicktime.symantec.com/3QitWkthhibn6J3dyv2WjMK7Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D91478106 ,2014-04-16,2024-04-16,Dell Inc. Enterprise
CA,Baltimore CyberTrust Root
https://clicktime.symantec.com/3GDackCrAv2JK3LE1ejLmCb7Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D12625621 ,2014-04-16,2024-04-16,Dell Inc. Enterprise
CA,Baltimore CyberTrust Root
https://clicktime.symantec.com/3CPUS2fftSKXmYYJpwrxa997Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D91478107 ,2014-04-16,2024-04-16,Dell Inc. Enterprise
CA,Baltimore CyberTrust Root
https://clicktime.symantec.com/34vSegkxwLnEhzzA2c8n23e7Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D12620974 ,2014-09-10,2024-09-10,Dell Inc. Enterprise
CA,Baltimore CyberTrust Root
https://clicktime.symantec.com/32GsGFkYLsck8uJmXJc9Ky17Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D6906659 ,2015-03-03,2022-03-03,ABB Intermediate CA
3,Baltimore CyberTrust Root
https://clicktime.symantec.com/3Gbhskg8uybb9uykbTxfo1h7Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D6976985 ,2015-03-18,2022-03-18,Bechtel External Policy CA
1,Baltimore CyberTrust Root
https://clicktime.symantec.com/3QaVKssB27cqRnuH6nnqUrX7Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D35335507 ,2015-05-21,2022-05-21,ABB Intermediate CA
3,Baltimore CyberTrust Root
https://clicktime.symantec.com/3TjvAB1yvCCo15dr1ecGvbd7Vc?u=https%3A%2F%2Fcr
t.sh%2F%3Fid%3D78292184 ,2016-11-30,2020-11-30,Eurida Primary CA,Baltimore
CyberTrust Root

Given that software may rely on OCSP responses for revocation checking (as
opposed to CRLs or some other mechanism), I wanted to notify the Mozilla
community of this inconsistent revocation information.

Thanks,
Corey
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/3XCAvWmYdPvvFEe9DtH7i3T7Vc?u=https%3A%2F%2Fli
sts.mozilla.org%2Flistinfo%2Fdev-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: Incorrect OCSP status for revoked intermediates

[Ben Wilson via dev-security-policy]

We believe this issue has been fixed.

From: Ben Wilson
Sent: Sunday, January 27, 2019 2:22:45 PM
To: Corey Bonnell; mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incorrect OCSP status for revoked intermediates

Thanks, Corey.  As I said, we'll try to get this resolved as soon as
possible and file an incident report.

-Original Message-
From: dev-security-policy  On
Behalf Of Corey Bonnell via dev-security-policy
Sent: Sunday, January 27, 2019 2:21 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incorrect OCSP status for revoked intermediates

On Sunday, January 27, 2019 at 4:09:44 PM UTC-5, Ben Wilson wrote:
> I'll look into this immediate, but have you checked to see whether
> these certificates have OCSP AIAs in them?  Or did you find these by
> searching our CRLs.
>
> -Original Message-
> From: dev-security-policy
>  On Behalf Of Corey
> Bonnell via dev-security-policy
> Sent: Sunday, January 27, 2019 8:50 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Incorrect OCSP status for revoked intermediates
>
> Hello,
> I discovered that the following Baltimore CyberTrust Root-chained
> intermediates are disclosed in CCADB and are revoked via CRL, but the
> OCSP responder is returning "good":
>
> DigiCert
> crt.sh URL(s),notBefore,notAfter,subject CN,issuer CN
> https://clicktime.symantec.com/3GqSUWeMsiuccdDg8FV74mK7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D3528065 ,2014-02-12,2021-02-12,Bechtel External Policy
> CA 1,Baltimore CyberTrust Root
> https://clicktime.symantec.com/3QitWkthhibn6J3dyv2WjMK7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D91478106 ,2014-04-16,2024-04-16,Dell Inc. Enterprise
> CA,Baltimore CyberTrust Root
> https://clicktime.symantec.com/3GDackCrAv2JK3LE1ejLmCb7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D12625621 ,2014-04-16,2024-04-16,Dell Inc. Enterprise
> CA,Baltimore CyberTrust Root
> https://clicktime.symantec.com/3CPUS2fftSKXmYYJpwrxa997Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D91478107 ,2014-04-16,2024-04-16,Dell Inc. Enterprise
> CA,Baltimore CyberTrust Root
> https://clicktime.symantec.com/34vSegkxwLnEhzzA2c8n23e7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D12620974 ,2014-09-10,2024-09-10,Dell Inc. Enterprise
> CA,Baltimore CyberTrust Root
> https://clicktime.symantec.com/32GsGFkYLsck8uJmXJc9Ky17Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D6906659 ,2015-03-03,2022-03-03,ABB Intermediate CA
> 3,Baltimore CyberTrust Root
> https://clicktime.symantec.com/3Gbhskg8uybb9uykbTxfo1h7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D6976985 ,2015-03-18,2022-03-18,Bechtel External Policy
> CA 1,Baltimore CyberTrust Root
> https://clicktime.symantec.com/3QaVKssB27cqRnuH6nnqUrX7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D35335507 ,2015-05-21,2022-05-21,ABB Intermediate CA
> 3,Baltimore CyberTrust Root
> https://clicktime.symantec.com/3TjvAB1yvCCo15dr1ecGvbd7Vc?u=https%3A%2
> F%2Fcr
> t.sh%2F%3Fid%3D78292184 ,2016-11-30,2020-11-30,Eurida Primary
> CA,Baltimore CyberTrust Root
>
> Given that software may rely on OCSP responses for revocation checking
> (as opposed to CRLs or some other mechanism), I wanted to notify the
> Mozilla community of this inconsistent revocation information.
>
> Thanks,
> Corey
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/3XCAvWmYdPvvFEe9DtH7i3T7Vc?u=https%3A%2
> F%2Fli sts.mozilla.org%2Flistinfo%2Fdev-security-policy

Hi Ben,
Yes, I confirmed that all listed certificates have OCSP AIA pointers. You
can use the crt.sh links and click "Check" in the Revocation table's OCSP
column to have crt.sh perform the OCSP check for you.

For full disclosure, I found these certificates using Censys.io.

Thanks,
Corey
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/3EBy6mM3kSWChPTFEoHeZpq7Vc?u=https%3A%2F%2Fli
sts.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Unretrievable CPS documents listed in CCADB

[Ben Wilson via dev-security-policy]

That approach could work.

 

From: Wayne Thayer  
Sent: Friday, May 3, 2019 1:19 PM
To: Ben Wilson 
Cc: Andrew Ayer ; Corey Bonnell ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Unretrievable CPS documents listed in CCADB

 

On Fri, May 3, 2019 at 8:36 AM Ben Wilson via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

I'm against having to continually update the exact URL of the CP and CPS in the 
CCADB.

 

 

A relatively simple solution to this problem is to create a "permanent link" to 
the current version of these docs (e.g. 
https://digicert.com/repository/current_cp.pdf), then modify or redirect the 
document that the link returns each time the document is updated as part of the 
publishing process. Under this scheme, the CA should never need to worry about 
updating CCADB.

 

  It's pretty easy to find the current CP and CPS from a legal repository.

 

 

But not as easy as getting it from a CCADB report, especially when the 
repository page doesn't clearly map a policy to a CA certificate.

 

  Plus, if we point to an exact one in the CCADB, it might not be the one that 
is applicable to a given certificate that was issued prior to the most current 
CPS.  In other words, you should look at when the certificate was issued and 
then figure out which CPS is applicable.  

 

I'm almost always looking for the current policy rather than trying to identify 
the version applicable to a specific certificate.

 

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Andrew 
Ayer via dev-security-policy
Sent: Thursday, May 2, 2019 8:16 PM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: Unretrievable CPS documents listed in CCADB

On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:

> As an aside, I noticed that several URLs listed in CCADB are “Legal 
> Repository” web page URLs that contain a list of many CP/CPS 
> documents. My recommendation is to slightly amend CCADB Policy to 
> require CAs to provide URLs to the specific document in question 
> rather than a general “Legal Repository” page, where it is left up to 
> the reader to decide which hyperlink on the page is the correct 
> document.

+1.  It's often a real hassle to find the CP/CPS for a CA.  Linking
directly to the document would help a lot.



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: Unretrievable CPS documents listed in CCADB

[Ben Wilson via dev-security-policy]

I'm against having to continually update the exact URL of the CP and CPS in the 
CCADB.  It's pretty easy to find the current CP and CPS from a legal 
repository.  Plus, if we point to an exact one in the CCADB, it might not be 
the one that is applicable to a given certificate that was issued prior to the 
most current CPS.  In other words, you should look at when the certificate was 
issued and then figure out which CPS is applicable.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Andrew Ayer via dev-security-policy
Sent: Thursday, May 2, 2019 8:16 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Unretrievable CPS documents listed in CCADB

On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy
 wrote:

> As an aside, I noticed that several URLs listed in CCADB are “Legal 
> Repository” web page URLs that contain a list of many CP/CPS 
> documents. My recommendation is to slightly amend CCADB Policy to 
> require CAs to provide URLs to the specific document in question 
> rather than a general “Legal Repository” page, where it is left up to 
> the reader to decide which hyperlink on the page is the correct 
> document.

+1.  It's often a real hassle to find the CP/CPS for a CA.  Linking
directly to the document would help a lot.
___
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: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Ben Wilson via dev-security-policy]

I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
certificate itself (not the CA that issues the OCSP responder certificate).
I don't think I've encountered a problem before, but I guess it would depend
on the implementation?

-Original Message-
From: dev-security-policy  On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, September 4, 2019 9:01 AM
To: perd...@gmail.com
Cc: mozilla-dev-security-policy

Subject: Re: Question about the issuance of OCSP Responder Certificates by
technically constrained CAs

On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> My question is the following: is it allowed to issue an OCSP Responder 
> certificate with "id-kp-OCSPSigning" EKU from a technically 
> constrained CA if the "id-kp-OCSPSigning" EKU is not listed in the CA 
> certificate,


This will fail, not because of policy reasons, but because of technical
reasons (not Firefox).

The code (for Firefox) is
https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b68
18e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888
,
with the most salient logic at
https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b68
18e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884
,
although the explanation in
https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b68
18e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#863-869
explains
the technical reasons.


> in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a 
> possible, mandatory or forbidden option for such CAs?
>

This is not forbidden by policy. That is, a technically constrained
subordinate CA certificate can have id-kp-OCSPSigning and id-kp-serverAuth.

As I see in the practice, if a technically constrained CA signs the OCSP
> response itself, it can be done without the "id-kp-OCSPSigning" EKU 
> but with the "digitalSignature" KU bit in the CA certificate.
>

Correct, if the id-kp-OCSPSigning EKU is missing from the technically
constrained intermediate, direct signing still works.
___
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: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

Dear Sándor,

I have a couple of follow-up questions for Microsec.

There were some responses during the recent public discussion in which
Microsec indicated it would update its CPS(es).

When do you anticipate that this will occur?

Also, it is also unclear from the quoted thread below whether such updates
will include additions to section 1.5.2 as required by Section 4.9.3 of the
Baseline Requirements.

Could you please clarify if and when section 1.5.2 will be updated?

Thanks.

Sincerely yours,

Ben Wilson
Mozilla Root Program



   -

   BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for
   reporting an issue such as key compromise to the CA. The Microsec CPS’
   only state that questions related to the policy may be reported via the
   info in that section, and other email addresses

(“highpriority...@e-szigno.hu”,

“revoc...@e-szigno.hu") are found in other sections of some documents. Section
4.9.5 then states that revocation requests are only accepted at the address
listed in section 1.2, but there is no email address in this section.

The CPS of Microsec is structured according to the requirement of RFC3647.
This also required by the CABF BR in section 2.2. According to RFC3647 the
Section 1.5 is for the policy administration and section 1.5.2 defines the
contact person who is responsible for maintaining the CPS. Section 4.9.3 of
the CPS contains detailed information about the possibilities of revocation
request submission. Section 1.3.1 contains the email addresses, where
revocation request can be sent (mentioning section 1.2 is an editorial
mistake, it will be corrected in the next version of the CPS). Section
4.9.3 contains also a subsection which describes the High-Priority
Certificate Problem Report mechanism. More detailed information can be
found on our website on the given link.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Welcome Ben Wilson to Mozilla!

[Ben Wilson via dev-security-policy]

Thanks, Kathleen

I'm really excited to begin working with all of you!

Cheers and stay safe,

Ben Wilson

On Mon, Apr 13, 2020 at 11:07 AM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> All,
>
> I am pleased to announce that Ben Wilson has joined Mozilla as a CA
> Program Manager!
>
> Ben has worked in PKI security, compliance, and policy since 1998.
> Previously, he worked at DigiCert in various roles, including VP of PKI
> Operations, VP of Compliance, and Chair of DigiCert’s Policy Authority
> team to develop and communicate policies and practices for internal and
> external stakeholders. Ben has also been very involved in the CA/Browser
> Forum. He is a former Chair of the CA/Browser Forum and of the American
> Bar Association’s Information Security Committee. Over the years, Ben
> has also participated in this mozilla.dev.security.policy forum.
>
> Here are some of the things that Ben will be responsible for:
> + Steps 3 through 9 of Mozilla’s root inclusion process[1], which
> includes the detailed CP/CPS reviews[2] and the public discussion phase[3]
> + CA Incident Bugs[4]
> + Updates to Mozilla’s Root Store Policy[5] and the Common CCADB
> Policy[6], including prioritizing potential changes[7] and leading
> discussions to determine the actual changes
> + Represent Mozilla in the CA/Browser Forum, along with Wayne
>
> I have added Ben to the Policy_Participants wiki page[8], and updated
> Wayne's entry.
>
> Welcome, Ben!
>
> Thanks,
> Kathleen
>
> [1] https://wiki.mozilla.org/CA/Application_Process
> [2] https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review
> [3] https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion
> [4] https://wiki.mozilla.org/CA/Incident_Dashboard
> [5]
>
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> [6] https://www.ccadb.org/policy
> [7] https://github.com/mozilla/pkipolicy/issues
> [8] https://wiki.mozilla.org/CA/Policy_Participants
> ___
> 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

COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Ben Wilson via dev-security-policy]

Dear MDSP community,

As you are aware from past discussions on this list, there has been a
concern about the impact of COVID-19 on CA operations.  COVID-19 continues
to impact certain areas of the world more severely than others. For
example, there has been a recent resurgence of COVID-19 in Japan.[1]  Globally,
COVID-19 has not leveled out.[2]

Recently at least one CA has expressed concern about Action 3 of Mozilla's
January 2020 CA Communication [3] and enforcement of Section 5.2 of
Mozilla’s Root Store Policy, which provide that as of 1-July-2020,
end-entity certificates MUST include an EKU extension containing
KeyPurposeId(s) describing the intended usage(s) of the certificate, and
the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.
See [4].

Some CAs (and their customers) located in Japan, the U.S., and elsewhere
are dealing with new priorities that were not apparent back in January.  Some
have had to reorganize to deal with reduced staff and reallocate resources,
while other companies have modified their schedules to delay changes that
might cause instability.[5], [6]

For some parties, the benefit of a 3-month delay (to 1-October-2020) in
enforcement of Mozilla’s EKU requirement may result in more flexibility,
resilience and secure operations.

Several options are being considered:

1.   Require that a CA request an extension, to be submitted on
Bugzilla and flagged as “covid-19”, similar to audit delays [7] AND

a.   Not require an incident report, OR

b.   Require an incident report

2.   Grant a blanket 3-month extension and not require revocation of
certificates that do not comply

3.   Replace July 1 with October 1 in section 5.2 of the Mozilla Root
Store Policy and publish a new version

4.   Recognize broader exceptions for COVID-19 issues, e.g. enlarge the
scope of the delayed-audit approach to include other non-conformities/other
issues and not require immediate certificate revocations

I look forward to hearing your opinions and suggestions.

Sincerely yours,

Ben Wilson

Endnotes:

[1]  https://apnews.com/9140ddd7283d534d8464778d9c4bd92a

[2]
https://ourworldindata.org/coronavirus#what-is-the-total-number-of-confirmed-cases

[3]
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3waNOW=Q00086,Q00087,Q00097


[4]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices

[5]  https://docs.microsoft.com/en-us/security/trusted-root/2020/april2020

[6]
https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

[7]  https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Ben Wilson via dev-security-policy]

 Dear Andrew,

The purpose of my email was to alert the Mozilla community of a COVID-19
concern as it arose and to start/continue a dialogue on these COVID-19
matters. I was hoping to get some general feedback to help guide our
COVID-19 policy.

I appreciate the feedback so far. As mentioned in the responses, the CA
will have to come forward to this list with more details about the issues
it faces, that way, the specific merits of its situation can be openly and
transparently evaluated.  If the CA chooses not to come forward, I will
assume that it will comply with the July 1 EKU deadline.

Sincerely yours,

Ben

On Thu, Apr 23, 2020 at 2:56 AM westmail24--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello Ben,
> What CA you present here?
> 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

Request to Include certSIGN Root CA G2 certificate

[Ben Wilson via dev-security-policy]

This request is for inclusion of the certSIGN Root CA G2 certificate and to
turn on the Websites trust bit and for EV treatment.


The request is documented in Bugzilla and in the CCADB as follows:

https://bugzilla.mozilla.org/show_bug.cgi?id=1403453

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0403

(Summary of info gathered and verified, URLs for test websites, etc.)



* certSIGN’s BR Self Assessment is here:

https://bugzilla.mozilla.org/attachment.cgi?id=9052673

The Certsign document repository can be found here:

https://www.certsign.ro/en/certsign-documents/policies-procedures

* Root Certificate Locations:

http://crl.certsign.ro/certsign-rootg2.crt

http://registru.certsign.ro/certcrl/certsign-rootg2.crt

http://www.certsign.ro/certcrl/certsign-rootg2.crt

https://crt.sh/?q=657CFE2FA73FAA38462571F332A2363A46FCE7020951710702CDFBB6EEDA3305

https://censys.io/certificates/657cfe2fa73faa38462571f332a2363a46fce7020951710702cdfbb6eeda3305/pem


* EV Policy OID:   2.23.140.1.1

* CRL URL: http://crl.certsign.ro/certsign-rootg2.crl

* OCSP URL: http://ocsp.certsign.ro



* Audit: See https://bugzilla.mozilla.org/attachment.cgi?id=9142635 (
http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_1612-163_V10_Certsign_S.pdf)
which shows that a recent annual audit was performed on the certSIGN Root
CA G2 by LSTI Group according to ETSI EN 319 411-2, V2.2.2 (2018-04)”,
“ETSI EN 319 411-1, V1.2.2 (2018-04)” and “ETSI EN 319 401, V2.2.1
(2018-04)” as well as the CA/Browser Forum’s “EV SSL Certificate
Guidelines, version 1.7.1” and “Baseline Requirements, version 1.6.7”
considering the requirements of the “ETSI EN 319 403, V2.2.2 (2015-08)” for
the Trust Service Provider Conformity Assessment.


* CP/CPS Review

Ryan Sleevi conducted a preliminary review the PKI Disclosure Statement and
CPS - https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c13

I followed up, and now Comment #24 in Bugzilla shows the latest responses
from Certsign - https://bugzilla.mozilla.org/show_bug.cgi?id=1403453#c24



This begins the 3-week comment period for this request.

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of this root into the Mozilla CA program.

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

Re: Mozilla's Expectations for OCSP Incident Reporting

[Ben Wilson via dev-security-policy]

Just an FYI - I've also started a thread on the CA/Browser Forum list to
see about establishing OCSP uptime requirements in the Baseline
Requirements.

On Mon, May 11, 2020 at 5:45 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2020-05-08 21:03, Wayne Thayer wrote:
> > It was recently reported [1] that IdenTrust experienced a multi-day OCSP
> > outage about two weeks ago. Other recent OCSP issues have resulted in
> > incident reports [3][4], so I am concerned that IdenTrust didn't report
> > this, and I created a bug [5] to ensure that we track the issue (assuming
> > the report of an extended outage is accurate).
> >
> > I also created an issue [6] suggesting that Mozilla clarify expectations
> > for reporting CRL and OCSP outages. These services are notoriously
> > unreliable and I doubt that a constant barrage of reports for brief
> outages
> > would be manageable. I believe that Mozilla does expect CAs to report
> > "significant" outages, but there is currently no guidance to help CAs
> > determine when they should file a report.
>
> Should we have minimum uptime requirements? For instance 90% for a 24
> hour period and 95% per 30 days?
>
>
> Kurt
> ___
> 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: Digicert issued certificate with let's encrypts public key

[Ben Wilson via dev-security-policy]

Thanks, Corey.
I've added this as a matter to consider in a future version of the Root
Store Policy. https://github.com/mozilla/pkipolicy/issues/215

On Thu, May 21, 2020 at 7:23 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> While I realize the current topic is concerning TLS, I find it rather
> surprising that Mozilla Policy does not mandate PoP for S/MIME certificate
> issuance. Lack of checking for S/MIME would present more concrete security
> concerns, so perhaps this should be addressed in a future update to the
> Policy.
>
> Thanks,
> Corey
> ___
> 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

Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Ben Wilson via dev-security-policy]

 This issue is presented for resolution in the next version of the Mozilla
Root Store Policy. It is related to Issue #147
 (previously posted for
discussion on this list on 6-Oct-2020).

Possible language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4

In addition to replacing "if issuing EV certificates" with "if capable of
issuing EV certificates" in two places -- for WebTrust and ETSI audits --
it would be followed by "(i.e. a subordinate CA under an EV-enabled root
that contains no EKU or the id-kp-serverAuth EKU or anyExtendedKeyUsage
EKU, and a certificatePolicies extension that asserts the CABF EV OID of
2.23.140.1.1, the anyPolicy OID, or the CA's EV policy OID)." Thus, Mozilla
considers that a CA is capable of issuing EV certificates if it is (1) a
subordinate CA (2) under an EV-enabled root (3) that contains no EKU or the
id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and (4) a
certificatePolicies extension that asserts the CABF EV OID of 2.23.140.1.1,
the anyPolicy OID, or the CA's EV policy OID.

I look forward to your suggestions.

Thanks,

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

Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Ben Wilson via dev-security-policy]

This issue #153, listed here:
https://github.com/mozilla/pkipolicy/issues/153, is proposed for resolution
with version 2.7.1 of the Mozilla Root Store Policy. It is related to Issue
139  (audits required even
if not issuing).

The first paragraph of section 3.1.3 of the MRSP would read:

Full-surveillance period-of-time audits MUST be conducted and updated audit
information provided no less frequently than *annually* from the time of CA
key pair generation until the CA certificate is no longer trusted by
Mozilla's root store or until all copies of the CA private key have been
completely destroyed, as evidenced by a Qualified Auditor's key destruction
report, whichever occurs sooner. Successive period-of-time audits MUST be
contiguous (no gaps).
Item 5 in the fifth paragraph of section 7.1 of the MRSP (new root
inclusions) would read:

5. an auditor-witnessed root key generation ceremony report and contiguous
period-of-time audit reports performed thereafter no less frequently than
annually;

The proposed language can be examined further in the following commits:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/0d72d9be5acca17ada34cf7e380741e27ee84e55

https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35

Or here:
https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.7.1/rootstore/policy.md

Thanks in advance for your comments,

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

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Ben Wilson via dev-security-policy]

 Ryan wrote:

> If we apply this concept to the proposed language, then the requirement
for an EV audit is
> simply about whether there is any unexpired, unrevoked path to a root CA
which can issue
> EV certificates. Similarly, checking the scope for an EV audit becomes
“the entire hierarchy”.

> This is accomplished by simply removing your proposed “(i.e. ...)”
parenthetical, and allowing
> the language from 3.1 to apply, by changing the language to “if the root
is recognized for
> issuing EV certificates”.

I think it might need to be phased in or have some effective date. Also, I
haven't mapped out how this might affect CAs that we sometimes add to the
root store without EV enablement and with the suggestion that they apply
later for it.

On Sat, Oct 17, 2020 at 12:26 AM Ryan Sleevi  wrote:

>
>
> On Thu, Oct 15, 2020 at 4:36 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>  This issue is presented for resolution in the next version of the Mozilla
>> Root Store Policy. It is related to Issue #147
>> <https://github.com/mozilla/pkipolicy/issues/147> (previously posted for
>> discussion on this list on 6-Oct-2020).
>>
>> Possible language is presented here:
>>
>> https://github.com/BenWilson-Mozilla/pkipolicy/commit/c1acc76ad9f05038dc82281532fb215d71d537d4
>>
>> In addition to replacing "if issuing EV certificates" with "if capable of
>> issuing EV certificates" in two places -- for WebTrust and ETSI audits --
>> it would be followed by "(i.e. a subordinate CA under an EV-enabled root
>> that contains no EKU or the id-kp-serverAuth EKU or anyExtendedKeyUsage
>> EKU, and a certificatePolicies extension that asserts the CABF EV OID of
>> 2.23.140.1.1, the anyPolicy OID, or the CA's EV policy OID)." Thus,
>> Mozilla
>> considers that a CA is capable of issuing EV certificates if it is (1) a
>> subordinate CA (2) under an EV-enabled root (3) that contains no EKU or
>> the
>> id-kp-serverAuth EKU or anyExtendedKeyUsage EKU, and (4) a
>> certificatePolicies extension that asserts the CABF EV OID of
>> 2.23.140.1.1,
>> the anyPolicy OID, or the CA's EV policy OID.
>>
>> I look forward to your suggestions.
>
>
> Given the continuing issues we see with respect to audits, it seems like
> this notion of “technically constrained (from issuing EV) sub-CA” is going
> to encounter many of the same fundamental issues we’ve seen with audit
> scopes being incorrect and improper.
>
> It seems the easiest, and best (for users) way, is to ensure that once a
> root is trusted for a given purpose, as much as possible it’s ensured that
> *all* CA certificates beneath that hierarchy are included within the scope
> of the audit.
>
> It’s already well-accepted that, for example, the expectations of the BR
> audits still apply even if a CA has not issued, whether that “not issued”
> was because it has never issued a very (e.g. just created and not used
> yet), whether it is no longer issuing certs (e.g. it is being retired),
> *and* for situations where the key had previously issued certs, but did not
> issue certs within the audit period (e.g. a pause, rather than simply not
> being used yet).
>
> For separate purposes (e.g. S/MIME vs TLS), we know there are practical
> reasons to ensure separate hierarchies; most pragmatic of them being the
> creation of certificates for one purpose that impact the trustworthiness of
> certificates for another purpose (e.g. S/MIME certs, both those technically
> separated and those merely “intended” for S/MIME, impacting TLS trust, such
> as we saw with the recent OCSP issue).
>
> Because of this, it seems that there is a simpler, clearer, unambiguous
> path for CAs that seems useful to move to:
> - If a CA is trusted for purpose X, that certificate, and all subordinate
> CAs, should be audited against the criteria relevant for X
>
> This would avoid much of the confusion CAs seemingly continue to encounter
> with respect to audit scope, disclosure, and intent, by making it as simple
> as “If you signed it, you audit it.”
>
> If we apply this concept to the proposed language, then the requirement
> for an EV audit is simply about whether there is any unexpired, unrevoked
> path to a root CA which can issue EV certificates. Similarly, checking the
> scope for an EV audit becomes “the entire hierarchy”.
>
> This is accomplished by simply removing your proposed “(i.e. ...)”
> parenthetical, and allowing the language from 3.1 to apply, by changing the
> language to “if the root is recognized for issuing EV certificates”.
>
> From an audit ingestion point, and for CAs, it becomes easier now: the
>

NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

Dear All,

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process,
https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
through 9). Mozilla is considering approval of NAVER Business Platform
Corp.’s request to include the NAVER Global Root Certification Authority as
a trust anchor with the websites trust bit enabled, as documented in the
following Bugzilla case:
https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a
3-week comment period, after which if no concerns are raised, we will close
the discussion and the request may proceed to the approval phase (Step 10).

*A Summary of Information Gathered and Verified appears here in the CCADB:*

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261

*NAVER Global Root Certification Authority, *valid from 8/18/2017 to
8/18/2037

SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265

https://crt.sh/?id=1321953839

*Root Certificate Download:*

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST_file_nm=1c3763b33dbf457d8672371567fd1a12.crt_real_file_nm=naverrca1.crt


*CP/CPS:*

Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
through 42 in Bugzilla contain discussion concerning the CPS and revisions
thereto.

Current CPS is version 1.4.3:

https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf_real_file_nm=NBP%20Certification%20Practice%20Statement%20v1.4.3.pdf

Repository location:  https://certificate.naver.com/bbs/initCrtfcJob.do

*BR Self Assessment* (Excel file) is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9063955

*Audits:*  Annual audits are performed by Deloitte according to the
WebTrust Standard and WebTrust Baseline Requirements audit criteria. See
webtrust.org. The last complete audit period for NAVER was from 1 December
2018 to 30 November 2019 and no issues were found. However, the audit
report was dated 28 April 2020, which was more than three months following
the end of the audit period. The explanation for the delay in obtaining the
audit report was as follows, “NBP had received a notification mail on
updating the audit information from CCADB support in March since the Root
certificate is only included into Microsoft Root Program. According to
instructions on the email, I explained that NBP would submit the audit
update information in April to Microsoft.”  The current audit period ends
30 November 2020.

*Mis-Issuances *

According to crt.sh and censys.io, the issuing CA under this root
(NAVER Secure Certification Authority 1) has issued approximately 80
certificates. I ran the following query for the issuing CA to identify any
mis-issuances:
https://crt.sh/?caid=126361=cablint,zlint,x509lint=2017-08-18,
and during the course of our review, we identified six test certificates
with errors. (Such certificates have either been revoked or have expired).
See:

https://crt.sh/?id=2132664529=cablint,zlint,x509lint

https://crt.sh/?id=2102184572=cablint,zlint,x509lint

https://crt.sh/?id=1478365347=cablint,zlint,x509lint

https://crt.sh/?id=2149282089=cablint,zlint,x509lint

https://crt.sh/?id=2149282369=cablint,zlint,x509lint

https://crt.sh/?id=2282123486=cablint,zlint,x509lint

The explanation provided (
https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c27) was “Regarding
CA/B Forum and X.509 lint tests NBP figured out two(2) certificates which
were not complied with BRs right after issuing them. The domains on SANs of
the certificates were owned and controlled by NBP. They were immediately
revoked according to CA procedures. For ZLint tests, the certificate (CN=
test2-certificate.naver.com) had been issued and became expired in
compliance with CA Browser Forum BRs and RFC 5280. I understand there is a
specific Mozilla policy on Authority Key IDs. NBP already fixed the system
functions. There is no such valid certificate and NBP CA currently issues
certificates fully complied with the Mozilla policy. You can see the new
certificate (CN= test2-certificate.naver.com) was issued without any error
at https://crt.sh/?id=2824319278.”

I have no further questions or concerns at this time, however I urge anyone
with concerns or questions to raise them by replying to this list under the
subject heading above.

Again, this email begins a three-week public discussion period, which I’m
scheduling to close on Monday, 2-November-2020.

Sincerely yours,

Ben Wilson

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

MRSP Issue #139: Audits required even if not issuing

[Ben Wilson via dev-security-policy]

 Here is the first issue for discussion here on the m.d.s.p. list relative
to the next version of the Mozilla Root Store Policy (v.2.7.1).

#139  - Audits are
required even if no longer issuing - Clarify that audits are required until
the CA certificate is revoked, expired, or removed. Related to Issue #153
.

Seven (7) comments are listed so far for this issue in GitHub, including
discussion re: whether auditors can provide reports when a CA isn't being
used to issue certificates.

I made an initial attempt to address this with some language in line 272 in
the following commit in my GitHub repository -
https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
(related changes also appear below in that commit).

The suggested language would amend the first paragraph of section 3.1.3 of
the MRSP to read, "Full-surveillance period-of-time audits MUST be
conducted and updated audit information provided no less frequently than
*annually* from the time of CA key pair generation until the CA certificate
is no longer trusted by Mozilla's root store or until all copies of the CA
private key have been completely destroyed, as evidenced by a Qualified
Auditor's key destruction report, whichever occurs sooner. Successive
period-of-time audits MUST be contiguous (no gaps)."

We will need to discuss scope and timing for implementing this requirement.

Thanks in advance for your contributions and suggestions.

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

MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

[Ben Wilson via dev-security-policy]

 #147  - Require EV audits
for certificates capable of issuing EV certificates – Clarify that EV
audits are required for all intermediate certificates that are technically
capable of issuing EV certificates, even when not currently issuing EV
certificates.

This issue is presented for resolution in the next version of the Mozilla
Root Store Policy.

Suggested language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b


The proposal is to replace "if issuing EV certificates" with "if capable of
issuing EV certificates" in two places -- for WebTrust and ETSI audits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Corey,
We will add this to the 2.7.1 batch of proposed changes. I've started
discussion of Issue 147, so we can discuss it there, or I can create a
separate email thread for it.

On Fri, Oct 2, 2020 at 5:16 AM Corey Bonnell  wrote:

> Including https://github.com/mozilla/pkipolicy/issues/152 would be a
> useful clarification alongside issue 147, as it will better define the
> parameters that determine if a given intermediate is “EV capable”.
>
> Thanks,
> Corey
> --
> *From:* dev-security-policy 
> on behalf of Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> *Sent:* Thursday, October 1, 2020 4:21:48 PM
> *To:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Policy 2.7.1 Issues to be Considered
>
> Below is a list of issues that I propose be addressed in the next version
> (2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73
> issues related to the MRSP listed here:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissuesdata=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097sdata=GZ8%2F%2FJg0sa%2FKAPcRes4w1tWPtQrXfd3xAdjoEY62gBQ%3Dreserved=0.
> So far, I have identified 13
> items to consider for this policy update; which are tagged as v.2.7.1 in
> GitHub (
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Flabels%2F2.7.1data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097sdata=fNzV%2FEjnNTWKsA%2BNMJo08ESzNttlkIHINUr23jRy%2F5E%3Dreserved=0).
> I will
> appreciate your input on this list as to whether there are issues that
> should be added or removed. Then, based on the list, I will start a
> separate discussion thread in mozilla.dev.security.policy for each issue.
>
> #139 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F139data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097sdata=7xarPFNWPfgfEcddgA%2BsVk23dViiNv9QRxpEoqjp1vk%3Dreserved=0>
> - Audits are
> required even if no longer issuing - Clarify that audits are required until
> the CA certificate is revoked, expired, or removed. Related to Issue #153.
>
> #147 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F147data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092sdata=kt7ywgVE5S6VqWB47cNsTf943OyNzdtSEbqA14%2F4TYo%3Dreserved=0>
> - Require EV audits
> for certificates capable of issuing EV certificates – Clarify that EV
> audits are required for all intermediate certificates that are technically
> capable of issuing EV certificates, even when not currently issuing EV
> certificates.
>
> #153 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F153data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092sdata=FToJiGI1xtCsEBHmmRsB2P%2Fv%2B8SFqze5HouMkmsJ8lc%3Dreserved=0>
> – Cradle-to-Grave
> Contiguous Audits – Specify the audits that are required from Root key
> generation ceremony until expiration or removal from Mozilla’s root store.
> Related to Issue #139.
>
> #154 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F154data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092sdata=qEnD7LC%2FXsEF3Hs7u68fxA4fNAPFaP7rGLox7GvIjn4%3Dreserved=0>
> - Require Management
> Assertions to list Non-compliance – Add to MRSP 2.4 “If being audited to
> the WebTrust criteria, the Management Assertion letter MUST include all
> known incidents that occurred or were still open/unresolved at any time
> during the audit period.”
>
> #173 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F173data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092sdata=THxcETFV6slWGx4h3Y9E9l4OVcRvCf43iPjtoqqpIzc%3Dreserved=0>
> - Strengthen
> requirement for newly included roots to meet all past and present
> requirements – Add language to MRSP 7.1 so that it is clear that before
> being included CAs must comply and have complied with past and present
> Mozilla Root Store Policy and Baseline Requirements.
>
> #186 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com

Re: Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Doug,
I don't have any preconceived notions. I was hoping that by discussing the
implementation issues for each issue we could determine appropriate
timeframes.
Ben

On Tue, Oct 6, 2020 at 12:19 PM Doug Beattie 
wrote:

> Ben,
>
> When, approximately, do you think this proposed updates would become
> effective, and specifically this item:
>
>https://github.com/mozilla/pkipolicy/issues/206
>
> Doug
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Thursday, October 1, 2020 4:22 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Policy 2.7.1 Issues to be Considered
>
> Below is a list of issues that I propose be addressed in the next version
> (2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73
> issues related to the MRSP listed here:
> https://github.com/mozilla/pkipolicy/issues. So far, I have identified 13
> items to consider for this policy update; which are tagged as v.2.7.1 in
> GitHub (https://github.com/mozilla/pkipolicy/labels/2.7.1). I will
> appreciate your input on this list as to whether there are issues that
> should be added or removed. Then, based on the list, I will start a
> separate discussion thread in mozilla.dev.security.policy for each issue.
>
> #139 <https://github.com/mozilla/pkipolicy/issues/139> - Audits are
> required even if no longer issuing - Clarify that audits are required until
> the CA certificate is revoked, expired, or removed. Related to Issue #153.
>
> #147 <https://github.com/mozilla/pkipolicy/issues/147> - Require EV
> audits for certificates capable of issuing EV certificates – Clarify that
> EV audits are required for all intermediate certificates that are
> technically capable of issuing EV certificates, even when not currently
> issuing EV certificates.
>
> #153 <https://github.com/mozilla/pkipolicy/issues/153> – Cradle-to-Grave
> Contiguous Audits – Specify the audits that are required from Root key
> generation ceremony until expiration or removal from Mozilla’s root store.
> Related to Issue #139.
>
> #154 <https://github.com/mozilla/pkipolicy/issues/154> - Require
> Management Assertions to list Non-compliance – Add to MRSP 2.4 “If being
> audited to the WebTrust criteria, the Management Assertion letter MUST
> include all known incidents that occurred or were still open/unresolved at
> any time during the audit period.”
>
> #173 <https://github.com/mozilla/pkipolicy/issues/173> - Strengthen
> requirement for newly included roots to meet all past and present
> requirements – Add language to MRSP 7.1 so that it is clear that before
> being included CAs must comply and have complied with past and present
> Mozilla Root Store Policy and Baseline Requirements.
>
> #186 <https://github.com/mozilla/pkipolicy/issues/186> - Clarify MRSP 5.3
> Requirement to Disclose Self-signed Certificates – Clarify that self-signed
> certificates with the same key pair as an existing root meets MRSP 5.3’s
> definition of an intermediate certificate that must be disclosed in the
> CCADB.
>
> #187 <https://github.com/mozilla/pkipolicy/issues/187> - Require
> disclosure of incidents in Audit Reports –  To MRSP 3.1.4 “The
> publicly-available documentation relating to each audit MUST contain at
> least the following clearly-labelled information: “ add “11. all incidents
> (as defined in section 2.4) that occurred or were still open/unresolved at
> any time during the audit period, or a statement that the auditor is
> unaware of any;”
>
> #192 <https://github.com/mozilla/pkipolicy/issues/192> - Require
> information about auditor qualifications in the audit report – Require
> audit statements to be accompanied by documentation of the auditor’s
> qualifications demonstrating the auditor’s competence and experience.
>
> #205 <https://github.com/mozilla/pkipolicy/issues/205> - Require CAs to
> publish accepted methods for proving key compromise – Require CAs to
> disclose their acceptable methods for proving key compromise in section
> 4.9.12 of their CPS.
>
> #206 <https://github.com/mozilla/pkipolicy/issues/206> - Limit re-use of
> domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
> verify ownership/control of each dNSName and iPAddress in the certificate's
> subjectAltName at intervals of 398 days or less;”
>
> #207 <https://github.com/mozilla/pkipolicy/issues/207> - Require audit
> statements to provide information about which CA Locations were and were
> not audited, and the extent to which they were (or were not) audited
>
> #211 <https://github.com/mozilla/pkipolicy/issues/211

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Dear Steven,
CA certificates can have a validity longer than 398 days. The policy
applies to the validity period of TLS server certificates. At the CA level,
it will be enforced as a compliance issue in the root store when we accept
or remove a root CA in the "publicly trusted" root store. It will also be
enforced at the server-certificate level, through the incident-reporting
process and treated as a mis-issuance. See
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents.
However, if a user installs its own CA certificate, then that CA can issue
server certificates with validity longer than 398 days. The code will check
the TLS server certificate to see if it chains to a publicly trusted root
and whether it was issued on or after 1-Sept-2020. If so, then if it does
not have a lifetime of less than 398 days, the TLS connection will be
blocked and there will be a warning message. See
https://bugzilla.mozilla.org/show_bug.cgi?id=908125
Does that answer your question?
Thanks,
Ben

On Tue, Aug 25, 2020 at 10:42 AM None Of via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:
> > Hi Christian,
> > I think your concern is about how our code will enforce this. Because
> our
> > policy only applies to roots that are built in, our intent is to have
> our
> > code apply this restriction only to certificates that chain up to
> built-in
> > roots.
> > Thanks,
> > Ben
> > On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via
> dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> > > >
> > >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
> > >
> > > Hi,
> > >
> > > blog post should clarify if this is valid for certificates issued by
> > > preinstalled root CAs only or also for CAs installed by user.
> > >
> > >
> > > regards
> > > Christian
> > > ___
> > > dev-security-policy mailing list
> > > dev-secur...@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> Hello Ben,
>
> I also would like clarification as to whether this change is an
> "administrative change" for Mozilla accepting CAs in the included root
> store, or whether it will be a technical change in how Firefox validates CA
> certificate validity.
>
> If users install a CA cert that has a validity longer than 398 days after
> 1 Sept 2020, will this cause warning messages to appear?
> ___
> 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: Verifying Auditor Qualifications

[Ben Wilson via dev-security-policy]

In a draft template for audit attestations, provided by the ACAB'c, the
template would provide a URL to the NAB's certification of the CAB with a
statement that the NAB had certified the CAB to perform "certification of
trust services according to 'EN ISO/IEC 17065:2012' and 'ETSI EN 319 403
V2.2.2 (2015-08)' " but with a note that the CAB could update the template
based on actual certifications received from the NAB. This raises the
question of whether NABs typically include ETSI EN 319 401, ETSI EN 319
411-1 and ETSI EN 319 411-2 in such CAB certification records. If not,
maybe references to EN ISO/IEC 17065:2012 and ETSI EN 319 403 V2.2.2
(2015-08) would then need to be sufficient. That is something that would be
good to know.

Thanks, Kathleen

On Wed, Aug 26, 2020 at 12:54 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 6/3/20 4:20 PM, Kathleen Wilson wrote:
> > It recently came to my attention that I need to be more diligent in
> > verifying auditor qualifications.
> > 
> > https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications
>
> All,
>
> While re-verifying auditor qualifications I have run into the following
> situation, that I will appreciate your opinions on.
>
>
> https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check
>
>  >> Check 1:  The NAB is listed as “full member” under
>
> https://european-accreditation.org/ea-members/directory-of-ea-members-and-mla-signatories/
>
> The NAB, Accredia (https://www.accredia.it/) is listed as a "Full Member".
>
>
>  >> Check 2:  The accreditation documentation was issued by that NAB and
> is hosted on the NAB's website
>
> The accreditation documentation on the NAB's website for a few CABs:
>
> QMSCERT:
>
> http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733=310_ORG_SEARCH_MASK_ORG=3761
>
> Bureau Veritas Italia:
>
> http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733=310_ORG_SEARCH_MASK_ORG=0663
>
> CSQA:
>
> http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733=310_ORG_SEARCH_MASK_ORG=0010
>
>
>  >> Check 3: The CABs accreditation documentation explicitly refers to
> all of the following:  411-1, and ETSI EN 319 411-2>
>
> This is where I'm running into difficulty. The NAB's accreditation
> documentation does not explicitly state that the CAB is certified to
> audit against those ETSI EN standards.
>
> For each of the CABs listed above, an Allegato (for UNI CEI EN/ISO/IEC
> 17065:2012) can be downloaded that says: "TSP (Trust Service Provider)
> and the services they offer compared with (EU Regulation) 910/2014 and /
> or specific provisions adopted by the national authorities for the
> services covered by the Accreditation Scheme."
>
> Which apparently refers to the the following documents that list the
> ETSI EN standards:
> Italian:
>
> https://www.accredia.it/app/uploads/2020/03/Circolare_tecnica_DC_05-2020.pdf
> English:
> https://www.accredia.it/app/uploads/2017/03/7015_DC2017SSV046eng.pdf
>
> https://www.accredia.it/documento/circolare-dc-n-82017-informativa-in-merito-allaccreditamento-degli-organismi-di-certificazione-operanti-a-fronte-dei-requisiti-del-regolamento-ue-2014_910-eidas-e-della-norma-etsi-en-319_4/
>
>
> Is that sufficient evidence that the CAB is certified by the NAB to
> audit according to the ETSI EN 319 403, ETSI EN 319 401, ETSI EN 319
> 411-1, and ETSI EN 319 411-2 standards?
>
> Thanks,
> Kathleen
>
>
>
>
>
>
> ___
> 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

Sectigo to Be Acquired by GI Partners

[Ben Wilson via dev-security-policy]

 As announced previously by Rob Stradling, there is an agreement for
private investment firm GI Partners, out of San Francisco, CA, to acquire
Sectigo. Press release:
https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners.


I am treating this as a change of legal ownership covered by section 8.1

of the Mozilla Root Store Policy, which states:

> If the receiving or acquiring company is new to the Mozilla root program,
> it must demonstrate compliance with the entirety of this policy and there
> MUST be a public discussion regarding their admittance to the root
program,
> which Mozilla must resolve with a positive conclusion in order for the
> affected certificate(s) to remain in the root program.

In order to comply with policy, I hereby formally announce the commencement
of a 3-week discussion period for this change in legal ownership of Sectigo
by requesting thoughtful and constructive feedback from the community.

Sectigo has already stated that it foresees no effect on its operations due
to this ownership change, and I believe that the acquisition announced by
Sectigo and GI Partners is compliant with Mozilla policy.

Thanks,

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

Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Below is a list of issues that I propose be addressed in the next version
(2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73
issues related to the MRSP listed here:
https://github.com/mozilla/pkipolicy/issues. So far, I have identified 13
items to consider for this policy update; which are tagged as v.2.7.1 in
GitHub (https://github.com/mozilla/pkipolicy/labels/2.7.1). I will
appreciate your input on this list as to whether there are issues that
should be added or removed. Then, based on the list, I will start a
separate discussion thread in mozilla.dev.security.policy for each issue.

#139  - Audits are
required even if no longer issuing - Clarify that audits are required until
the CA certificate is revoked, expired, or removed. Related to Issue #153.

#147  - Require EV audits
for certificates capable of issuing EV certificates – Clarify that EV
audits are required for all intermediate certificates that are technically
capable of issuing EV certificates, even when not currently issuing EV
certificates.

#153  – Cradle-to-Grave
Contiguous Audits – Specify the audits that are required from Root key
generation ceremony until expiration or removal from Mozilla’s root store.
Related to Issue #139.

#154  - Require Management
Assertions to list Non-compliance – Add to MRSP 2.4 “If being audited to
the WebTrust criteria, the Management Assertion letter MUST include all
known incidents that occurred or were still open/unresolved at any time
during the audit period.”

#173  - Strengthen
requirement for newly included roots to meet all past and present
requirements – Add language to MRSP 7.1 so that it is clear that before
being included CAs must comply and have complied with past and present
Mozilla Root Store Policy and Baseline Requirements.

#186  - Clarify MRSP 5.3
Requirement to Disclose Self-signed Certificates – Clarify that self-signed
certificates with the same key pair as an existing root meets MRSP 5.3’s
definition of an intermediate certificate that must be disclosed in the
CCADB.

#187  - Require disclosure
of incidents in Audit Reports –  To MRSP 3.1.4 “The publicly-available
documentation relating to each audit MUST contain at least the following
clearly-labelled information: “ add “11. all incidents (as defined in
section 2.4) that occurred or were still open/unresolved at any time during
the audit period, or a statement that the auditor is unaware of any;”

#192  - Require
information about auditor qualifications in the audit report – Require
audit statements to be accompanied by documentation of the auditor’s
qualifications demonstrating the auditor’s competence and experience.

#205  - Require CAs to
publish accepted methods for proving key compromise – Require CAs to
disclose their acceptable methods for proving key compromise in section
4.9.12 of their CPS.

#206  - Limit re-use of
domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
verify ownership/control of each dNSName and iPAddress in the certificate's
subjectAltName at intervals of 398 days or less;”

#207  - Require audit
statements to provide information about which CA Locations were and were
not audited, and the extent to which they were (or were not) audited

#211  - Align OCSP
requirements in Mozilla's policy with the section 4.9.10 of the Baseline
Requirements
#218  Clarify CRL
requirements for End Entity Certificates – For CRLite, Mozilla would like
to ensure that it has full lists of revoked certificates. If the CA uses
partial CRLs, then require CAs to provide the URL location of their full
and complete CRL in the CCADB.

Ben Wilson
Mozilla Root Program Manager
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

In accordance with the CA inclusion process,[1] this is a summary of the
public discussion of Microsec’s application for inclusion of the e-Szigno
Root CA 2017 into the Mozilla root store, and to EV enable it and the
currently-included e-Szigno Root CA 2009. The request is documented in
Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
email launching the public discussion and comments received during the
public discussion raised a number of issues, not all of which are itemized
here, including:

* the CPS was unclear about certificate problem reporting and revocation
request processing[4]; and

* Microsec has had systemic, standards-related non-conformities, e.g. Bug#
1622539[5], and needs to demonstrate better behavior in keeping up with and
complying with the CABF Baseline Requirements and root store policy.[6]

Microsec is resolving these concerns by:

- updating its CPS[7][8]; and

- committing to engage in better compliance with industry standards[9].

In my opinion Microsec has demonstrated sufficient response that we do not
need to remove Microsec from Mozilla’s root store. Therefore, once I am
satisfied after a review of the updated CPS, I am planning to recommend
that we approve the request to include the e-Szigno Root CA 2017
certificate and enable the websites trust bit. However, I plan to deny the
request for EV treatment for both root certificates. Microsec may re-apply
by filing a new request for EV treatment after they have demonstrated
improved compliance with the BRs and EV Guidelines.

I appreciate any feedback on this proposed course of action.

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364

[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ

[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ


[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539

[6]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ


[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ


[8]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30


[9]
https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ



On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Dear Ben,
>
> I confirm that Microsec will correct all issues in the CP and CPS
> documents as promised during the public discussion.
>
> Thanks to everyone who took the time to read Microsec CP and CPS and to
> comment on them.
>
> If there are no more comments on the content of our CP and CPS documents
> in the public discussion, we will review the thread again and gather all
> the issues to be resolved.
> As usual, Microsec will review current versions of all applicable
> requirements for changes.
>
> I confirm that the section 1.5.2 will be changed. The High Priority
> Certificate Problem Report will be reviewed and will be moved here from
> section 4.9.3.
>
> Other issues I can see after a brief overview:
> - Preliminary report in case of Certificate problem report in section 4.9.5
> - correct the reference to section 1.3.1 instead of 1.2 in section 4.9.5
> - review the email address validation rules in case of non-automatic
> validation procedure in section 3.2.7
>
> I expect that Microsec will be able to do it within one week and will
> prepare the draft version of the public documents by the end of April.
>
> We publish the drafts on our website and send them to the auditor and our
> supervisory authority at the same time.
>
> This is followed by a 30-day commenting period during which anyone can
> comment on the planned changes.
> If significant issues arise during this period, the draft shall be amended
> and the 30 days shall begin again.
> If there are no significant issues, the new document will enter into force
> by the end of May 2020.
>
> Please let us know if you expect us to take any further steps in this
> process.
>
> Best regards,
>
> Sándor
>
> dr. Sándor Szőke
> Microsec deputy director
> ___
> 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: Request to Include certSIGN Root CA G2 certificate

[Ben Wilson via dev-security-policy]

In accordance with the CA inclusion process[1], this is a summary of the
public discussion of Certsign’s application for inclusion of the certSIGN
ROOT CA G2 into the Mozilla root store with the websites trust bit and EV
enabled. The request is documented in Bugzilla #1403453[2]. The public
discussion began on 6-May-2020[3].

During the public discussion, it was noted that the audit report listed six
minor non-conformities regarding documentation and process
implementation[4]. Of primary concern was recordkeeping of the CA key
shares. Certsign responded that all six non-conformities, including key
share recordkeeping, had been remediated[5]. Specifically with regard to
the CA key shares, Certsign has registered its DR backup shares in its
asset inventory, card custody is recorded, use of secrets by the
application is logged by a script, and person(s) with access to the
safeboxes no longer has/have access to the room where the safeboxes are
stored.[6]

No other comments were received.

Based on a totality of the information presented and reviewed, I am
planning to recommend that Certsign’s application be approved.


I appreciate any feedback on this proposed course of action.

[1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1403453

[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/rJke0W6eAwAJ


[4] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635

[5] https://bugzilla.mozilla.org/attachment.cgi?id=9149366

[6]
https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/Nfbq64TyBwAJ


On Wed, May 13, 2020 at 3:18 AM Gabriel Petcu via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Saturday, May 9, 2020 at 12:56:00 AM UTC+3, Wayne Thayer wrote:
> > The ETSI audit attestation statement referenced by Ben [1] lists 6
> > non-conformities that were to be corrected within 3 months of the onsite
> > audit that occurred on 2020-02-10 until 2020-02-14:
> >
> > Findings with regard to ETSI EN 319 401:
> > -REQ-7.8-06–Documentation shall be improved
> >
> > Findings with regard to ETSI EN 319 411-1:
> > -REG-6.3.1-01–Implementation shall be improved
> > -GEN-6.5.1-04-Implementation shall be improved
> >
> > Findings with regard to ETSI EN 319 411-2:
> > -SDP-6.5.1-02 -Implementation shall be improved
> > -GEN-6.6.1-05–Documentation shall be improved
> > -CSS-6.3.10-13–Documentation shall be improved
> >
> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for
> > signing certificates shall be created under, at least, dual control.
> >
> > I'd like to see an explanation of these non-conformities and the
> > remediation from certSIGN, and confirmation from LSTI that they have been
> > fixed.
> >
> > - Wayne
> >
> > [1] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
> >
> > On Wed, May 6, 2020 at 4:59 PM Ben Wilson via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > This request is for inclusion of the certSIGN Root CA G2 certificate
> and to
> > > turn on the Websites trust bit and for EV treatment.
> > >
> > >
> > > The request is documented in Bugzilla and in the CCADB as follows:
> > >
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
> > >
> > >
> > >
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0403
> > >
> > > (Summary of info gathered and verified, URLs for test websites, etc.)
> > >
> > >
> > >
> > > * certSIGN’s BR Self Assessment is here:
> > >
> > > https://bugzilla.mozilla.org/attachment.cgi?id=9052673
> > >
> > > The Certsign document repository can be found here:
> > >
> > > https://www.certsign.ro/en/certsign-documents/policies-procedures
> > >
> > > * Root Certificate Locations:
> > >
> > > http://crl.certsign.ro/certsign-rootg2.crt
> > >
> > > http://registru.certsign.ro/certcrl/certsign-rootg2.crt
> > >
> > > http://www.certsign.ro/certcrl/certsign-rootg2.crt
> > >
> > >
> > >
> https://crt.sh/?q=657CFE2FA73FAA38462571F332A2363A46FCE7020951710702CDFBB6EEDA3305
> > >
> > >
> > >
> https://censys.io/certificates/657cfe2fa73faa38462571f332a2363a46fce7020951710702cdfbb6eeda3305/pem
> > >
> > >
> > > * EV Policy OID:   2.23.140.1.1
> > >
> > > * CRL URL: http://crl.certsign.ro/certsign-rootg2.crl
> > >
> > > * OCSP URL: http://ocsp.certsign.ro
> > >

Re: EV-enablement Request of Identrust

[Ben Wilson via dev-security-policy]

Based on the record in Bugzilla Case 1551703 and the CCADB Case 417 (
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417)
, and receiving no further comments, I have recommended approval of this
request to EV-enable the Identrust Commercial Root CA 1.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1551703#c13


On Fri, Jul 31, 2020 at 10:28 AM Ben Wilson  wrote:

> Today is the close of the comment period for the Identrust EV enablement
> request. I don't believe we have received any comments, and I intend to
> recommend that this request be approved unless there are any reasons why
> the request should be denied.
> Thanks,
> Ben
>
> On Fri, Jul 10, 2020 at 4:05 PM Ben Wilson  wrote:
>
>> This is a request to EV-enable the IdenTrust Commercial Root CA 1, as
>> documented here:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703
>>
>> *  Summary of Information Gathered and Verified:
>>
>>
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417
>>
>> *  SHA2 hash for Root CA Certificate:
>> 5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE
>>
>> *  Root Certificate Download URL:
>>
>> http://validation.identrust.com/roots/commercialrootca1.p7c
>>
>> *  Identrust’s BR Self Assessment is located here:
>>
>> https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel
>> Spreadsheet Download)
>>
>> *  CPS:
>>
>>
>> https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf
>>
>> *  Test Website:
>>
>> https://ev-valid.identrustssl.com/
>>
>> *  EV Policy OIDs:
>>
>> 2.16.840.1.113839.0.6.9,  2.23.140.1.1
>>
>> * CRL URL:
>>
>> http://validation.identrust.com/crl/commercialrootca1.crl
>>
>> *  OCSP URL:
>>
>> http://commercial.ocsp.identrust.com
>>
>> *  Audit:
>>
>> A period of time WebTrust EV annual audit report was provided on August
>> 16, 2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That
>> and other WebTrust audit reports are available from the bottom of the
>> following applicant page:
>> https://www.identrust.com/support/documents/trustid.
>>
>>
>> I’ve reviewed the CPS, BR Self Assessment, and related information for
>> this inclusion request.  Comments and concerns regarding the CPS were
>> satisfactorily addressed as noted in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703.  I now recommend
>> that the IdenTrust Commercial Root CA 1 be enabled for Extended Validation
>> treatment.
>>
>>
>> This begins the 3-week comment period for this request.
>>
>>
>> I will greatly appreciate your thoughtful and constructive feedback on
>> Identrust’s request.
>>
>> Sincerely yours,
>>
>> Ben Wilson
>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SecureTrust: Root Certificates Inclusion Request

[Ben Wilson via dev-security-policy]

This email announces an intent to include the following three (3) root
certificates as trust anchors with the websites and email trust bits
enabled, and to enable each root for EV as documented in the following
Bugzilla case:  https://bugzilla.mozilla.org/show_bug.cgi?id=1528369

This email commences the three-week public discussion period set forth in
https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion.

The three root CA certificates are as follows:

*Trustwave Global Certification Authority* – valid from 23-Aug-2017

SHA2: 97552015F5DDFC3C8788C006944555408894450084F100867086BC1A2BB58DC8

*Trustwave Global ECC P256 Certification Authority* – valid from 23-Aug-2017

SHA2: 945BBC825EA554F489D1FD51A73DDF2EA624AC7019A05205225C22A78CCFA8B4

*Trustwave Global ECC P384 Certification Authority* –

SHA2: 55903859C8C0C3EBB8759ECE4E2557225FF5758BBD38EBD48276601E1BD58097


*A Summary of Information Gathered and Verified appears here in the CCADB:*
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0392


*Root Certificate Download URLs are as follows:*
https://certs.securetrust.com/CA/TWGCA.txt

https://certs.securetrust.com/CA/TWGP256CA.txt

https://certs.securetrust.com/CA/TWGP384CA.txt

*CP/CPS:*  We have reviewed the CPS and provided comments, which were
incorporated into SecureTrust's most recent CPS:

https://certs.securetrust.com/CA/SecureTrustCPS_62.pdf

(Repository location:  https://ssl.trustwave.com/CA /
https://certs.securetrust.com/CA/)

*SecureTrust’s BR Self Assessment* is located here:
https://bugzilla.mozilla.org/attachment.cgi?id=9060769

*Audits:*  Annual audits are performed by BDO International, Ltd. according
to the WebTrust Standard, BR and EV audit criteria.  I have reviewed the
key generation audit report from Grant Thornton and subsequent 2018 and
2019 audit reports for these three roots and determined that there is
continuity (all three are included in WebTrust Standard, BR and EV audits
continuously since CA generation). Minor issues were found by BDO
International, Ltd., as part of the 2019 Baseline Requirements audit.[1]
These issues were addressed in [2], which was closed by Mozilla on
14-Mar-2020.

[1]
https://certs.securetrust.com/CA/2%20-%20SecureTrust%202019%20SSL%20BL%20Report.pdf

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1606031  (BR Audit 2019 -
matters to be resolved)


I ran mis-issuance reports for the three roots with linting to look for
issuance errors and didn’t find any from the three above-mentioned roots.


Other closed CA Incidents for SecureTrust include the following:

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1546776  (Unvalidated
domain in certificate )

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1551374  ("Some-State" in
stateOrProvinceName)

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1600844 (Unconstrained ICA
not included in WTBR audit report)

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1646711 (Metadata-only
field values in 2 certificates)


This email begins the three-week public discussion period, which will close
on 24-August-2020.

Sincerely yours,

Ben Wilson

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

Re: EV-enablement Request of Identrust

[Ben Wilson via dev-security-policy]

Today is the close of the comment period for the Identrust EV enablement
request. I don't believe we have received any comments, and I intend to
recommend that this request be approved unless there are any reasons why
the request should be denied.
Thanks,
Ben

On Fri, Jul 10, 2020 at 4:05 PM Ben Wilson  wrote:

> This is a request to EV-enable the IdenTrust Commercial Root CA 1, as
> documented here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703
>
> *  Summary of Information Gathered and Verified:
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417
>
> *  SHA2 hash for Root CA Certificate:
> 5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE
>
> *  Root Certificate Download URL:
>
> http://validation.identrust.com/roots/commercialrootca1.p7c
>
> *  Identrust’s BR Self Assessment is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel Spreadsheet
> Download)
>
> *  CPS:
>
>
> https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf
>
> *  Test Website:
>
> https://ev-valid.identrustssl.com/
>
> *  EV Policy OIDs:
>
> 2.16.840.1.113839.0.6.9,  2.23.140.1.1
>
> * CRL URL:
>
> http://validation.identrust.com/crl/commercialrootca1.crl
>
> *  OCSP URL:
>
> http://commercial.ocsp.identrust.com
>
> *  Audit:
>
> A period of time WebTrust EV annual audit report was provided on August
> 16, 2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That
> and other WebTrust audit reports are available from the bottom of the
> following applicant page:
> https://www.identrust.com/support/documents/trustid.
>
>
> I’ve reviewed the CPS, BR Self Assessment, and related information for
> this inclusion request.  Comments and concerns regarding the CPS were
> satisfactorily addressed as noted in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1551703.  I now recommend
> that the IdenTrust Commercial Root CA 1 be enabled for Extended Validation
> treatment.
>
>
> This begins the 3-week comment period for this request.
>
>
> I will greatly appreciate your thoughtful and constructive feedback on
> Identrust’s request.
>
> Sincerely yours,
>
> Ben Wilson
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ben Wilson via dev-security-policy]

All,


Thank you to Ryan for identifying this problem, and to all of you who are
earnestly investigating what this problem means and the impact to your CA
hierarchies. Mozilla::pkix requires that an OCSP responder certificate be
an end entity certificate, so we believe that Firefox and Thunderbird are
not impacted by this problem. Historically, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=991209#c10, Mozilla has
allowed CA certificates to have the OCSP signing EKU because some CAs
reported that some Microsoft server software required CA certificates to
have the id-kp-OCSPSigning EKU.

The comments in the code[1] say

// When validating anything other than an delegated OCSP signing cert,

// reject any cert that also claims to be an OCSP responder, because such

// a cert does not make sense. For example, if an SSL certificate were to

// assert id-kp-OCSPSigning then it could sign OCSP responses for itself,

// if not for this check.

// That said, we accept CA certificates with id-kp-OCSPSigning because

// some CAs in Mozilla's CA program have issued such intermediate

// certificates, and because some CAs have reported some Microsoft server

// software wrongly requires CA certificates to have id-kp-OCSPSigning.

// Allowing this exception does not cause any security issues because we

// require delegated OCSP response signing certificates to be end-entity

// certificates.

Additionally, as you all know, Firefox uses OneCRL for checking the
revocation status of intermediate certificates, so as long as the revoked
intermediate certificate is in OneCRL, the third-party would not be able to
“unrevoke” their certificate (for Firefox). Therefore, Mozilla does not
need the certificates that incorrectly have the id-kp-OCSPSigning EKU to be
revoked within the next 7 days, as per section 4.9.1.2 of the BRs.

However, as Ryan has pointed out in this thread, others may still have risk
because they may not have a OneCRL equivalent, or they may have certificate
verification implementations that behave differently than mozilla::pkix in
regards to processing OCSP responder certificates. Therefore, it is
important to identify a path forward to resolve the security risk that this
problem causes to the ecosystem.

We are concerned that revoking these impacted intermediate certificates
within 7 days could cause more damage to the ecosystem than is warranted
for this particular problem. Therefore, Mozilla does not plan to hold CAs
to the BR requirement to revoke these certificates within 7 days. However,
an additional Incident Report for delayed revocation will still be
required, as per our documented process[2].  We want to work with CAs to
identify a path forward, which includes determining a reasonable timeline
and approach to replacing the certificates that incorrectly have the
id-kp-OCSPSigning EKU (and performing key destruction for them).

Therefore, we are looking forward to your continued input in this
discussion about the proper response for CAs to take to resolve the
security risks caused by this problem, and ensure that this problem is not
repeated in future certificates.  We also look forward to your suggestions
on how we can improve OCSP responder requirements in Mozilla’s Root Store
Policy, and to your continued involvement in the CA/Browser Forum to
improve the BRs.

Thanks,


Ben

[1]
https://dxr.mozilla.org/mozilla-central/rev/c68fe15a81fc2dc9fc5765f3be2573519c09b6c1/security/nss/lib/mozpkix/lib/pkixcheck.cpp#858-869

[2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation


On Wed, Jul 1, 2020 at 3:06 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I've created a new batch of certificates that violate 4.9.9 of the BRs,
> which was introduced with the first version of the Baseline Requirements as
> a MUST. This is https://misissued.com/batch/138/
>
> A quick inspection among the affected CAs include O fields of: QuoVadis,
> GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
> Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.
>
> Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
> Delegated Responder within Section 4.2.2.2 as indicated by the presence of
> the id-kp-OCSPSigning as an EKU.
>
> These certificates lack the necessary extension, and as such, violate the
> BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
> Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
> could also consider the effective date as 2013-05-15, described later in
> [1] , without changing the results.
>
> This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> 

New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

All,
This is just to let everyone know that I posted a new Mozilla Security blog
post this morning. Here is the link>
https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
As I note at the end of the blog post, we continue to seek safeguarding
secure browsing by working with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to keep our users
safe.
Thanks,
Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Thanks, Paul, for your comments and concerns regarding our reasons 2 and 3,
and the costs vs. benefits of going to a 398-day certificate lifetime.
We'll keep those in mind as we move forward. In response, the security of
our users is the primary concern for Mozilla. So while we recognize there
might be added costs and burdens, we still believe that they do not
outweigh the user security benefits of moving to a 398-day certificate
lifetime.
Thanks again,
Ben

On Thu, Jul 9, 2020 at 12:48 PM Paul Walsh  wrote:

> Good question. And I can see why you might ask that question.
>
> The community lead of PhishTank mistakenly said that submissions should
> only be made for URLs that are used to steal' credentials. This helps to
> demonstrate a misconception. While this might have been ok in the past,
> it’s not today.
>
> Phishing is a social engineering technique, used to trick consumers into
> trusting URLs / websites so they can do bad things - including but not
> limited to, man-in-the-middle attacks. Mozilla references this attack
> vector as one of the main reasons for wanting to reduce the life of a cert.
> They didn’t call it “phishing” but that’s precisely what it is.
>
> We can remove all of my references to “phishing” and replace it with
> “security risks” or “social engineering” if it makes this conversation a
> little easier.
>
> And, according to every single security company in the world that focuses
> on this problem, certificates are absolutely used by bad actors - if only
> to make sure they don’t see a “Not Secure” warning.
>
> I’m not talking about EV or identity related info here as it’s not
> related. I’m talking about the risk of a bad actor caring to use a cert
> that was issued to someone else when all they have to do is get a new one
> for free.
>
> I don’t see the risk that some people see. Hoping to be corrected because
> the alternative is that browsers are about to make life harder and more
> expensive for website owners with little to no upside - outside that of a
> researchers lab.
>
> Warmest regards,
> Paul
>
>
> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi  wrote:
>
>
>
> On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> According to Google, spear phishing
>
>
> I didn't see phishing mentioned in Mozilla's post, which is unsurprising,
> since certificates have nothing to do with phishing. Did I overlook
> something saying it was about phishing?
>
> It seems reasonable to read it as it was written, which doesn't mention
> phishing, which isn't surprising, because certificates have never been able
> to address phishing.
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Hi Christian,
I think your concern is about how our code will enforce this. Because our
policy only applies to roots that are built in, our intent is to have our
code apply this restriction only to certificates that chain up to built-in
roots.
Thanks,
Ben

On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
>
> Hi,
>
> blog post should clarify if this is valid for certificates issued by
> preinstalled root CAs only or also for CAs installed by user.
>
>
> regards
> Christian
> ___
> 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: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Yes, that's right.

On Fri, Jul 10, 2020 at 12:11 PM Doug Beattie 
wrote:

> Ben,
>
> For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC.
>
>
> -Original Message-
> From: dev-security-policy 
> On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Friday, July 10, 2020 12:49 PM
> To: mozilla-dev-security-policy
> 
> Subject: Re: New Blog Post on 398-Day Certificate Lifetimes
>
> Some people have asked whether two-year certificates existing on August 31
> would remain valid.  The answer is yes. Those certificates will remain
> valid
> until they expire. The change only applies to certificates issued on or
> after Sept. 1, 2020.
> ___
> 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: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Some people have asked whether two-year certificates existing on August 31
would remain valid.  The answer is yes. Those certificates will remain
valid until they expire. The change only applies to certificates issued on
or after Sept. 1, 2020.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

EV-enablement Request of Identrust

[Ben Wilson via dev-security-policy]

This is a request to EV-enable the IdenTrust Commercial Root CA 1, as
documented here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1551703

*  Summary of Information Gathered and Verified:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417

*  SHA2 hash for Root CA Certificate:
5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE

*  Root Certificate Download URL:

http://validation.identrust.com/roots/commercialrootca1.p7c

*  Identrust’s BR Self Assessment is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel Spreadsheet
Download)

*  CPS:

https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf

*  Test Website:

https://ev-valid.identrustssl.com/

*  EV Policy OIDs:

2.16.840.1.113839.0.6.9,  2.23.140.1.1

* CRL URL:

http://validation.identrust.com/crl/commercialrootca1.crl

*  OCSP URL:

http://commercial.ocsp.identrust.com

*  Audit:

A period of time WebTrust EV annual audit report was provided on August 16,
2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That and
other WebTrust audit reports are available from the bottom of the following
applicant page:  https://www.identrust.com/support/documents/trustid.


I’ve reviewed the CPS, BR Self Assessment, and related information for this
inclusion request.  Comments and concerns regarding the CPS were
satisfactorily addressed as noted in
https://bugzilla.mozilla.org/show_bug.cgi?id=1551703.  I now recommend that
the IdenTrust Commercial Root CA 1 be enabled for Extended Validation
treatment.


This begins the 3-week comment period for this request.


I will greatly appreciate your thoughtful and constructive feedback on
Identrust’s request.

Sincerely yours,

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

Updated Language in CA Incident Report Template

[Ben Wilson via dev-security-policy]

All,

I have updated the wiki page containing the CA incident report template.
See https://wiki.mozilla.org/CA/Responding_To_An_Incident


The purpose of this update is to place more emphasis on the level of detail
that CAs should provide, especially in sections 6 (root cause) and 7
(remediation) of incident reports. Other changes were made to ensure that
all types of incidents (i.e. not just misissuance) can be adequately
explained.

Here is a diff version -
https://wiki.mozilla.org/index.php?title=CA/Responding_To_An_Incident=prev=1228621

Thanks,
Ben Wilson
Mozilla Root Store Program
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include certSIGN Root CA G2 certificate

[Ben Wilson via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1403453
<https://bugzilla.mozilla.org/show_bug.cgi?id=1403453>

- Ben

On Thu, May 28, 2020 at 12:06 PM Ben Wilson  wrote:

> In accordance with the CA inclusion process[1], this is a summary of the
> public discussion of Certsign’s application for inclusion of the certSIGN
> ROOT CA G2 into the Mozilla root store with the websites trust bit and EV
> enabled. The request is documented in Bugzilla #1403453[2]. The public
> discussion began on 6-May-2020[3].
>
> During the public discussion, it was noted that the audit report listed
> six minor non-conformities regarding documentation and process
> implementation[4]. Of primary concern was recordkeeping of the CA key
> shares. Certsign responded that all six non-conformities, including key
> share recordkeeping, had been remediated[5]. Specifically with regard to
> the CA key shares, Certsign has registered its DR backup shares in its
> asset inventory, card custody is recorded, use of secrets by the
> application is logged by a script, and person(s) with access to the
> safeboxes no longer has/have access to the room where the safeboxes are
> stored.[6]
>
> No other comments were received.
>
> Based on a totality of the information presented and reviewed, I am
> planning to recommend that Certsign’s application be approved.
>
>
> I appreciate any feedback on this proposed course of action.
>
> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
>
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/rJke0W6eAwAJ
>
>
> [4] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
>
> [5] https://bugzilla.mozilla.org/attachment.cgi?id=9149366
>
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/Nfbq64TyBwAJ
>
>
> On Wed, May 13, 2020 at 3:18 AM Gabriel Petcu via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Saturday, May 9, 2020 at 12:56:00 AM UTC+3, Wayne Thayer wrote:
>> > The ETSI audit attestation statement referenced by Ben [1] lists 6
>> > non-conformities that were to be corrected within 3 months of the onsite
>> > audit that occurred on 2020-02-10 until 2020-02-14:
>> >
>> > Findings with regard to ETSI EN 319 401:
>> > -REQ-7.8-06–Documentation shall be improved
>> >
>> > Findings with regard to ETSI EN 319 411-1:
>> > -REG-6.3.1-01–Implementation shall be improved
>> > -GEN-6.5.1-04-Implementation shall be improved
>> >
>> > Findings with regard to ETSI EN 319 411-2:
>> > -SDP-6.5.1-02 -Implementation shall be improved
>> > -GEN-6.6.1-05–Documentation shall be improved
>> > -CSS-6.3.10-13–Documentation shall be improved
>> >
>> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for
>> > signing certificates shall be created under, at least, dual control.
>> >
>> > I'd like to see an explanation of these non-conformities and the
>> > remediation from certSIGN, and confirmation from LSTI that they have
>> been
>> > fixed.
>> >
>> > - Wayne
>> >
>> > [1] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
>> >
>> > On Wed, May 6, 2020 at 4:59 PM Ben Wilson via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > > This request is for inclusion of the certSIGN Root CA G2 certificate
>> and to
>> > > turn on the Websites trust bit and for EV treatment.
>> > >
>> > >
>> > > The request is documented in Bugzilla and in the CCADB as follows:
>> > >
>> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
>> > >
>> > >
>> > >
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0403
>> > >
>> > > (Summary of info gathered and verified, URLs for test websites, etc.)
>> > >
>> > >
>> > >
>> > > * certSIGN’s BR Self Assessment is here:
>> > >
>> > > https://bugzilla.mozilla.org/attachment.cgi?id=9052673
>> > >
>> > > The Certsign document repository can be found here:
>> > >
>> > > https://www.certsign.ro/en/certsign-documents/policies-procedures
>> > >
>> > > * Root Certificate Locations:
>> > >
>> > > http://crl.certsign.ro/certsign-rootg2.crt
>> > >

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1445364


- Ben

On Tue, Jun 2, 2020 at 1:57 PM Ben Wilson  wrote:

> I have now reviewed Microsec's updated CPS for OV and DV.  I am not going
> to hold up approval of the inclusion of this root for the following
> reasons, which I believe are relatively minor, but Microsec should be aware
> that:
>
>- section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
>Authentication CPS" (
>https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
>CPS") appears to allow certain identifiers, allowed for EV, but not yet
>added to the Baseline Requirements, see
>
> https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
>This is something that should be taken up with the CA/Browser Forum (and
>corrected in Microsec's CPS); and
>- section 4.9.5 of the CPS, which states, "Emails arriving out of
>office hours are considered as arrived at the beginning of the next
>business day." This may put Microsec at risk of a violation of the Baseline
>Requirements sections 4.9.1 through 4.9.5. While "receipt" (or "arrival")
>is not yet defined in the Baseline Requirements, there is an expectation of
>24x7 availability, which it appears Microsec is providing - "The Trust
>Service Provider maintains a continuous 24x7 ability to respond internally
>to a High Piority Certificate Problem Report."
>
> This concludes my review of the Microsec CPs/CPSes, and I believe it is
> now appropriate to begin the process of adding this root CA into NSS
> (without EV enablement).
>
> On Thu, May 28, 2020 at 1:00 PM Ben Wilson  wrote:
>
>> In accordance with the CA inclusion process,[1] this is a summary of the
>> public discussion of Microsec’s application for inclusion of the e-Szigno
>> Root CA 2017 into the Mozilla root store, and to EV enable it and the
>> currently-included e-Szigno Root CA 2009. The request is documented in
>> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
>> email launching the public discussion and comments received during the
>> public discussion raised a number of issues, not all of which are itemized
>> here, including:
>>
>> * the CPS was unclear about certificate problem reporting and revocation
>> request processing[4]; and
>>
>> * Microsec has had systemic, standards-related non-conformities, e.g.
>> Bug# 1622539[5], and needs to demonstrate better behavior in keeping up
>> with and complying with the CABF Baseline Requirements and root store
>> policy.[6]
>>
>> Microsec is resolving these concerns by:
>>
>> - updating its CPS[7][8]; and
>>
>> - committing to engage in better compliance with industry standards[9].
>>
>> In my opinion Microsec has demonstrated sufficient response that we do
>> not need to remove Microsec from Mozilla’s root store. Therefore, once I am
>> satisfied after a review of the updated CPS, I am planning to recommend
>> that we approve the request to include the e-Szigno Root CA 2017
>> certificate and enable the websites trust bit. However, I plan to deny
>> the request for EV treatment for both root certificates. Microsec may
>> re-apply by filing a new request for EV treatment after they have
>> demonstrated improved compliance with the BRs and EV Guidelines.
>>
>> I appreciate any feedback on this proposed course of action.
>>
>> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>>
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>>
>> [3]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>>
>> [4]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>>
>>
>> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>>
>> [6]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>>
>>
>> [7]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>>
>>
>> [8]
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>>
>>
>> [9]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>>
>>
>>
>> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> Dear Ben,
>>>
>>> I confirm that Microsec will correct all issues in the CP and CPS
>>> documents as promised during the public discussion.
>>>
>>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>>> comment on them.
>>>
>>> If there are no more comments on the content of our CP and CPS documents
>>> in the public discussion, we will review the thread again and gather all
>>> the issues to be resolved.
>>> As usual, Microsec will review current versions of all applicable
>>> requirements for changes.
>>>
>>> I confirm 

CA Configuration and Operation

[Ben Wilson via dev-security-policy]

Often CA configurations and settings are complex and can be difficult to
manage. We would like to remind CA operators that they need to be familiar
with the configuration and operation of all aspects of CA software and
ensure that they have adequate documentation and training.

For example, in April, a CA operator in the Mozilla Root Program received a
post-issuance warning that a certificate with an RSASSA-PSS key had made it
through the EJBCA pre-issuance check.[1][2]  Apparently, “Check for RSA” on
CSR input allowed an RSASSA-PSS key through because it was considered part
of the RSA suite that was whitelisted. Internal documentation for CA setup
did not include correct validator (pre-issuance) configuration setup.

The CA operator started an investigation into why this occurred. Upon
investigation the CA operator discovered that the validator had started
functioning due to a configuration change occurring unbeknownst to an
engineer when he clicked on save after selecting the validator in CA
settings. The CA operator explained that highlighting the specific
validator was an additional required step after adding a certificate
profile in the validator settings. This additional step was not clearly
stated in the CA software manual.

The vendor has explained that this misunderstanding was due to the fact
that validators need to be enabled on a certificate-profile basis, in order
to allow the same CA to host multiple profiles without validators
conflicting with each other. As certificate profiles can be shared amongst
multiple CAs, the validator needs to be selected there as well.

The vendor also recommends that CA operators use the provided human
readable configuration export tool to run and diff after upgrades and
configuration changes to verify that nothing unintended has changed.

In summary, the general purpose of this email is to urge all CA operators
to be familiar with configuration processes of the CA software that they
use, and specifically to alert users of EJBCA to the procedural measures
described above.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1630870

[2] EJBCA software by Primekey has a pre-issuance “validator” system for
keys, amongst which an external validator to run linters. See
https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/validators-overview/post-processing-validators
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

I have now reviewed Microsec's updated CPS for OV and DV.  I am not going
to hold up approval of the inclusion of this root for the following
reasons, which I believe are relatively minor, but Microsec should be aware
that:

   - section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
   Authentication CPS" (
   https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
   CPS") appears to allow certain identifiers, allowed for EV, but not yet
   added to the Baseline Requirements, see
   
https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
   This is something that should be taken up with the CA/Browser Forum (and
   corrected in Microsec's CPS); and
   - section 4.9.5 of the CPS, which states, "Emails arriving out of office
   hours are considered as arrived at the beginning of the next business day."
   This may put Microsec at risk of a violation of the Baseline Requirements
   sections 4.9.1 through 4.9.5. While "receipt" (or "arrival") is not yet
   defined in the Baseline Requirements, there is an expectation of 24x7
   availability, which it appears Microsec is providing - "The Trust Service
   Provider maintains a continuous 24x7 ability to respond internally to a
   High Piority Certificate Problem Report."

This concludes my review of the Microsec CPs/CPSes, and I believe it is now
appropriate to begin the process of adding this root CA into NSS (without
EV enablement).

On Thu, May 28, 2020 at 1:00 PM Ben Wilson  wrote:

> In accordance with the CA inclusion process,[1] this is a summary of the
> public discussion of Microsec’s application for inclusion of the e-Szigno
> Root CA 2017 into the Mozilla root store, and to EV enable it and the
> currently-included e-Szigno Root CA 2009. The request is documented in
> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
> email launching the public discussion and comments received during the
> public discussion raised a number of issues, not all of which are itemized
> here, including:
>
> * the CPS was unclear about certificate problem reporting and revocation
> request processing[4]; and
>
> * Microsec has had systemic, standards-related non-conformities, e.g. Bug#
> 1622539[5], and needs to demonstrate better behavior in keeping up with and
> complying with the CABF Baseline Requirements and root store policy.[6]
>
> Microsec is resolving these concerns by:
>
> - updating its CPS[7][8]; and
>
> - committing to engage in better compliance with industry standards[9].
>
> In my opinion Microsec has demonstrated sufficient response that we do not
> need to remove Microsec from Mozilla’s root store. Therefore, once I am
> satisfied after a review of the updated CPS, I am planning to recommend
> that we approve the request to include the e-Szigno Root CA 2017
> certificate and enable the websites trust bit. However, I plan to deny
> the request for EV treatment for both root certificates. Microsec may
> re-apply by filing a new request for EV treatment after they have
> demonstrated improved compliance with the BRs and EV Guidelines.
>
> I appreciate any feedback on this proposed course of action.
>
> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>
> [4]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>
>
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>
>
> [7]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>
>
> [8]
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>
>
> [9]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>
>
>
> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> Dear Ben,
>>
>> I confirm that Microsec will correct all issues in the CP and CPS
>> documents as promised during the public discussion.
>>
>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>> comment on them.
>>
>> If there are no more comments on the content of our CP and CPS documents
>> in the public discussion, we will review the thread again and gather all
>> the issues to be resolved.
>> As usual, Microsec will review current versions of all applicable
>> requirements for changes.
>>
>> I confirm that the section 1.5.2 will be changed. The High Priority
>> Certificate Problem Report will be reviewed and will be moved here from
>> section 4.9.3.
>>
>> Other issues I can see after a brief overview:
>> - Preliminary report in case of Certificate problem report in section
>> 4.9.5
>> - correct the reference to section 1.3.1 instead of 1.2 in 

Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process for GlobalSign.

See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
(Steps 4 through 9).

GlobalSign has four (4) new roots to include in the root store.  Two roots,
one RSA and another ECC, are to support server authentication (Bugzilla Bug
# 1570724 ) while two
other roots are for email authentication, RSA and ECC (Bugzilla Bug #
1637269 ).

Mozilla is considering approving GlobalSign’s request(s). This email begins
the 3-week comment period, after which, if no concerns are raised, we will
close the discussion and the request may proceed to the approval phase
(Step 10).

*A Summary of Information Gathered and Verified appears here in these two
CCADB cases:*

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596

*Root Certificate Information:*

*GlobalSign Root R46 *

crt.sh -
https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9

Download - https://secure.globalsign.com/cacert/rootr46.crt

*GlobalSign Root E46*

crt.sh -
https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058

Download - https://secure.globalsign.com/cacert/roote46.crt

*GlobalSign Secure Mail Root R45 *

crt.sh -
https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974

Download - https://secure.globalsign.com/cacert/smimerootr45.crt

*GlobalSign Secure Mail Root E45 *

crt.sh -
https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19

Download - https://secure.globalsign.com/cacert/smimeroote45.crt


*CP/CPS:*

https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf

The current GlobalSign CPS is version 9.6, published 29-December-2020.

Repository location: https://www.globalsign.com/en/repository

*BR Self-Assessment* (Excel) is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9082310

*Audits:*  GlobalSign is audited annually in accordance with the WebTrust
criteria by Ernst & Young, Belgium, which found in June 2020 that
“throughout the period April 1, 2019 to March 31, 2020, GlobalSign
management’s assertion, as referred to above, is fairly stated, in all
material respects, in accordance with the WebTrust Principles and Criteria
for Certification Authorities - SSL Baseline with Network Security, Version
2.3.”  The WebTrust audit noted the following 13 Bugzilla incidents, which
had been previously reported as of that audit date:

1 Misissuance of QWAC certificates.

2 Issue with an OCSP responder status.

3 Some SSL certificates with US country code and invalid State/Prov have
been issued.

4 ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report.

5 OCSP responders found to respond signed by the default CA when passed an
invalid issuer in request.

6 Wrong business category on 3 EV SSL certificates.

7 OCSP Responder returned invalid values for some precertificates.

8 Customer running an on-premise (technically-constrained) CA that chains
to a GlobalSign root, issued certificates without AIA extension.

9 Misissued 4 certificates with invalid CN.

10 Certificates with Subject Public Key Info lacking the explicit NULL
parameter.

11 Untimely revocation of TLS certificate after submission of private key
compromise.

12 Unable to revoke 2 noncompliant QWACs within 5 days.

13 Unable to revoke noncompliant ICA within 7 days



*Incident Reports / Mis-Issuances *

The following bugs/incidents remain open and are being worked on.

1667944 

Empty SingleExtension in OCSP responses


1651447 

Failure to revoke noncompliant ICA within 7 days


1591005 

ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report 

1649937 

Incorrect OCSP Delegated Responder Certificate


1668007 

Invalid stateOrProvinceName value


1664328 

SHA-256 hash algorithm used with ECC P-384 key


1575880 

SSL Certificates with US country code and invalid State/Prov

Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ben Wilson via dev-security-policy]

This is the last issue that I have marked for discussion in relation to
version 2.7.1 of the Mozilla Root Store Policy
.
It is identified and discussed in GitHub Issue #218
 for the MRSP.

I will soon update everyone on the status of the other 13 discussion items
already presented, as some of them are in need of revision based on
comments received thus far.

While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes
a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla
still desires that CRL-based revocation information be available because
CRLite uses CRLs to construct its revocation filters.  (Apple also uses
such CRL information in its certificate validation processes and, as I
understand, is making a similar request of CAs with respect to the new
CCADB field, discussed below.)

While all such CRL information is needed, large CRLs are disfavored because
of the time they take to download and process.  Thus, CAs shard, partition,
or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains,
"Each CRL has a particular scope.  The CRL scope is the set of certificates
that could appear on a given CRL. … A complete CRL lists all unexpired
certificates, within its scope, that have been revoked for one of the
revocation reasons covered by the CRL scope.  A *full and complete CRL*
lists all unexpired certificates issued by a CA that have been revoked for
any reason." (Emphasis added.)

There is a new field in the CCADB for CAs to include information needed for
browsers or others to construct a "full and complete CRL", i.e. to gather
information from CAs that don't include the CRL path to their "full and
complete CRL" in end entity certificates they issue. This new CCADB field
is called "Full CRL Issued By This CA" and is located under the heading
"Pertaining to Certificates Issued by this CA." Rather than condition the
requirement that CAs fill in this information in the CCADB only when they
don't include a CDP to a full and complete CRL, I propose that this new
CCADB field be populated in all situations where the CA is enabled for
server certificate issuance. In cases where the CA shards or partitions its
CRL, the CA must provide a JSON-based list of CRLs that when combined are
the equivalent of the full and complete CRL.

Proposed language to add to section 6 of the Mozilla Root Store Policy is
as follows:

*CAs SHOULD place the URL for the associated CRL within the
crlDistributionPoints extension of issued certificates. A CA MAY omit the
crlDistributionPoint extension, if permitted by applicable requirements and
policies, such as the Baseline Requirements. *

*A CA technically capable of issuing server certificates MUST ensure that
the CCADB field "Full CRL Issued By This CA" contains either the URL for
the full and complete CRL or the URL for the JSON file containing all URLs
for CRLs that when combined are the equivalent of the full and complete CRL*
.


I look forward to your comments and suggestions.

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

Summary of Camerfirma's Compliance Issues

[Ben Wilson via dev-security-policy]

 All,

We have prepared an issues list as a summary of Camerfirma's compliance
issues over the past several years. The purpose of the list is to collect
and document all issues and responses in one place so that an overall
picture can be seen by the community. The document is on the Mozilla wiki:
https://wiki.mozilla.org/CA:Camerfirma_Issues.


I will now forward the link above to Camerfirma to provide them with a
proper opportunity to respond to the issues raised and to ask that they
respond directly in m.d.s.p. with any comments, corrections, inputs, or
updates that they may have.

If anyone in this group believes they have an issue appropriate to add to
the list, please send an email to certifica...@mozilla.org.

Sincerely yours,
Ben Wilson
Mozilla Root Program
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

om here:
> > > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1 or
> here: https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2 ?
> (They both lead to the same CPS v. 1.6 document.)
> > > Ben
> > >
> > > On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via
> dev-security-policy  wrote:
> > >>
> > >> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
> > >> dev-secur...@lists.mozilla.org> wrote:
> > >> >
> > >> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias
> van de
> > >> Meent escribió:
> > >> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
> > >> > >  wrote:
> > >> > > >
> > >> > > > [...]
> > >> > > >
> > >> > > > *CP/CPS:*
> > >> > > >
> > >> > > >
> > >>
> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
> > >> > > >
> > >> > > > Current CPS is version 1.5, published 1-October-2020.
> > >> > > >
> > >> > > > Repository location:
> > >> > > >
> > >>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> > >> > > >
> > >> > > I'm having trouble finding the end entity certificate profiles in
> this
> > >> > > CPS. According to the CPS s7.1.2, they are supposed to be
> available at
> > >> > > http://www.cert.fnmt.es/dpcs/, but that redirects me to a
> repository
> > >> > > [0] of which the only english-language document [1] does not
> contain
> > >> > > any end entity certificate profiles, but only the root and ICA
> > >> > > profiles in attachments. Similarly, I cannot find the CPS you
> linked
> > >> > > in their repository.
> > >> > >
> > >> > All the relevant documentation (CPS, PDS, Terms and conditions,
> > >> certificate profiles, and old versions of CPSs) of each CA is
> published in
> > >> its corresponding channel in the website, all of them accessible
> from:
> > >> >
> > >>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> > >>
> > >> I'm sorry, but I'm having trouble finding a link to the latest
> version of
> > >> the CPS of the to-be-included root in that repository. If you add
> this CPS,
> > >> it would be useful to take Mozilla Root Store Policy section 3.3 (6)
> into
> > >> account ("CAs must provide a way to clearly determine which CP and
> CPS
> > >> applies to each of its root and intermediate certificates").
> > >>
> > >> > For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for
> each
> > >> intermediate CA):
> > >> > AC SERVIDORES SEGUROS TIPO 1:
> > >> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
> > >> > and
> > >> > AC SERVIDORES SEGUROS TIPO 2:
> > >> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
> > >> >
> > >> > In regards the certificate profiles, we have included in CPS v1.6
> section
> > >> 7.1.2. direct links to the published documents of profiles.
> > >> >
> > >> > The document describing the profiles of the Website authentication
> > >> certificates, including all extensions, are published at
> > >> > AC SERVIDORES SEGUROS TIPO 1:
> > >> >
> > >>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> > >> > AC SERVIDORES SEGUROS TIPO 2:
> > >> >
> > >>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
> > >> >
> > >>
> > >> Thank you for the links, I probably overlooked them before.
> > >>
> > >> > > I noticed that the CPS defers a great amount of sections (section
> 5,
> > >> > > 6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC,
> which
> > >> > > probably is [1] but that is never explicitly confirmed in the CPS
> -
> > >> > > there is no explicit link to any repository in section 1.6.1
> where the
> > >> > &g

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

See responses inline below:

On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie 
wrote:

> Hi Ben,
>
> For now I won’t comment on the 398 day limit or the date which you propose
> this to take effect (July 1, 2021), but on the ability of CAs to re-use
> domain validations completed prior to 1 July for their full 825 re-use
> period.  I'm assuming that the 398 day limit is only for those domain
> validated on or after 1 July, 2021.  Maybe that is your intent, but the
> wording is not clear (it's never been all that clear)
>

Yes. (I agree that the wording is currently unclear and can be improved,
which I'll work on as discussion progresses.)  That is the intent - for
certificates issued beginning next July--new validations would be valid for
398 days, but existing, reused validations would be sunsetted and could be
used for up to 825 days (let's say, until Oct. 1, 2023, which I'd advise
against, given the benefits of freshness provided by re-performing methods
in BR 3.2.2.4 and BR 3.2.2.5).


>
> Could you consider changing it to read more like this (feel free to edit
> as needed):
>
> CAs may re-use domain validation for subjectAltName verifications of
> dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days  accordance with domain validation re-use in the BRs, section  4.2.1>.  CAs
> MUST limit domain re-use for subjectAltName verifications of dNSNames and
> IPAddresses to 398 days for domains validated on or after July 1, 2021.
>

Thanks. I am open to all suggestions and improvements to the language. I'll
see how this can be phrased appropriately to reduce the chance for
misinterpretation.


>
> From a CA perspective, I don't have any major concerns with shortening the
> domain re-use periods, but customers do/will.  Will there be a Mozilla blog
> that outlines the security improvements with cutting the re-use period in
> half and why July 2021 is the right time?
>

Yes.  I'll prepare a blog post that outlines the security improvements to
be obtained by shortening the reuse period. (E.g., certificates should not
contain stale information.) July 2021 was chosen because I figured April
2021 would be too soon. It also allows CAs to schedule any needed system
work during Q2/2021. In my opinion, Oct. 2023 is a considerably long tail
for this change, and existing domains/customers should not be affected
until then.

Cheers,

Ben


>
> Doug
>
> -----Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Monday, November 30, 2020 2:27 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
>  The purpose of this email is to begin public discussion on a modification
> to subsection 5 in section 2.1 of the Mozilla Root Store Policy.
>
> Issue #206 <https://github.com/mozilla/pkipolicy/issues/206> in GitHub
> discusses the need to bring the reuse period for domain validation in line
> with the certificate issuance validity cycle of 398 days (as set forth in
> section 6.3.2 of the Baseline Requirements). This proposal is not to say
> that Mozilla is not also contemplating a ballot in the CA/Browser Forum
> that would introduce similar language to the Baseline Requirements. Any
> potential CABF endorsers of such a ballot should reach out to me off-list.
>
> Currently, subsection 5 of section 2.1 of the Mozilla Root Store Policy
> (MRSP) states that a CA must “verify that all of the information that is
> included in SSL certificates remains current and correct at time intervals
> of 825 days or less;”
>
> It is proposed that a subsection 5.1 be added to this subsection to
> require that, for subjectAltName verifications of dNSNames or IPAddresses
> performed on or after July 1, 2021, CAs verify the dNSName or IPAddress at
> intervals of 398 days or less.
> Proposed language may be found in the following commit:
>
>
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/b7b53eea3a0af1503f3c99632ba22efc9e86bee2
> Restated here, the proposed language for subsection 5.1 of section 2.1 is:
>
> "for subjectAltName verifications of dNSNames and IPAddresses performed on
> or after July 1, 2021, verify that each dNSName or IPAddress is current and
> correct at intervals of 398 days or less;"
>
> I look forward to your comments, suggestions and discussions.
>
> Thanks,
>
> Ben
> ___
> 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

Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

 The purpose of this email is to begin public discussion on a modification
to subsection 5 in section 2.1 of the Mozilla Root Store Policy.

Issue #206  in GitHub
discusses the need to bring the reuse period for domain validation in line
with the certificate issuance validity cycle of 398 days (as set forth in
section 6.3.2 of the Baseline Requirements). This proposal is not to say
that Mozilla is not also contemplating a ballot in the CA/Browser Forum
that would introduce similar language to the Baseline Requirements. Any
potential CABF endorsers of such a ballot should reach out to me off-list.

Currently, subsection 5 of section 2.1 of the Mozilla Root Store Policy
(MRSP) states that a CA must “verify that all of the information that is
included in SSL certificates remains current and correct at time intervals
of 825 days or less;”

It is proposed that a subsection 5.1 be added to this subsection to require
that, for subjectAltName verifications of dNSNames or IPAddresses performed
on or after July 1, 2021, CAs verify the dNSName or IPAddress at intervals
of 398 days or less.
Proposed language may be found in the following commit:

https://github.com/BenWilson-Mozilla/pkipolicy/commit/b7b53eea3a0af1503f3c99632ba22efc9e86bee2
Restated here, the proposed language for subsection 5.1 of section 2.1 is:

"for subjectAltName verifications of dNSNames and IPAddresses performed on
or after July 1, 2021, verify that each dNSName or IPAddress is current and
correct at intervals of 398 days or less;"

I look forward to your comments, suggestions and discussions.

Thanks,

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

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

Matthias,
Have you been able to obtain the CPS downloadable from here:
https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1  or
here:  https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
?  (They both lead to the same CPS v. 1.6 document.)
Ben

On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via
dev-security-policy  wrote:

> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de
> Meent escribió:
> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
> > >  wrote:
> > > >
> > > > [...]
> > > >
> > > > *CP/CPS:*
> > > >
> > > >
> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
> > > >
> > > > Current CPS is version 1.5, published 1-October-2020.
> > > >
> > > > Repository location:
> > > >
>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> > > >
> > > I'm having trouble finding the end entity certificate profiles in this
> > > CPS. According to the CPS s7.1.2, they are supposed to be available at
> > > http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository
> > > [0] of which the only english-language document [1] does not contain
> > > any end entity certificate profiles, but only the root and ICA
> > > profiles in attachments. Similarly, I cannot find the CPS you linked
> > > in their repository.
> > >
> > All the relevant documentation (CPS, PDS, Terms and conditions,
> certificate profiles, and old versions of CPSs) of each CA is published in
> its corresponding channel in the website, all of them accessible from:
> >
>
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>
> I'm sorry, but I'm having trouble finding a link to the latest version of
> the CPS of the to-be-included root in that repository. If you add this CPS,
> it would be useful to take Mozilla Root Store Policy section 3.3 (6) into
> account ("CAs must provide a way to clearly determine which CP and CPS
> applies to each of its root and intermediate certificates").
>
> > For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for each
> intermediate CA):
> > AC SERVIDORES SEGUROS TIPO 1:
> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
> > and
> > AC SERVIDORES SEGUROS TIPO 2:
> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
> >
> > In regards the certificate profiles, we have included in CPS v1.6 section
> 7.1.2. direct links to the published documents of profiles.
> >
> > The document describing the profiles of the Website authentication
> certificates, including all extensions, are published at
> > AC SERVIDORES SEGUROS TIPO 1:
> >
>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> > AC SERVIDORES SEGUROS TIPO 2:
> >
>
> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
> >
>
> Thank you for the links, I probably overlooked them before.
>
> > > I noticed that the CPS defers a great amount of sections (section 5,
> > > 6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which
> > > probably is [1] but that is never explicitly confirmed in the CPS -
> > > there is no explicit link to any repository in section 1.6.1 where the
> > > acronym is defined, nor are there any other indications that this DGPC
> > > is located in the repository under the link of [0]. This is confusing,
> > > and detrimental to the readability of the document.
> > >
> > CPS new version (v1.6) integrates all the sections that were referred to
> in the DGPC (v5.8) and which applied in general to all our CAs. From
> version 1.6 our CPS collects in a single document all the information and
> BRs compliance commitments for our AC RAIZ FNMT-RCM SERVIDORES SEGUROS
> > [...]
> > I hope that we have been able to resolve all the issues raised with this
> new version of the CPS (1.6) and have gained in transparency.
> > Thanks
> > Santiago.
>
> Thanks for the update, it sounds promising. I'll check it again once I can
> find the CPS in the repository.
>
> Regards,
>
> Matthias
> ___
> 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: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

See my responses inline below.

On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:

>
>
> On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> See responses inline below:
>>
>> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie > >
>> wrote:
>>
>> > Hi Ben,
>> >
>> > For now I won’t comment on the 398 day limit or the date which you
>> propose
>> > this to take effect (July 1, 2021), but on the ability of CAs to re-use
>> > domain validations completed prior to 1 July for their full 825 re-use
>> > period.  I'm assuming that the 398 day limit is only for those domain
>> > validated on or after 1 July, 2021.  Maybe that is your intent, but the
>> > wording is not clear (it's never been all that clear)
>> >
>>
>> Yes. (I agree that the wording is currently unclear and can be improved,
>> which I'll work on as discussion progresses.)  That is the intent - for
>> certificates issued beginning next July--new validations would be valid
>> for
>> 398 days, but existing, reused validations would be sunsetted and could be
>> used for up to 825 days (let's say, until Oct. 1, 2023, which I'd advise
>> against, given the benefits of freshness provided by re-performing methods
>> in BR 3.2.2.4 and BR 3.2.2.5).
>>
>
> Why? I have yet to see a compelling explanation from a CA about why
> "grandfathering" old validations is good, and as you note, it undermines
> virtually every benefit that is had by the reduction until 2023.
>

I am open to the idea of cutting off the tail earlier, at let's say,
October 1, 2022, or earlier (see below).  I can work on language that does
that.


>
> Ben, could you explain the rationale why this is better than the simpler,
> clearer, and immediately beneficial for Mozilla users of requiring new
> validations be conducted on-or-after 1 July 2021? Any CA that had concerns
> would have ample time to ensure there is a fresh domain validation before
> then, if they were concerned.
>

I don't have anything yet in particular with regard to a
pros-cons/benefits-analysis-supported rationale, except that I expect
push-back from SSL/TLS certificate subscribers and from CAs on their
behalf. You're right, CAs could take the time between now and July 1st to
obtain 398-day validations, but my concern is with the potential push-back.

Also, as I mentioned before, I am interested in proposing this as a ballot
in the CA/Browser Forum and seeing where it goes. I realize that this issue
might come with added baggage from the history surrounding the
validity-period changes that were previously defeated in the Forum, but it
would still be good to see it adopted there first. Nonetheless, this issue
is more than ripe enough to be resolved here by Mozilla as well.



>
> Doug, could you explain more about why it's undesirable to do that?
>
>
>> >
>> > Could you consider changing it to read more like this (feel free to edit
>> > as needed):
>> >
>> > CAs may re-use domain validation for subjectAltName verifications of
>> > dNSNames and IPAddresses done prior to July 1, 2021 for up to 825 days
>> > > accordance with domain validation re-use in the BRs, section  4.2.1>.
>> CAs
>> > MUST limit domain re-use for subjectAltName verifications of dNSNames
>> and
>> > IPAddresses to 398 days for domains validated on or after July 1, 2021.
>> >
>>
>> Thanks. I am open to all suggestions and improvements to the language.
>> I'll
>> see how this can be phrased appropriately to reduce the chance for
>> misinterpretation.
>>
>
> As noted above, I think adopting this wording would prevent much (any?)
> benefit from being achieved until 2023. I can understand that 2023 is
> better than "never", but I'm surprised to see an agreement so quickly to
> that being desirable over 2021. I suspect there's ample context here, but I
> think it would benefit from discussion.
>

The language needs to be worked on some more.  As I note above, we should
come up with a cutoff date that is before 2023. It seems that two years is
too long to wait for the last 825-day validation to expire when there are
domain validation methods that work in a matter of seconds.


>
>
>> > From a CA perspective, I don't have any major concerns with shortening
>> the
>> > domain re-use periods, but customers do/will.  Will there be a Mozilla
>> blog
>> > that outlines the security improvements with cutting the re-use period
>> in
>> > half and why July 2021 is the right time?
>
> >
>>
>> Yes.  

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

[Ben Wilson via dev-security-policy]

All,

I have started a similar, simultaneous discussion with the CA/Browser
Forum, in order to gain traction.


https://lists.cabforum.org/pipermail/servercert-wg/2020-December/002382.html

Ben

On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley 
wrote:

> Should this limit on reuse also apply to s/MIME? Right now, the 825 day
> limit in Mozilla policy only applies to TLS certs with email verification
> of s/MIME being allowed for infinity time.  The first draft of the language
> looked like it may change this while the newer language puts back the TLS
> limitation. If it's not addressed in this update, adding clarification on
> domain verification reuse for SMIME would be a good improvement on the
> existing policy.
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ben Wilson via dev-security-policy
> Sent: Wednesday, December 2, 2020 2:22 PM
> To: Ryan Sleevi 
> Cc: Doug Beattie ; Mozilla <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name
> verification to 398 days
>
> See my responses inline below.
>
> On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:
>
> >
> >
> > On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> See responses inline below:
> >>
> >> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie
> >>  >> >
> >> wrote:
> >>
> >> > Hi Ben,
> >> >
> >> > For now I won’t comment on the 398 day limit or the date which you
> >> propose
> >> > this to take effect (July 1, 2021), but on the ability of CAs to
> >> > re-use domain validations completed prior to 1 July for their full
> >> > 825 re-use period.  I'm assuming that the 398 day limit is only for
> >> > those domain validated on or after 1 July, 2021.  Maybe that is
> >> > your intent, but the wording is not clear (it's never been all that
> >> > clear)
> >> >
> >>
> >> Yes. (I agree that the wording is currently unclear and can be
> >> improved, which I'll work on as discussion progresses.)  That is the
> >> intent - for certificates issued beginning next July--new validations
> >> would be valid for
> >> 398 days, but existing, reused validations would be sunsetted and
> >> could be used for up to 825 days (let's say, until Oct. 1, 2023,
> >> which I'd advise against, given the benefits of freshness provided by
> >> re-performing methods in BR 3.2.2.4 and BR 3.2.2.5).
> >>
> >
> > Why? I have yet to see a compelling explanation from a CA about why
> > "grandfathering" old validations is good, and as you note, it
> > undermines virtually every benefit that is had by the reduction until
> 2023.
> >
>
> I am open to the idea of cutting off the tail earlier, at let's say,
> October 1, 2022, or earlier (see below).  I can work on language that does
> that.
>
>
> >
> > Ben, could you explain the rationale why this is better than the
> > simpler, clearer, and immediately beneficial for Mozilla users of
> > requiring new validations be conducted on-or-after 1 July 2021? Any CA
> > that had concerns would have ample time to ensure there is a fresh
> > domain validation before then, if they were concerned.
> >
>
> I don't have anything yet in particular with regard to a
> pros-cons/benefits-analysis-supported rationale, except that I expect
> push-back from SSL/TLS certificate subscribers and from CAs on their
> behalf. You're right, CAs could take the time between now and July 1st to
> obtain 398-day validations, but my concern is with the potential push-back.
>
> Also, as I mentioned before, I am interested in proposing this as a ballot
> in the CA/Browser Forum and seeing where it goes. I realize that this issue
> might come with added baggage from the history surrounding the
> validity-period changes that were previously defeated in the Forum, but it
> would still be good to see it adopted there first. Nonetheless, this issue
> is more than ripe enough to be resolved here by Mozilla as well.
>
>
>
> >
> > Doug, could you explain more about why it's undesirable to do that?
> >
> >
> >> >
> >> > Could you consider changing it to read more like this (feel free to
> >> > edit as needed):
> >> >
> >> > CAs may re-use domain validation for subjectAltName verifications
> >> > of dNSNames and IPAddresses done prior to July 1, 2021 for up to
> >> > 825 days

Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

nsported from one Cryptographic
> Module to another, the Private Key must be encrypted during transport.
> Private Keys must never exist in plain text form outside the Cryptographic
> Module boundary."
>
> CPS / DGPC s6.2.7 fails to commit FNMT to using devices meeting FIPS 140
> level 3 or higher (as that is apparently located in DGPC 6.2.1 and 6.2.8
> (?))
>
> Section 6.2.7 now states, "Root CA private keys of the FNMT-RCM are
> generated and stored inside cryptographic modules which meet the
> requirements of 6.2.1 of this CPS"
>
> CPS / DGPC does not mention "factor" or "2fa" according to my search, even
> though BR 6.5.2 specifies 'The CA SHALL enforce multi-factor authentication
> for all accounts capable of directly causing certificate issuance.".
>
> Section 6.5.1 now states, "The FNMT-RCM shall enforce multi-factor
> authentication for all accounts capable of directly causing certificate
> issuance."
>
> ... skipped over similar issues in 7: failure to document a commitment to
> the relevant sections of the BR ... skipped over similar issues in 8:
> failure to document a commitment to the relevant sections of the BR
>
> FNMT indicated "Sections 7 and 8 have been reviewed and more detailed
> information has been included in CPS v.1.6 sections 7.1.2, 8, 8.1, and 8.5.
> "
>
>
>
> On Fri, Dec 4, 2020 at 12:40 PM Santiago Brox via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> El viernes, 4 de diciembre de 2020 a las 18:20:41 UTC+1, Matthias van de
>> Meent escribió:
>> > Thanks for the pointer, Ben.
>> >
>> > I didn't realise that the links in section 'Particulares AC Raíz
>> > FNMT-RCM Servidores Seguros' of their main repository [1] were links
>> > to repositories that would include the applicable CPS... As those
>> > sections seemed to be for ICAs of the root, I didn't consider them as
>> > a source for the CPS of their parent CA. Together with that the CPS
>> > pointers in the certificate profile point to the main repository and
>> > that the QcPDS links in the certificate profiles don't seem to point
>> > to anything, I got lost...
>> >
>> > So, sorry for the noise, I was very confused by the structure of the
>> repository.
>> >
>> > Now that I know where to look, I'll probably check the contents more
>> > thoroughly sometime in the following weekend, at first glance they
>> > already looked much better.
>> >
>> > -Matthias
>> >
>> > [1]
>> https://www.sede.fnmt.gob.es/en/normativa/declaracion-de-practicas-de-certificacion
>> > On Wed, 2 Dec 2020, 23:44 Ben Wilson,  wrote:
>> > >
>> > > Matthias,
>> > > Have you been able to obtain the CPS downloadable from here:
>> > > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1 or
>> here: https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
>> ? (They both lead to the same CPS v. 1.6 document.)
>> > > Ben
>> > >
>> > > On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via
>> dev-security-policy  wrote:
>> > >>
>> > >> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy
>> <
>> > >> dev-secur...@lists.mozilla.org> wrote:
>> > >> >
>> > >> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias
>> van de
>> > >> Meent escribió:
>> > >> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
>> > >> > >  wrote:
>> > >> > > >
>> > >> > > > [...]
>> > >> > > >
>> > >> > > > *CP/CPS:*
>> > >> > > >
>> > >> > > >
>> > >>
>> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
>> > >> > > >
>> > >> > > > Current CPS is version 1.5, published 1-October-2020.
>> > >> > > >
>> > >> > > > Repository location:
>> > >> > > >
>> > >>
>> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>> > >> > > >
>> > >> > > I'm having trouble finding the end entity certificate profiles
>> in this
>> > >> > > CPS. According to the CPS s7.1.2, they are supposed to be
>> available at
>> > >> > > http://www.cert.fnmt.es

Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

[Ben Wilson via dev-security-policy]

All,

This email is part of the discussion for the next version of the Mozilla
Root Store Policy (MSRP), version 2.7.1, to be published during of Q1-2021.

For audit delays, we currently require that audit statements disclose the
locations that were and were not audited, but that requirement has not been
incorporated yet into the MRSP. See
https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations. That
provision reads as follows:

Disclose each location (at the state/province level) that was included in
the scope of the audit or should have been included in the scope of the
audit, whether the inspection was physically carried out in person at each
location, and which audit criteria were checked (or not checked) at each
location.

   - If the CA has more than one location in the same state/province, then
   use terminology to clarify the number of facilities in that state/province
   and whether or not all of them were audited. For example: "Facility 1 in
   Province", "Facility 2 in Province, Facility 3 in Province" *or*
   "Primary Facility in Province", "Secondary Facility in Province", "Tertiary
   Facility in Province".
  - The public audit statement does not need to identify the type of
  Facility.
  - "Facility" includes: data center locations, registration authority
  locations, where IT and business process controls of CA operations are
  performed, facility hosting an active HSM with CA private keys,
facility or
  bank deposit box storing a deactivated and encrypted copy of a
private key.

It is proposed by Issue #207
 that this language
requiring the disclosure of site locations--audited and unaudited--be made
clearly part of the MSRP by reference to the language above.

A similar method of incorporating by reference has been taken in section
2.4 of the MSRP

with respect to incident reporting and in section 7.1

with requirements for the CA inclusion process.

It is proposed that we add a new subsection 10 to MRSP section 3.1.4

that would require that audit documentation disclose the facility site
locations that were, or were not, examined.

One concern that has been raised previously is that the Baseline
Requirements do not define "facility site location". However, we believe
that the language above at
https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations
accomplishes that. We're open to suggestions for re-wording parts of it to
make it even better.

Currently, the audit letter template for WebTrust for CAs references the
site location audited (at the level of specificity that is proposed
above).  Over this past year, due to COVID, some ETSI attestation letters
have also explained which sites were and were not checked. This approach
seems to work, and the additional information will be beneficial in the
future as we evaluate the security and trust of PKI service providers.

So, for the page cited above, we intend to move "Minimum Expectations" out
from under "Audit Delay" so that it stands separately as a requirement for
disclosing the facility site location. Then we will also revise MRSP
section 3.1.4 by inserting a new subsection 10 to require "facility site
locations that were, or were not, examined" with a hyperlink to the Minimum
Expectations language cited above.

We look forward to your comments and suggestions.

Sincerely yours,

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

Policy 2.7.1: MRSP Issue #211: Align OCSP requirements in Mozilla's policy with the BRs

[Ben Wilson via dev-security-policy]

This discussion is related to Issue #211 on GitHub
.

Effective September 30, 2020, as a result of the Browser Alignment Ballot
, section
4.9.10 of the CA/Browser Forum’s BaselineRequirements
 (BR§4.9.10) says
that a CA’s OCSP responses must meet certain requirements. The purpose of
this email is to determine whether changes should be made to section 6 of
the Mozilla Root Store Policy

(MRSP§6) to bring it closer to the Forum’s requirements for OCSP responses.
There are a few possible paths forward, including:

*Option 1* - Leave “as is” because MRSP§6 doesn’t conflict with the
Baseline Requirements.  MRSP§6 currently says,

“For end-entity certificates, if the CA provides revocation information via
an Online Certificate Status Protocol (OCSP) service:

· it MUST update that service at least every four days; and

· responses MUST have a defined value in the nextUpdate field, and it MUST
be no more than ten days after the thisUpdate field; and

· the value in the nextUpdate field MUST be before or equal to the notAfter
date of all certificates included within the BasicOCSPResponse.certs field
or, if the certs field is omitted, before or equal to the notAfter date of
the CA certificate which issued the certificate that the BasicOCSPResponse
is for.”

*Option 2* - MRSP§6 could simply incorporate by reference all of BR§4.9.10,
but then quite a few new OCSP requirements would also be adopted, some of
which people might find useful.



*Option 3* - Paste only language from BR§4.9.10’s subsections (1) through
(4) (for Subscriber/End-Entity Certificates) into MRSP§6.  Those four
subsections state:  “(1) OCSP responses MUST have a validity interval
greater than or equal to eight hours; (2) OCSP responses MUST have a
validity interval less than or equal to ten days; (3) For OCSP responses
with validity intervals less than sixteen hours, then the CA SHALL update
the information provided via an Online Certificate Status Protocol prior to
one-half of the validity period before the nextUpdate; and (4) For OCSP
responses with validity intervals greater than or equal to sixteen hours,
then the CA SHALL update the information provided via an Online Certificate
Status Protocol at least eight hours prior to the nextUpdate, and no later
than four days after the thisUpdate.”  The drawback of this approach would
come when trying to synchronize the language—it would not be in lockstep
with relevant changes to the BRs.



*Option 4* - Amend MRSP§6 to just incorporate by reference the above
subsections, i.e., “subsections (1) through (4) of BR§4.9.10, which deal
with the OCSP status responses for Subscriber Certificates, are hereby
incorporated by reference”.  This approach has a similar drawback if
additional subsections are added, and it doesn’t include other language in
BR§4.9.10 that some might find useful.

*Option 5* - Other

Finally, under the options above, can anyone think why different language
might be needed for OCSP responses for non-SSL/TLS (e.g. SMIME)
implementations?

Thanks in advance for your suggestions / recommendations.

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

Policy 2.7.1: Process Overview

[Ben Wilson via dev-security-policy]

 Re-posting this email to start it with its own subject line and to start a
new thread:

There have been questions about the process being followed and the comment
period.  Here is where it now stands.

I intend to introduce the remaining discussion topics over the next three
weeks. I did not announce an end to the discussion period on purpose, so
that we can have as full of a discussion as possible. Also, in the next
three weeks, I intend to start summarizing the discussions and coming up
with new suggested language on those issues that have been discussed. I
expect that during December we will start to solidify the amendments to
MRSP (v.2.7.1), and that in January I'll announce a "last call" on the
amendments. Following that I will "summarize a consensus that has been
reached, and/or state the official position of Mozilla" - see
https://wiki.mozilla.org/CA/Updating_Root_Store_Policy.

Part of the discussion that will still need to take place deals with
implementation deadlines, timing, etc. Let's discuss that now for the
non-controversial items, and then in late December / early January for
those that are more contentious (assuming they remain in this batch of
changes).

Sincerely yours,
Ben Wilson
Mozilla Root Store
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: NAVER: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

tion processes, but this language in the NAVER
CPS meets the minimum requirements. Hopefully, NAVER and other CAs will not
only strive to improve their CPS revocation language, but also strive to
revoke certificates quickly when one of the criteria is met.

Are there any final comments or issues that have not been addressed?  If
not, I will be closing public discussion tomorrow [Step 9] and giving
notice that it is Mozilla’s intent to approve NAVER's request for inclusion
[Step 10].

Thanks,

Ben


On Thu, Nov 5, 2020 at 8:55 AM Sooyoung Eo via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thank you all for the comments during the public discussion phase.
> All matters raised in this public discussion has been fixed and then
> published
> our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14,
> and 9.16.3.
>
> You can find the revised CPS v1.5.0 at our repository.
> https://certificate.naver.com/bbs/initCrtfcJob.do
> (directly download link:
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY_file_nm=8458f988c4994fc2b5fbae53a0c704c7.pdf_real_file_nm=NAVER%20Cloud%20CPS%20v1.5.0.pdf
> )
>
> To minimize confusion,  I would like to metion that "NAVER BUSINESS
> PLATFORM"
> has been renamed to "NAVER Cloud" without any changes on the ownership of
> the company and Certification Authority on October 26, 2020.
>
> Kind Regards,
> Sooyoung Eo
>
>
> 2020년 11월 4일 수요일 오전 7시 50분 27초 UTC+9에 Ben Wilson님이 작성한 내용:
> > The 3-week public discussion was to close on Monday, but I'd like Naver
> to
> > provide any further final comments and give anyone else an opportunity
> to
> > comment through this Thursday, and then I will proceed with Steps 6-10
> > (summarize matters, note any remaining items, and make a last call for
> > objections).
> > On Fri, Oct 23, 2020 at 10:04 AM Sooyoung Eo via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > 2020년 10월 10일 토요일 오전 7시 31분 12초 UTC+9에 George님이 작성한 내용:
> > > > Minor but it seems like all certificates with a stateOrProvinceName
> > > field are misissued. The ST field should probably be the "Gyeonggi-do"
> as
> > > the "Seongnam-si" entered is a city.
> > > >
> > > >
> > > >
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy
> <
> > > dev-secur...@lists.mozilla.org> wrote:
> > > >
> > > > > Dear All,
> > > > >
> > > > > This is to announce the beginning of the public discussion phase
> of
> > > the
> > > > > Mozilla root CA inclusion process,
> > > > > https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> > > (Steps 4
> > > > > through 9). Mozilla is considering approval of NAVER Business
> Platform
> > > > > Corp.’s request to include the NAVER Global Root Certification
> > > Authority as
> > > > > a trust anchor with the websites trust bit enabled, as documented
> in
> > > the
> > > > > following Bugzilla case:
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby
> > > initiate a
> > > > > 3-week comment period, after which if no concerns are raised, we
> will
> > > close
> > > > > the discussion and the request may proceed to the approval phase
> (Step
> > > 10).
> > > > >
> > > > > A Summary of Information Gathered and Verified appears here in the
> > > CCADB:
> > > > >
> > > > >
> > >
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261
> > > > >
> > > > > *NAVER Global Root Certification Authority, *valid from 8/18/2017
> to
> > > > > 8/18/2037
> > > > >
> > > > > SHA2:
> 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265
> > > > >
> > > > > https://crt.sh/?id=1321953839
> > > > >
> > > > > Root Certificate Download:
> > > > >
> > > > >
> > >
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST_file_nm=1c3763b33dbf457d8672371567fd1a12.crt_real_file_nm=naverrca1.crt
> > > > >
> > > > > CP/CPS:
> > > > >
> > > > > Comments 29 (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
> > >
> > > > > through 42 in Bugzilla contain d