Re: New SHA-1 certificates issued in 2016

2016-11-05 Thread Kurt Roeckx 
On Sat, Nov 05, 2016 at 09:09:49AM +, Gervase Markham wrote:
> > If they had sent an incident report to Mozilla I would agree, but I do
> > not think that CAs should be credited for noticing mistakes when they
> > try to sweep them under the rug.  This is particularly true in the case
> > of SHA-1 misissuance, where revoking without broader notification
> > demonstrates not competence but rather a lack of understanding of the
> > risks.
> 
> Your point being that if they do disclose, the community can then run
> crypto analysis over the cert to see if it's likely to be constructed as
> part of a collision attempt?

I think in general we want to hear from CAs about any incident,
including BR violations. For all the bugs we filed in bugzilla
about SHA-1, 1024 bit RSA keys, and so on there should be an
incident report, and it should _at least_ be mentioned in their
audit. But they really should send such incident reports to all
root programs at the moment they knew about it.


Kurt

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

Re: New SHA-1 certificates issued in 2016

2016-11-05 Thread Gervase Markham 
On 04/11/16 23:51, Andrew Ayer wrote:
> The March 2016 CA communication said[1]:
> 
> "It has been pointed out in the mozilla.dev.security.policy forum that
> a chosen-prefix attack on SHA-1 could be used to forge a certificate if
> a CA's private key is used to sign *anything* with SHA-1."
> 
> Therefore, CAs participating in the Mozilla program know that this
> practice is dangerous.

This is true; however, unfortunately, I don't believe this amounts to a
requirement that CAs should not use SHA-1 at all any more.

> Frankly, I'm disappointed that despite my efforts to draw attention to
> this issue in March, both in the context of non-serverAuth certificates[2]
> and OCSP responses[3], Mozilla took no further action, such as
> amending Mozilla policy or proposing a CABF ballot to plug this hole.

Your disappointment stings.

> If they had sent an incident report to Mozilla I would agree, but I do
> not think that CAs should be credited for noticing mistakes when they
> try to sweep them under the rug.  This is particularly true in the case
> of SHA-1 misissuance, where revoking without broader notification
> demonstrates not competence but rather a lack of understanding of the
> risks.

Your point being that if they do disclose, the community can then run
crypto analysis over the cert to see if it's likely to be constructed as
part of a collision attempt?

Gerv

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

Re: New SHA-1 certificates issued in 2016

2016-11-04 Thread Andrew Ayer 
On Fri, 4 Nov 2016 10:30:00 +
Gervase Markham  wrote:

> We need to recall that currently, SHA-1 issuance is not banned
> directly by Mozilla policy, but only by the BRs. And so we don't have
> a route to object to certs not covered by the BRs.

The March 2016 CA communication said[1]:

"It has been pointed out in the mozilla.dev.security.policy forum that
a chosen-prefix attack on SHA-1 could be used to forge a certificate if
a CA's private key is used to sign *anything* with SHA-1."

Therefore, CAs participating in the Mozilla program know that this
practice is dangerous.

Frankly, I'm disappointed that despite my efforts to draw attention to
this issue in March, both in the context of non-serverAuth certificates[2]
and OCSP responses[3], Mozilla took no further action, such as
amending Mozilla policy or proposing a CABF ballot to plug this hole.

> >> D) Small numbers (1 or 2) of SHA-1 certs issued in early January.
> >> One could perhaps charitably say that the CA or their subCA made a
> >>mistake, realised, has fixed it, and hasn't made it since. Now
> >> it's November, is this worth chasing? (4 CAs)
> >>
> >> Also, does it make it better if the CA has already revoked the
> >> certificate before we report it to them?
> > 
> > No. Revocation doesn't help because the forged/collided cert need
> > not share the same serial number.  Revocation would only help if it
> > were based on the SHA-1 hash of the TBSCertificate.
> 
> We are not _just_ looking at SHA-1 issuance through the lens of
> collision; it's also a compliance and competence issue. I think a CA
> which issues a SHA-1 cert and doesn't notice seems less competent than
> one which does notice and immediately revokes it and doesn't issue
> another.

