RE: Policy 2.6 Proposal: Update Minimum Audit Versions

[Peter Miškovič via dev-security-policy]

Hi Dimitris,

the official list of ETSI published standards you can find at 
http://www.etsi.org/standards-search#Pre-defined%20Collections

If you search for ETSI EN 319 411 you can find that only officially  ETSI 
published versions for ETSI EN 319 411-1 were V1.1.1 (2016-02) and V1.2.2 
(2018-04). Any other version, according document history on the last page of 
standard, were version for  EN approval Procedure (V1.2.0) or Vote (V1.2.1).  
It means that versions 1.2.0 and 1.2.1 were not officially published by ETSI. 

For ETSI EN 319 411-2 you can find that only official ETSI published version 
were versions V2.1.1 (2016-02) and V2.2.2 (2018-04). 

According this the minimal requirements should looks like:

“Trust Service Providers practice” in ETSI EN 319 411-1 version 1.1.1 or 
version 1.2.2 or later ETSI officially published version.
“Trust Service Providers practice” in ETSI EN 319 411-2  version 2.1.1  or 
version 2.2.2 or later ETSI officially published version

Regards
Peter




-Original Message-
From: Dimitris Zacharopoulos <ji...@it.auth.gr> 
Sent: Friday, May 11, 2018 7:23 AM
To: Peter Miškovič <peter.misko...@disig.sk>; Wayne Thayer 
<wtha...@mozilla.com>; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Policy 2.6 Proposal: Update Minimum Audit Versions

Hello Peter,

These were very recently published however not everyone is tracking down ETSI 
updates by registering to the mailing lists. The main question is where can you 
find the authoritative document *list*? I though the official list is 
https://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx.

Also, were there any other versions published before 1.2.2? The recommendation 
says "1.2 or later". Where are the versions 1.2.0, 1.2.1 published?

Thanks,
Dimitris.

On 11/5/2018 8:13 πμ, Peter Miškovič via dev-security-policy wrote:
> There were published a new versions of both ETSI standards:
>
> ETSI EN 319 411-1 V1.2.2 adopted on April 23, 2018 
> http://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.02.02_60
> /en_31941101v010202p.pdf
>
> ETSI EN 319 411-2 V2.2.2 adopted on April 23, 2018 
> http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.02.02_60
> /en_31941102v020202p.pdf
>
> Peter
>
> -Original Message-
> From: dev-security-policy 
> <dev-security-policy-bounces+peter.miskovic=disig...@lists.mozilla.org
> > On Behalf Of Wayne Thayer via dev-security-policy
> Sent: Thursday, May 10, 2018 5:04 PM
> To: mozilla-dev-security-policy 
> <mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Policy 2.6 Proposal: Update Minimum Audit Versions
>
> After consulting with representatives from WebTrust and ETSI, I 
> propose that we update the minimum required versions of audit criteria 
> in section
> 3.1.1 as follows:
>
> - WebTrust "Principles and Criteria for Certification Authorities - 
> Extended Validation SSL" from 1.4.5 to 1.6.0 or later
> - “Trust Service Providers practice” in ETSI EN 319 411-1 from 1.1.1 
> to 1.2 or later
> - “Trust Service Providers practice” in ETSI EN 319 411-2  from 2.1.1 
> to
> 2.2 or later
>
> These newer versions were all published last year and should be the minimum 
> for audits completed from now on.
>
> Please respond with any concerns you have about this update to our root store 
> policy.
>
> - Wayne
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

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

RE: Policy 2.6 Proposal: Update Minimum Audit Versions

[Peter Miškovič via dev-security-policy]

There were published a new versions of both ETSI standards:

ETSI EN 319 411-1 V1.2.2 adopted on April 23, 2018
http://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.02.02_60/en_31941101v010202p.pdf

ETSI EN 319 411-2 V2.2.2 adopted on April 23, 2018
http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.02.02_60/en_31941102v020202p.pdf

Peter

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Thursday, May 10, 2018 5:04 PM
To: mozilla-dev-security-policy 
Subject: Policy 2.6 Proposal: Update Minimum Audit Versions

After consulting with representatives from WebTrust and ETSI, I propose that we 
update the minimum required versions of audit criteria in section
3.1.1 as follows:

- WebTrust "Principles and Criteria for Certification Authorities - Extended 
Validation SSL" from 1.4.5 to 1.6.0 or later
- “Trust Service Providers practice” in ETSI EN 319 411-1 from 1.1.1 to 1.2 or 
later
- “Trust Service Providers practice” in ETSI EN 319 411-2  from 2.1.1 to
2.2 or later

These newer versions were all published last year and should be the minimum for 
audits completed from now on.

Please respond with any concerns you have about this update to our root store 
policy.

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

[Peter Miškovič via dev-security-policy]

Hi Paul,
Problem with OCSP response for RootCA (CA Disig Root R1 and CA Disig Root R2) 
was fixed on Thursday August 31, 2017.
Regards
Peter Miskovic


From: Paul Kehrer [mailto:paul.l.keh...@gmail.com]
Sent: Tuesday, August 29, 2017 2:48 PM
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:


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


-Paul

___
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

[Peter Miškovič via dev-security-policy]

Hi Paul,
we found the problem with OCSP response for SubCA R1I1 and SubCA R2I2 and fixed 
it yesterday afternoon.
Problem with OCSP response for RootCA will be fixed to the end of next week. 
They are offline and there is no real possibility to issue a SSL certificate 
directly by them even if  they are enabled for issuing.

Regards
Peter Miskovic


From: Paul Kehrer [mailto:paul.l.keh...@gmail.com]
Sent: Tuesday, August 29, 2017 2:48 PM
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:


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


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

[Peter Miškovič via dev-security-policy]

___
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

[Peter Miškovič via dev-security-policy]

Hi Paul,
thank you for the information. We had yesterday a holiday here in Slovakia. We 
are starting the investigation of this problem now.
Regards.
Peter Miskovic

From: Paul Kehrer [mailto:paul.l.keh...@gmail.com]
Sent: Tuesday, August 29, 2017 2:48 PM
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