Re: Violations of Baseline Requirements 4.9.10

[Kurt Roeckx via dev-security-policy]

On 2017-08-30 08:46, Adriano Santoni wrote:
 >>  - 2 are technically constrained sub-CAs ( 
https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 )


Those two are actually the same certificate; it's not clear to me why 
they appear twice on crt.sh


I didn't look if all the name constrains match, but they're at least in 
a different order.



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

[Adriano Santoni via dev-security-policy]

>>  - 2 are technically constrained sub-CAs ( 
https://crt.sh/?id=147626411 / https://crt.sh/?id=47081615 )


Those two are actually the same certificate; it's not clear to me why 
they appear twice on crt.sh



Il 29/08/2017 18:50, Ryan Sleevi via dev-security-policy ha scritto:

On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

Symantec / GeoTrust

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

DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External
Example cert:
https://crt.sh/?q=049462100743d2bcb10780e7c4eb2c
e1197a3f8bea7fad5ef9141f008eb1e6ca
OCSP URI: http://ocsp.unicredit.eu/ocsp


Note: There are 7 associated certificates for this CA (
https://crt.sh/?caid=294 )

Of those:
5 are issued by Symantec / GeoTrust:
   - 1 is expired ( https://crt.sh/?id=9219 )
   - 4 are revoked ( https://crt.sh/?id=12722071 / https://crt.sh/?id=6941850
/ https://crt.sh/?id=47086214 / https://crt.sh/?id=12165934)
2 are issued by Actalis
   - 2 are technically constrained sub-CAs ( https://crt.sh/?id=147626411 /
https://crt.sh/?id=47081615 )

As they are technically-constrained subordinate CAs, they are (presently)
exempted from that MUST requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy




smime.p7s
Description: Firma crittografica S/MIME
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remove old WoSign root certs from NSS

[Kathleen Wilson via dev-security-policy]

Posted:

https://blog.mozilla.org/security/2017/08/30/removing-disabled-wosign-startcom-certificates-firefox-58/

I will look into getting this translated and published in China.

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

Re: Remove old WoSign root certs from NSS

[Percy via dev-security-policy]

links to all of WoSign's announcement in case anyone want to verify.
https://www.wosign.com/news/index.htm  year 2017
https://www.wosign.com/news/index2016.htm year 2016
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remove old WoSign root certs from NSS

[Percy via dev-security-policy]

In fact, can you tell us, when was the first time WoSign started to notify 
users about replacing certs?  

I've dig through all of WoSign's announcement and the first and in fact the 
ONLY announcement regarding replacing certs is dated July 10th, 2017 , titled 
Announcement regarding Google's decision on July 7th".  During Sept 19, 2016 to 
July 10th 2017, WoSign posted a total of 19 announcements, including 
announcements like mountain hiking competition in Youth Day, trips to Yangtze 
River Delta, Wosign's professional services won customers' acknowledgment.   

Of course your customers might be unable to replace certs in time if you only 
notified them July this year while browser announcement such decisions in Oct 
last year!
___
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

FW: Violations of Baseline Requirements 4.9.10

[Cristian Garabet via dev-security-policy]

Hi Paul,

Thank you for feedback. We acknowledge the reported issues.
Regarding the OCSP for certSIGN  Enterprise CA Class 3 G2  subCA, the problem 
was due to a misconfiguration and has been fixed today.
Regarding the OCSP for certSIGN ROOT CA  the problem is due to a software 
limitation and will be fixed until 15.09.2017.

Kind regards,
Cristian Garabet


From: Paul Kehrer
Sent: Tuesday, August 29, 2017 3:47:41 PM (UTC+02:00) Athens, Bucharest
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:

….

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

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

[Alex Gaynor via dev-security-policy]

Hi Ben,

I'm not sure it should matter that a CA _does_ only issue client certs --
in the DigiNotar-style situation for which this rule was envisioned, the
relevant thing is whether the cert is _capable_ of issuing server certs.

Alex

On Tue, Aug 29, 2017 at 12:43 PM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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=74d992d3910bcf7e34b8b5cd28f91e
> aeb4f41f3da6394d78b8c43672d43f4f0f
>
> 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=cd74198d4c23e4701dea579892321b
> 9e4f47a08bd8374710b899aad1495a4b35
>
> OCSP URI: http://ocsp.firmaprofesional.com
>
>
>
> DN: C=ES, emailAddress=c...@firmaprofesional.com  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=649d5190f9fff58de60313c2f05983
> 93f9dba05368b1dbfe93ec806015fb8796
>
> 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=d4ef928ee32c3838d40e5756b52382
> 9b1dafcd46fd84428ba03d59330a4ae5e7
>
> 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=da74b18f3651bf90a8b2c07f8df294
> de19e441dcaa6913627261752199c302a2
>
> 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=1a088e912ddb15a3b52ab1396af2a1
> ce0dcfab170e007e551f63231c76975417
>
> 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=e1abb0faeaa7312f2c3e041cbd2df0
> 3a507e346b9716442463ed61106aff6947
>
> 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=239ffa86d71033ba255914782057d8
> 7e8421aedd5910b786928b6a1248c3e341
>
> 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=98ab1983ae9f6a6116e5010e3ab2b1
> b0bf266fa205a140b1bc1d340ff4ff6355
>
> OCSP URI: http://ocsp.certsign.ro
>
>
>
> DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA
>
> Example cert: https://crt.sh/?q=3003bf8853427c7b91023f7539853d
> 

Re: Violations of Baseline Requirements 4.9.10

[David Fernandez via dev-security-policy]

Hi Paul,
can you provide what you posted, for example attaching the ocsp response. I 
mean if I query for a non-existant certificate, I get the following answer:

openssl ocsp -no_cert_verify -no_signature_verify  -issuer SSLEV_IZENPE.cer 
-serial 0x295990755083049101712519384020072382191 -url http://ocsp.izenpe.com

Response verify OK
0x295990755083049101712519384020072382191: revoked
This Update: Aug 30 08:36:05 2017 GMT
Next Update: Sep  1 08:36:05 2017 GMT
Reason: certificateHold
Revocation Time: Jan  1 00:00:00 1970 GMT
___
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

[Paul Kehrer via dev-security-policy]

Hi David,

If you use the cert at https://crt.sh/?id=1616324 as issuer (the root
itself) and run this command:

openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101
-url http://ocsp.izenpe.com -noverify

You will get back

This Update: Jun 22 11:06:43 2017 GMT
Next Update: Jun 22 11:06:43 2018 GMT

Of course, no serverAuth certificates should be issued directly off the
root, but the root is still enabled for that purpose so the responder
should respond UNAUTHORIZED here (UNAUTHORIZED instead of UNKNOWN to allow
the root to stay offline).

On August 30, 2017 at 4:42:10 PM, David Fernandez via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

Hi Paul,
can you provide what you posted, for example attaching the ocsp response. I
mean if I query for a non-existant certificate, I get the following answer:

openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer
-serial 0x295990755083049101712519384020072382191 -url
http://ocsp.izenpe.com

Response verify OK
0x295990755083049101712519384020072382191: revoked
This Update: Aug 30 08:36:05 2017 GMT
Next Update: Sep 1 08:36:05 2017 GMT
Reason: certificateHold
Revocation Time: Jan 1 00:00:00 1970 GMT
___
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,
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 

Re: Violations of Baseline Requirements 4.9.10

[David Fernandez via dev-security-policy]

Hi Paul,
thank you for the clarification, I thought you were talking about subordinates.
Regards,
 
El miércoles, 30 de agosto de 2017, 10:58:34 (UTC+2), Paul Kehrer  escribió:
> Hi David,
> 
> If you use the cert at https://crt.sh/?id=1616324 as issuer (the root
> itself) and run this command:
> 
> openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101
> -url http://ocsp.izenpe.com -noverify
> 
> You will get back
> 
> This Update: Jun 22 11:06:43 2017 GMT
> Next Update: Jun 22 11:06:43 2018 GMT
> 
> Of course, no serverAuth certificates should be issued directly off the
> root, but the root is still enabled for that purpose so the responder
> should respond UNAUTHORIZED here (UNAUTHORIZED instead of UNKNOWN to allow
> the root to stay offline).
> 
> On August 30, 2017 at 4:42:10 PM, David Fernandez via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
> 
> Hi Paul,
> can you provide what you posted, for example attaching the ocsp response. I
> mean if I query for a non-existant certificate, I get the following answer:
> 
> openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer
> -serial 0x295990755083049101712519384020072382191 -url
> http://ocsp.izenpe.com
> 
> Response verify OK
> 0x295990755083049101712519384020072382191: revoked
> This Update: Aug 30 08:36:05 2017 GMT
> Next Update: Sep 1 08:36:05 2017 GMT
> Reason: certificateHold
> Revocation Time: Jan 1 00:00:00 1970 GMT
> ___

___
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

[Paul Kehrer via dev-security-policy]

On August 30, 2017 at 4:53:54 AM, Ben Wilson via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

This CA is technically constrained:



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





Hi Ben,

ABB Intermediate CA 3 (https://crt.sh/?id=7739892), which issued ABB
Issuing CA 6, does have a name constraints extension. Unfortunately that NC
extension does not comply with BR 7.1.5 because it fails to encode an IPv6
exclusion:

The Subordinate CA Certificate MUST also include within excludedSubtrees an
iPAddress GeneralName of 32 zero octets (covering the IPv6 address range of
::0/0)

This is an interesting edge case since the CA is partially, but not fully
constrained.

-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

[identrust--- via dev-security-policy]

On Tuesday, August 29, 2017 at 9:41:07 AM UTC-4, Paul Kehrer wrote:
> 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, 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=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208
> OCSP URI: http://ocsp.catcert.net
> 
> DN: 

Re: Remove old WoSign root certs from NSS

[Percy via dev-security-policy]

It's true that the first post has a link to that second post. However, the 
related sentence is 

To learn more, please visit "Announcement regarding Google's decision on July 
7th", with a hyperlink to the second post. 

And only the second post mentions anything about replacing certs. I hardly 
think users would understand they are risking being blocked by major browsers 
from such a benign looking sentence. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remove old WoSign root certs from NSS

[Percy via dev-security-policy]

On Wednesday, August 30, 2017 at 11:15:04 AM UTC-7, Kathleen Wilson wrote:
> Posted:
> 
> https://blog.mozilla.org/security/2017/08/30/removing-disabled-wosign-startcom-certificates-firefox-58/
> 
> I will look into getting this translated and published in China.
> 
> Thanks,
> Kathleen

Thank you so much for taking Chinese users into consideration! 
___
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