If they had sent an incident report to Mozilla I would agree, but I do
not think that CAs should be credited for noticing mistakes when they
try to sweep them under the rug.  This is particularly true in the case
of SHA-1 misissuance, where revoking without broader notification
demonstrates not competence but rather a lack of understanding of the
risks.

Regards,
Andrew


[1] 
https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o00iHdtx
[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/DEgLsxMfBAAJ
[3] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

2016-11-04 Thread Rick Andrews 
On Friday, November 4, 2016 at 4:49:28 AM UTC-7, Gervase Markham wrote:
> On 03/11/16 18:09, Andrew Ayer wrote:
> > This is just as bad as signing an actual cert with SHA-1.
> 
> Add:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315225 (Symantec)
> 
> Gerv

I updated the bug to say that this was disclosed back in March and discussed on 
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/64$3Aa9$3A32$3A73$3Aa4$3A19$3Ad1$3A64/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

2016-11-04 Thread Gervase Markham 
On 03/11/16 18:09, Andrew Ayer wrote:
> This is just as bad as signing an actual cert with SHA-1.

Add:
https://bugzilla.mozilla.org/show_bug.cgi?id=1315225 (Symantec)

Gerv

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

Re: New SHA-1 certificates issued in 2016

2016-11-04 Thread Gervase Markham 
On 03/11/16 21:17, Jakob Bohm wrote:
> Note that the GlobalSign SHA-1 intermediaries chain only to their old
> SHA-1 root which is (I believe) not used for any SHA-256 certs, except
> a cross-cert that signs their current SHA-256 root.

Nevertheless, it is still in Mozilla's trust store.

> So I suspect the intent of GlobalSign is that the old SHA-1 root should
> loose its ServerAuth trust bit around 2017-01-01, reducing it to a
> SHA-1-forever root trusted only by old SHA-1-only systems and maybe for
> e-mail (because some non-Mozilla e-mail clients were very late to
> supporting SHA-2 e-mail signatures).

If this were true, a) that's not good enough, as SHA-1 issuance has been
banned by the BRs since 2016-01-01, and b) they would have needed to
file a bug for this trust change long ago, and I can't find one.

Gerv


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

Re: New SHA-1 certificates issued in 2016

2016-11-03 Thread Andrew Ayer 
On Thu, 3 Nov 2016 17:53:01 +
Gervase Markham  wrote:

> On 28/10/16 16:11, Patrick Figel wrote:
> > I found a number of SHA-1 certificates chaining up to CAs trusted by
> > Mozilla that have not been brought up on this list or on Bugzilla
> > yet.
> 
> Using the handy crt.sh link posted by Rob, I have gone through the
> 2016 SHA-1 issuances known to crt.sh to filter out those which chain
> up to a root trusted by Mozilla. (Handily, crt.sh contains this
> information as well.) There are a distressingly large number of
> them :-(
> 
> Based on Patrick's report, I filed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign)
> 
> and based on this additional research, I have filed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems)
> 
> There may be more in the future. I would be interested in the group's
> opinion on what to do about:
> 
> A) SHA-1 precerts with no actual cert logged (1 CA)

This is just as bad as signing an actual cert with SHA-1.  RFC6962 says:

"The signature on the TBSCertificate indicates the
certificate authority's intent to issue a certificate.  This intent
is considered binding (i.e., misissuance of the Precertificate is
considered equal to misissuance of the final certificate)."

This is not just a theoretical concern.  When this came up earlier this
year with Symantec, I explained that pre-certificates are a vector for
exploiting a SHA-1 collision, since the forged/collided certificate
need not contain the pre-certificate poison extension.

> B) SHA-1 email certificates with no DNS names, although their lack of
>an EKU means they are valid for server auth (2 CAs)

The more pertinent question is the issuing CA's EKU.

> C) SHA-1 email certificates with EKU but no serverAuth (1 CA)

Ditto.

> D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One
>could perhaps charitably say that the CA or their subCA made a
>mistake, realised, has fixed it, and hasn't made it since. Now it's
>November, is this worth chasing? (4 CAs)
> 
> Also, does it make it better if the CA has already revoked the
> certificate before we report it to them?

No. Revocation doesn't help because the forged/collided cert need not
share the same serial number.  Revocation would only help if it were
based on the SHA-1 hash of the TBSCertificate.

The common thread in all of these answers is that the forged/collided
certificate need not look anything like the data that the CA signed
with SHA-1.  Any time a CA trusted for serverAuth signs
attacker-controlled data using SHA-1 there is a risk of a forged
serverAuth certificate.

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

Re: New SHA-1 certificates issued in 2016

2016-11-03 Thread Gervase Markham 
On 28/10/16 16:11, Patrick Figel wrote:
> I found a number of SHA-1 certificates chaining up to CAs trusted by
> Mozilla that have not been brought up on this list or on Bugzilla yet.

Using the handy crt.sh link posted by Rob, I have gone through the 2016
SHA-1 issuances known to crt.sh to filter out those which chain up to a
root trusted by Mozilla. (Handily, crt.sh contains this information as
well.) There are a distressingly large number of them :-(

Based on Patrick's report, I filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign)

and based on this additional research, I have filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera)
https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa)
https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign)
https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems)

There may be more in the future. I would be interested in the group's
opinion on what to do about:

A) SHA-1 precerts with no actual cert logged (1 CA)

B) SHA-1 email certificates with no DNS names, although their lack of
   an EKU means they are valid for server auth (2 CAs)

C) SHA-1 email certificates with EKU but no serverAuth (1 CA)

D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One
   could perhaps charitably say that the CA or their subCA made a
   mistake, realised, has fixed it, and hasn't made it since. Now it's
   November, is this worth chasing? (4 CAs)

Also, does it make it better if the CA has already revoked the
certificate before we report it to them?

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

Re: New SHA-1 certificates issued in 2016

2016-11-03 Thread c 
On Saturday, October 29, 2016 at 12:02:54 PM UTC-5, Gervase Markham wrote:
> The scope of the BRs is debateable. These certs are clearly in scope for
> Mozilla policy, as they chain up to trusted roots; however Mozilla
> policy does not (yet) ban SHA-1 issuance other than via the BRs. This
> may be fixed in policy version 2.3.
> 
> Without tls-server-auth and with other EKUs, these certs would not be
> trusted in Firefox. The systemic risks from SHA-1 issuance remain, however.
> 
> Gerv

Gerv,
Given the discussions in the past about risks of SHA-1 issuance for *any* cert 
type, and the responses from action #1c from the March 2016 CA communication, 
are there any public plans for dealing type of certificate yet?
Do these non-server-certs only fall under the BR's sigAlg policy if a generated 
certificate collision has an EKU of server auth? (And by that time, is it too 
late?)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

2016-10-29 Thread Gervase Markham 
On 28/10/16 16:11, Patrick Figel wrote:
> I found a number of SHA-1 certificates chaining up to CAs trusted by
> Mozilla that have not been brought up on this list or on Bugzilla yet.
> Apologies in case I missed prior discussion for any of these, and kudos
> to censys for making this search incredibly easy.

Thank you for reporting these. Bugs filed:

https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign)
https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain)

Gerv

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

Re: New SHA-1 certificates issued in 2016

2016-10-29 Thread Gervase Markham 
On 28/10/16 16:11, Patrick Figel wrote:
> #7
> Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA"
> (Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth
> certificates, but I don't think the intermediates have any relevant
> technical constraints. I'm not sure if they're in scope for BRs/Mozilla,
> but here's the list in any case:
> https://crt.sh/?id=26427662=cablint
> https://crt.sh/?id=32333872=cablint
> https://crt.sh/?id=19594797=cablint
> https://crt.sh/?id=24979702=cablint

The scope of the BRs is debateable. These certs are clearly in scope for
Mozilla policy, as they chain up to trusted roots; however Mozilla
policy does not (yet) ban SHA-1 issuance other than via the BRs. This
may be fixed in policy version 2.3.

Without tls-server-auth and with other EKUs, these certs would not be
trusted in Firefox. The systemic risks from SHA-1 issuance remain, however.

Gerv

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

Re: New SHA-1 certificates issued in 2016

2016-10-28 Thread Ryan Sleevi 
On Friday, October 28, 2016 at 9:06:44 AM UTC-7, Ben Wilson wrote:
> -Original Message-
> Subject: RE: New SHA-1 certificates issued in 2016
> 
> Thank you, Patrick, for pointing these out to us.  DigiCert has been in the 
> forefront pushing the move toward SHA-2. In fact, we've been issuing SHA-2 
> certificates by default to our customers for a couple of years now.  We've 
> communicated with these sub-CAs and requested that these certificates be
> revoked.   We'll follow up with a status report on our efforts sometime next
> week.
> Sincerely yours,
> Ben Wilson
> DigiCert VP of Compliance

Ben,

While it's useful that you've requested these certs been revoked, as has been 
pointed out during numerous discussions of SHA-1, a revocation does not 
mitigate the fact that a SHA-1 cert was issued, as an attacker can manipulate 
the contents in such a way to avoid any revocations.

More important to the community would be understanding why these subordinate 
CAs are not complying with the Baseline Requirements, as required by the 
Mozilla Root Certificate Program policies, and as required by the Baseline 
Requirements.

As these are not technically constrained sub-CAs, what we have is demonstrable 
evidence of several possibilities, most seriously:
1) That these CAs may not be adhering to the Baseline Requirements as part of 
their policies - an indicator that their auditors may be derelict in their 
professional duties to ensure that the policies and practices are consistent 
with the BRs
2) If their policies document adherence, as they're required to, then these CAs 
are not issuing according to their CP/CPS

Could you indicate what steps DigiCert is taking to assure members of the 
public that these subordinate CAs will be operated in a manner consistent with 
expectations?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New SHA-1 certificates issued in 2016

2016-10-28 Thread Ben Wilson 
Resending without a digital signature.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Ben Wilson
Sent: Friday, October 28, 2016 10:01 AM
To: Patrick Figel <patfi...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: New SHA-1 certificates issued in 2016

Thank you, Patrick, for pointing these out to us.  DigiCert has been in the 
forefront pushing the move toward SHA-2. In fact, we've been issuing SHA-2 
certificates by default to our customers for a couple of years now.  We've 
communicated with these sub-CAs and requested that these certificates be
revoked.   We'll follow up with a status report on our efforts sometime next
week.
Sincerely yours,
Ben Wilson
DigiCert VP of Compliance

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Patrick Figel
Sent: Friday, October 28, 2016 9:12 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: New SHA-1 certificates issued in 2016

I found a number of SHA-1 certificates chaining up to CAs trusted by Mozilla 
that have not been brought up on this list or on Bugzilla yet.
Apologies in case I missed prior discussion for any of these, and kudos to 
censys for making this search incredibly easy.

#1
https://crt.sh/?id=32335005=cablint
  Common Name: portalcsg.siemens.com
  Serial: 1518050245
  Not Before: Jul 12 14:01:45 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Siemens Issuing CA Class Internet Server 2013
   - Siemens Internet CA V1.0

#2
https://crt.sh/?id=32335007=cablint
  Common Name: downloada.industrysoftware.automation.siemens.com
  Serial: 2087556804
  Not Before: May 10 15:54:05 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Siemens Issuing CA Class Internet Server 2013
   - Siemens Internet CA V1.0

#3
https://crt.sh/?id=32331581=cablint
  Common Name: VPN-PDC1.vodafone.com
  Serial: 77:00:1c:7f:f6:f8:7e:5d:d6:48:bf:72:4d:00:01:00:1c:7f:f6
  Not Before: Jun 23 09:39:53 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Vodafone (Corporate Services 2009)
   - Vodafone (Corporate Domain 2009)

#4
https://crt.sh/?id=20279777=cablint
  Common Name: styles.ag2rlamondiale.fr
  Serial: 11:21:79:9c:b3:3b:51:dd:43:a5:40:b5:a2:4b:81:38:b8:4a
  Not Before: May 23 12:02:20 2016 GMT
  Chains to: "Class 2 Primary CA" (DocuSign (OpenTrust/Keynectis)) via:
   - CLASS 2 KEYNECTIS CA

#5
https://crt.sh/?id=23099350=cablint
  Common Name: enterprisevault.dnb.no
  Serial: 7e:c3:58:c6:d5:0a:4a:7f:c6:be:ea:19:f3:f4:98:e5:9d:cd:df:41
  Not Before: May 19 13:15:04 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - DnB NOR ASA PKI Class G
   - Eurida Primary CA

#6
Don't know what to make of this one. It's a CA:true SHA-1 certificate.
Not sure what the BRs/Mozilla's policies have to say about this:
https://crt.sh/?id=2199=cablint
  Common Name: ACCV-CA3
  Serial: 1246797330
  Not Before: May 23 10:00:00 2016 GMT
  Chains to: "Root CA Generalitat Valenciana" (Government of Spain)

#7
Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA"
(Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth 
certificates, but I don't think the intermediates have any relevant technical 
constraints. I'm not sure if they're in scope for BRs/Mozilla, but here's the 
list in any case:
https://crt.sh/?id=26427662=cablint
https://crt.sh/?id=32333872=cablint
https://crt.sh/?id=19594797=cablint
https://crt.sh/?id=24979702=cablint
___
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 SHA-1 certificates issued in 2016

2016-10-28 Thread Ben Wilson 
Thank you, Patrick, for pointing these out to us.  DigiCert has been in the
forefront pushing the move toward SHA-2. In fact, we've been issuing SHA-2
certificates by default to our customers for a couple of years now.  We've
communicated with these sub-CAs and requested that these certificates be
revoked.   We'll follow up with a status report on our efforts sometime next
week.
Sincerely yours,
Ben Wilson
DigiCert VP of Compliance

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Patrick Figel
Sent: Friday, October 28, 2016 9:12 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: New SHA-1 certificates issued in 2016

I found a number of SHA-1 certificates chaining up to CAs trusted by Mozilla
that have not been brought up on this list or on Bugzilla yet.
Apologies in case I missed prior discussion for any of these, and kudos to
censys for making this search incredibly easy.

#1
https://crt.sh/?id=32335005=cablint
  Common Name: portalcsg.siemens.com
  Serial: 1518050245
  Not Before: Jul 12 14:01:45 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Siemens Issuing CA Class Internet Server 2013
   - Siemens Internet CA V1.0

#2
https://crt.sh/?id=32335007=cablint
  Common Name: downloada.industrysoftware.automation.siemens.com
  Serial: 2087556804
  Not Before: May 10 15:54:05 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Siemens Issuing CA Class Internet Server 2013
   - Siemens Internet CA V1.0

#3
https://crt.sh/?id=32331581=cablint
  Common Name: VPN-PDC1.vodafone.com
  Serial: 77:00:1c:7f:f6:f8:7e:5d:d6:48:bf:72:4d:00:01:00:1c:7f:f6
  Not Before: Jun 23 09:39:53 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Vodafone (Corporate Services 2009)
   - Vodafone (Corporate Domain 2009)

#4
https://crt.sh/?id=20279777=cablint
  Common Name: styles.ag2rlamondiale.fr
  Serial: 11:21:79:9c:b3:3b:51:dd:43:a5:40:b5:a2:4b:81:38:b8:4a
  Not Before: May 23 12:02:20 2016 GMT
  Chains to: "Class 2 Primary CA" (DocuSign (OpenTrust/Keynectis)) via:
   - CLASS 2 KEYNECTIS CA

#5
https://crt.sh/?id=23099350=cablint
  Common Name: enterprisevault.dnb.no
  Serial: 7e:c3:58:c6:d5:0a:4a:7f:c6:be:ea:19:f3:f4:98:e5:9d:cd:df:41
  Not Before: May 19 13:15:04 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - DnB NOR ASA PKI Class G
   - Eurida Primary CA

#6
Don't know what to make of this one. It's a CA:true SHA-1 certificate.
Not sure what the BRs/Mozilla's policies have to say about this:
https://crt.sh/?id=2199=cablint
  Common Name: ACCV-CA3
  Serial: 1246797330
  Not Before: May 23 10:00:00 2016 GMT
  Chains to: "Root CA Generalitat Valenciana" (Government of Spain)

#7
Some non-TLS-Server-Auth SHA-1 certificates chaining up to "Certum CA"
(Asseco Data Systems S.A.). Most appear to be S/MIME or TLS client auth
certificates, but I don't think the intermediates have any relevant
technical constraints. I'm not sure if they're in scope for BRs/Mozilla, but
here's the list in any case:
https://crt.sh/?id=26427662=cablint
https://crt.sh/?id=32333872=cablint
https://crt.sh/?id=19594797=cablint
https://crt.sh/?id=24979702=cablint
___
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