More SHA-1 certs

[Peter Bowen]

These are all in the last week

Sub-CA under SHECA (which has applied to be in the Mozilla program)
https://crt.sh/?id=12367776&opt=cablint

Sub-CA under DigiCert
https://crt.sh/?id=12460684&opt=cablint

Sub-CA under Symantec
https://crt.sh/?id=12456194&opt=cablint
https://crt.sh/?id=12434313&opt=cablint

[Rick Andrews]

The Sub-CA under Symantec is managed by one of our customers. We've reached out to them and we're investigating. More detail to follow.

[Steve Schultze]

Are CAs really not monitoring issuance of certs by their sub-CAs for simple
violations like this? Does this not violate a Mozilla or CAB Forum
policy? Should it?

On Mon, Feb 1, 2016 at 1:41 PM, Jeremy Rowley <jeremy...@digicert.com>
wrote:

> Same with DigiCert. This is a sub CA issued by Verizon. We've reached out
> to the customer to investigate why they had the issue and what they are
> doing to remediate. We will provide details once we receive them.

>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley
> =digice...@lists.mozilla
> .org] On Behalf Of Rick Andrews
> Sent: Monday, February 1, 2016 11:34 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: More SHA-1 certs
>
> On Sunday, January 31, 2016 at 9:47:53 AM UTC-8, Peter Bowen wrote:

> The Sub-CA under Symantec is managed by one of our customers. We've reached
> out to them and we're investigating. More detail to follow.

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

[Erwann Abalea]

Le dimanche 31 janvier 2016 18:47:53 UTC+1, Peter Bowen a écrit :
> Sub-CA under SHECA (which has applied to be in the Mozilla program)
> https://crt.sh/?id=12367776&opt=cablint

Wow. Each certificate has its own CRL. And this CRL is not properly partitioned (missing IDP extension).

[martin...@gmail.com]

Here's a list of all certificates with SHA-1 signatures and notBefore >= 2016-01-01, logged in the Certificate Transparency Log:
https://crt.sh/?cablint=211&minNotBefore=2016-01-01

[Charles Reiss]

On 02/05/16 20:13, martin...@gmail.com wrote:
> Here's a list of all certificates with SHA-1 signatures and notBefore >= 2016-01-01, logged in the Certificate Transparency Log:
> https://crt.sh/?cablint=211&minNotBefore=2016-01-01

Some notes on how these look as of now. The listed subCA CNs are:
- DOD CA-28
- DOD CA-27

These chain to DST ACES CA X6, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c21 and
https://cabforum.org/pipermail/public/2016-February/006696.html


- Intel External Basic Issuing CA 3A

These chain through a technically constrained subordinate CA
https://crt.sh/?id=1250505


- Symantec Private SSL SHA1 CA

These chain to the 1024-bit VeriSign roots 'Class 3 Public Primary
Certification Authority' and 'Class 3 Public Primary Certification
Authority - G2' which are no longer included in Mozilla's root program.

Curiously, the similar COMODO CA 'COMODO Domain Validation Legacy Server
CA 2' (chains to retired root 'UTN - DATACorp SGC') appears to be
exempted from listing? (example cert:
https://crt.sh/?id=12584167&opt=cablint)


- VeriSign Class 3 Secure Server CA - G3
- VeriSign Class 3 International Server CA - G3

I believe these are the certs at
https://cabforum.org/pipermail/public/2016-January/006519.html or
precertificates for them.

- RSA Corporate Server CA v2
- DnB NOR ASA PKI Class G
- Shared Business CA 3
- TI Trust Technologies Global CA
- Postecom CS3
- Aetna Inc. Certificate Authority
- SHECA
- AC Infrastructure
- YourNet SSL for business
- Verizon Public SureServer CA G14-SHA1

These have been mentioned here previously.

[Charles Reiss]

On 02/05/16 21:14, Ben Wilson wrote:
> Aren't all of these CA certificates?

The links in the '#' column are to lists of BR-noncompliant
certificates; the links in the 'Issuer Name' column are to information
about the issuing DN+public key of those certificates.

>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
> Behalf Of martin...@gmail.com
> Sent: Friday, February 5, 2016 1:13 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: More SHA-1 certs
>

> Here's a list of all certificates with SHA-1 signatures and notBefore >=
> 2016-01-01, logged in the Certificate Transparency Log:
> https://crt.sh/?cablint=211&minNotBefore=2016-01-01

[Rob Stradling]

On 05/02/16 21:43, Charles Reiss wrote:
> On 02/05/16 20:13, martin...@gmail.com wrote:

>> Here's a list of all certificates with SHA-1 signatures and notBefore >= 2016-01-01, logged in the Certificate Transparency Log:
>> https://crt.sh/?cablint=211&minNotBefore=2016-01-01
>

> Some notes on how these look as of now. The listed subCA CNs are:
> - DOD CA-28
> - DOD CA-27
>
> These chain to DST ACES CA X6, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c21 and
> https://cabforum.org/pipermail/public/2016-February/006696.html
>
>
> - Intel External Basic Issuing CA 3A
>
> These chain through a technically constrained subordinate CA
> https://crt.sh/?id=1250505
>
>
> - Symantec Private SSL SHA1 CA
>
> These chain to the 1024-bit VeriSign roots 'Class 3 Public Primary
> Certification Authority' and 'Class 3 Public Primary Certification
> Authority - G2' which are no longer included in Mozilla's root program.

"Class 3 Public Primary Certification Authority - G2" is still trusted
for serverAuthentication in Microsoft's root program.

> Curiously, the similar COMODO CA 'COMODO Domain Validation Legacy Server
> CA 2' (chains to retired root 'UTN - DATACorp SGC') appears to be
> exempted from listing? (example cert:
> https://crt.sh/?id=12584167&opt=cablint)

On the crt.sh database I'd marked "COMODO Domain Validation Legacy
Server CA 2" as out-of-scope for cablint checks, on the grounds that the
root (UTN - DATACorp SGC) has been (or is waiting to be) pulled from
root programs that demand BR compliance.

However, I'm going to add it back in-scope. We (Comodo) currently
intend that new certs issued under "UTN - DATACorp SGC" will adhere to
the BRs in every way except for SHA-1. It would be useful for crt.sh /
cablint to spot any unintended issues.

> - VeriSign Class 3 Secure Server CA - G3
> - VeriSign Class 3 International Server CA - G3
>
> I believe these are the certs at
> https://cabforum.org/pipermail/public/2016-January/006519.html or
> precertificates for them.
>
> - RSA Corporate Server CA v2
> - DnB NOR ASA PKI Class G
> - Shared Business CA 3
> - TI Trust Technologies Global CA
> - Postecom CS3
> - Aetna Inc. Certificate Authority
> - SHECA
> - AC Infrastructure
> - YourNet SSL for business
> - Verizon Public SureServer CA G14-SHA1
>
> These have been mentioned here previously.
>
>
>

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

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Yuhong Bao]

> "Class 3 Public Primary Certification Authority - G2" is still trusted
> for serverAuthentication in Microsoft's root program.

Actually the same is true for the G1 one too (they just added the trust back).
Yuhong Bao

[Erwann Abalea]

Le dimanche 31 janvier 2016 18:47:53 UTC+1, Peter Bowen a écrit :

> Sub-CA under SHECA (which has applied to be in the Mozilla program)
> https://crt.sh/?id=12367776&opt=cablint

One CRL per issued certificate, and the CRL isn't correctly limited in its scope, allowing for a CRL substitution attack to unrevoke a certificate.

[Rick Andrews]

We verified that the customer who managed that SubCA has revoked both certificates.

[Rob Stradling]

On 06/02/16 21:14, Rob Stradling wrote:
> On 05/02/16 21:43, Charles Reiss wrote:
>> On 02/05/16 20:13, martin...@gmail.com wrote:

This page can now show a chronological view. Click "Ungroup by Issuer"
and then sort by the notBefore date or by the date each cert was first
logged.

The chronological view should work for any cablint issue (not just SHA-1
certs issued after 2015).

<snip>

>> Curiously, the similar COMODO CA 'COMODO Domain Validation Legacy Server
>> CA 2' (chains to retired root 'UTN - DATACorp SGC') appears to be
>> exempted from listing? (example cert:
>> https://crt.sh/?id=12584167&opt=cablint)
>
> On the crt.sh database I'd marked "COMODO Domain Validation Legacy
> Server CA 2" as out-of-scope for cablint checks, on the grounds that the
> root (UTN - DATACorp SGC) has been (or is waiting to be) pulled from
> root programs that demand BR compliance.
>
> However, I'm going to add it back in-scope. We (Comodo) currently
> intend that new certs issued under "UTN - DATACorp SGC" will adhere to
> the BRs in every way except for SHA-1. It would be useful for crt.sh /
> cablint to spot any unintended issues.

I've also added an "excludeCAs" parameter, which takes a comma-separated
list of crt.sh CA IDs.

To exclude SHA-1 certs issued by Symantec and Comodo from previously
trusted roots, try this:
https://crt.sh/?cablint=211&dir=^&sort=1&minNotBefore=2016-01-01&excludeCAs=7198,11000&group=none

[Rob Stradling]

On 02/03/16 14:56, Rob Stradling wrote:
<snip>

> I've also added an "excludeCAs" parameter, which takes a comma-separated
> list of crt.sh CA IDs.
>
> To exclude SHA-1 certs issued by Symantec and Comodo from previously
> trusted roots, try this:
> https://crt.sh/?cablint=211&dir=^&sort=1&minNotBefore=2016-01-01&excludeCAs=7198,11000&group=none

I couldn't help but notice this SHA-1 precertificate issued by Symantec
a couple of days ago:
https://crt.sh/?id=13407116&opt=cablint

Dean, Rick, could you comment on this?

It doesn't seem to be related to the limited SHA-1 exception you
obtained for WorldPay. Any idea why the "Remediation:" [1] steps you
took in January didn't prevent the issuance of this precertificate?

Thanks.


[1] https://cabforum.org/pipermail/public/2016-January/006519.html

[sanja...@symantec.com]

Rob,
This was a pre-certificate. Our systems do not allow issuance of SHA-1 certificates and no certificate was issued. The pre-certificate was logged but then rejected. We are still investigating.

Thanks.

[Rob Stradling]

On 03/03/16 04:52, sanja...@symantec.com wrote:

> On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
<snip>

>> I couldn't help but notice this SHA-1 precertificate issued by Symantec
>> a couple of days ago:
>> https://crt.sh/?id=13407116&opt=cablint

<snip>
> Rob,

Sanjay, thanks for investigating.

> This was a pre-certificate. Our systems do not allow issuance of SHA-1 certificates and no certificate was issued.

Were you aware that RFC6962 says that "misissuance of the Precertificate
is considered equal to misissuance of the final certificate"?

> The pre-certificate was logged but then rejected. We are still investigating.

What do you mean by "...but then rejected"?

Serial number 64:a9:32:73:a4:19:d1:64:3f:6b:2d:a3:ca:97:f0:89 is not
currently listed on the CRL.

[Jeremy Rowley]

The RFC says "misissuance of a precertificate is considered equal to misissuance of a final certificate". This raises an interesting question. Pre certificates are not required to comply with the Cab forum's BRs as they fall out of scope (not intended to be used for TLS authentication). Sha1 certs are only considered misissued because the BRs say issuance of a SHA1 certificate is prohibited. If the certificate is never issued, the misissuance never occurred because the precertificate was not missused (no reqs against SHA1 precerts) and a certificate in violation of the BRs was never created.

Rob Stradling <rob.st...@comodo.com> wrote:

On 03/03/16 04:52, sanja...@symantec.com wrote:

> On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
<snip>

>> I couldn't help but notice this SHA-1 precertificate issued by Symantec
>> a couple of days ago:
>> https://crt.sh/?id=13407116&opt=cablint

<snip>
> Rob,

Sanjay, thanks for investigating.

> This was a pre-certificate. Our systems do not allow issuance of SHA-1 certificates and no certificate was issued.

Were you aware that RFC6962 says that "misissuance of the Precertificate
is considered equal to misissuance of the final certificate"?

> The pre-certificate was logged but then rejected. We are still investigating.

What do you mean by "...but then rejected"?

Serial number 64:a9:32:73:a4:19:d1:64:3f:6b:2d:a3:ca:97:f0:89 is not
currently listed on the CRL.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Richard Barnes]

Perhaps this is something we should clarify in the BRs or Mozilla
policy. While I'm glad an actual cert was not issued in this case, it
is important to maintain consistency between precertificates and
certificates, if only for the CT logs tell a consistent story.

In particular, I would propose that in this case, the serial number of
the precertificate should be considered used and revoked, and that
status should be reflected in the CRL and OCSP.

Sent from my iPhone. Please excuse brevity.

> On Mar 3, 2016, at 07:40, Jeremy Rowley <jeremy...@digicert.com> wrote:
>
> The RFC says "misissuance of a precertificate is considered equal to misissuance of a final certificate". This raises an interesting question. Pre certificates are not required to comply with the Cab forum's BRs as they fall out of scope (not intended to be used for TLS authentication). Sha1 certs are only considered misissued because the BRs say issuance of a SHA1 certificate is prohibited. If the certificate is never issued, the misissuance never occurred because the precertificate was not missused (no reqs against SHA1 precerts) and a certificate in violation of the BRs was never created.
>
>
> Rob Stradling <rob.st...@comodo.com> wrote:
>
>> On 03/03/16 04:52, sanja...@symantec.com wrote:

>> On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
> <snip>

>>> I couldn't help but notice this SHA-1 precertificate issued by Symantec
>>> a couple of days ago:
>>> https://crt.sh/?id=13407116&opt=cablint

> <snip>
>> Rob,
>
> Sanjay, thanks for investigating.
>
>> This was a pre-certificate. Our systems do not allow issuance of SHA-1 certificates and no certificate was issued.
>
> Were you aware that RFC6962 says that "misissuance of the Precertificate
> is considered equal to misissuance of the final certificate"?
>
>> The pre-certificate was logged but then rejected. We are still investigating.
>
> What do you mean by "...but then rejected"?
>
> Serial number 64:a9:32:73:a4:19:d1:64:3f:6b:2d:a3:ca:97:f0:89 is not
> currently listed on the CRL.
>

> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

[Andrew Ayer]

On Thu, 3 Mar 2016 08:25:52 -0800
Richard Barnes <rba...@mozilla.com> wrote:

> Perhaps this is something we should clarify in the BRs or Mozilla
> policy. While I'm glad an actual cert was not issued in this case, it
> is important to maintain consistency between precertificates and
> certificates, if only for the CT logs tell a consistent story.

There's a more important reason, which is that if you can get a CA to
sign a pre-cert using a weak hash algorithm, and that signature is
conveniently published in a CT log, you can potentially exploit a
collision to forge a valid, trusted certificate (the forgery need not
contain the poison extension)[1]. Because of this, issuing a SHA-1
pre-cert is _just as bad_ as issuing a SHA-1 cert - there is no silver
lining that the actual cert was not issued.

It's also troubling that a CA may be allowed to continue issuing
non-serverAuth certs with SHA-1 from an issuer that is also used for
serverAuth certs. Again, a collision attack could be used to forge a
trusted serverAuth cert.

I urge that this hole be fixed in both Mozilla policy and the BRs, not
just by clarifying the cert/pre-cert equivalence, but also by forbidding
an issuer that is trusted for serverAuth from signing _anything_ with
SHA-1.

Regards,
Andrew

[1] Unless the precert was signed by a dedicated precert signing
certificate, which was not the case here.

[Ryan Sleevi]

On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote:
> It's also troubling that a CA may be allowed to continue issuing
> non-serverAuth certs with SHA-1 from an issuer that is also used for
> serverAuth certs. Again, a collision attack could be used to forge a
> trusted serverAuth cert.
>
> I urge that this hole be fixed in both Mozilla policy and the BRs, not
> just by clarifying the cert/pre-cert equivalence, but also by forbidding
> an issuer that is trusted for serverAuth from signing _anything_ with
> SHA-1.

A resounding +1 to this. This goes back to the core goal - if a certificate has id-kp-serverAuth / is in scope for the BRs, the only way to make a reasonable argument about the cryptographic operations is if _everything_ issued by that CA is seen in scope.

This is not just a matter for SHA-1; consider an intermediate with id-kp-serverAuth and id-kp-emailProtection. If, in the issuance of S/MIME certificates, the CA leaves off the EKU from the leaf, and issues a commonName of "example.com", then that certificate - though intended for email - can now be used for TLS authentication. This is wholly independent of SHA-1 deprecation.

For this reason, I'm a strong supporter in mandating that the scope of Mozilla's policies - and, more importantly, the expectation of BR compliance - extends to include _all_ certificates issued from an intermediates capable of causing TLS certificate issuance, even if those leaves are not intended for TLS.

[Rob Stradling]

On 03/03/16 15:39, Jeremy Rowley wrote:
> The RFC says "misissuance of a precertificate is considered equal to misissuance of a final certificate". This raises an interesting question. Pre certificates are not required to comply with the Cab forum's BRs as they fall out of scope (not intended to be used for TLS authentication).

Jeremy, I have to disagree with you on that point.

The BRs say...
"7.1.2.5 Application of RFC 5280
For purposes of clarification, a Precertificate, as described in
RFC 6962 - Certificate Transparency, shall not be considered to
be a “certificate” subject to the requirements of RFC 5280 -
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile under these Baseline Requirements."

Precertificates must be in scope (for the BRs) for it to be within the
BRs' remit to declare them to be out of scope for RFC5280!

CT assists with "authenticating servers accessible through the
Internet", because it helps detect misissued certs. When CT is
enforced, you can have increased confidence that the server you've
connected to is indeed "authentic".

I think it's clear that precertificates _are_ "intended to be used for
authenticating servers accessible through the Internet" and that they
are in-scope for the BRs.

> Sha1 certs are only considered misissued because the BRs say issuance of a SHA1 certificate is prohibited. If the certificate is never issued, the misissuance never occurred because the precertificate was not missused (no reqs against SHA1 precerts) and a certificate in violation of the BRs was never created.
>
>
> Rob Stradling <rob.st...@comodo.com> wrote:
>
> On 03/03/16 04:52, sanja...@symantec.com wrote:

>> On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
> <snip>

>>> I couldn't help but notice this SHA-1 precertificate issued by Symantec
>>> a couple of days ago:
>>> https://crt.sh/?id=13407116&opt=cablint

> <snip>
>> Rob,
>
> Sanjay, thanks for investigating.
>
>> This was a pre-certificate. Our systems do not allow issuance of SHA-1 certificates and no certificate was issued.
>
> Were you aware that RFC6962 says that "misissuance of the Precertificate
> is considered equal to misissuance of the final certificate"?
>
>> The pre-certificate was logged but then rejected. We are still investigating.
>
> What do you mean by "...but then rejected"?
>
> Serial number 64:a9:32:73:a4:19:d1:64:3f:6b:2d:a3:ca:97:f0:89 is not
> currently listed on the CRL.

[sanja...@symantec.com]

Rob,
Following discussions with the customer who initiated this order, we have identified a technical deficiency in our system that allowed for hash algorithm modifications by a subset of customers to existing enrollments in limited circumstances, and only when pending administrator review prior to issuance. We released a patch today to add this case to our system-wide SHA1 blocking mechanisms. In addition, as an added precaution, we are evaluating an update to actively change any SHA1 orders encountered in our system to SHA256.

- Sanjay

[Rob Stradling]

On 04/03/16 04:18, Jeremy Rowley wrote:
> If you recall, the fact that pre-certs are out of scope of the BRs was one of the reasons against putting them into the BRs in the first place. The decision to add them was to assist CAs who may have an overly strict reading on scope considering the very loose language originally used: "These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet." The fact the BRs mention a document out of scope is not evidence of an intent to include them given the history of that particular language.
>
> Other comments:

> "CT assists with "authenticating servers accessible through the Internet", because it helps detect misissued certs. When CT is enforced, you can have increased confidence that the server you've connected to is indeed "authentic"."

> - Intending to assist is NOT the same thing as actually intending to authenticate servers accessible through the Internet.

Neither certificates nor precertificates authenticate servers. Signed
blobs of data don't do anything! It's the TLS client code that actually
authenticates the server.

So, IMHO, if precertificates are out of scope, then certificates are out
of scope too.

> "I think it's clear that precertificates _are_ "intended to be used for authenticating servers accessible through the Internet" and that they are in-scope for the BRs."

> - Completely disagree. I think it's clear they are NOT in scope...

We'll have to agree to disagree then.

> but I would (as always) support a ballot to fix this. The BR scope is terrible and really should be remedied.

+1. Let's make it so that there's no reason to disagree!

> It's been a plague for over a year. I'm 100% supportive of any proposal to include precerts and fix the language,

IIRC, all previous proposals for fixing the BR scope have focused on
features of the end-entity certificate profile. That's proved to be
problematic, because some CAs want/need to issue certs that could
technically be used for server authentication even though that's not the
intent (e.g. Subject.CN is included and EKU is required to be anyEKU).

Maybe we need to take a different approach that ignores the end-entity
certificate profile completely. How about we propose that...

- An X.509 certificate is in scope for the BRs if it's signed by an
Issuing CA that is in scope.

- An Issuing CA is in scope if:
i) it chains to a Root Certificate that is trusted for server
authentication
and
ii) there's no EKU "constraint" in that chain that excludes server
authentication.
and
iii) it hasn't been whitelisted by browsers as "out of scope".

?

> but, given the current wording, I don't agree that Symantec violated any rule the Forum has set.

>
> -----Original Message-----
> From: Rob Stradling [mailto:rob.st...@comodo.com]
> Sent: Thursday, March 3, 2016 2:49 PM
> To: Jeremy Rowley
> Cc: mozilla-dev-s...@lists.mozilla.org; sanja...@symantec.com
> Subject: Re: More SHA-1 certs
>

> On 03/03/16 15:39, Jeremy Rowley wrote:
>> The RFC says "misissuance of a precertificate is considered equal to misissuance of a final certificate". This raises an interesting question. Pre certificates are not required to comply with the Cab forum's BRs as they fall out of scope (not intended to be used for TLS authentication).
>
> Jeremy, I have to disagree with you on that point.
>
> The BRs say...
> "7.1.2.5 Application of RFC 5280
> For purposes of clarification, a Precertificate, as described in
> RFC 6962 - Certificate Transparency, shall not be considered to
> be a “certificate” subject to the requirements of RFC 5280 -
> Internet X.509 Public Key Infrastructure Certificate and Certificate
> Revocation List (CRL) Profile under these Baseline Requirements."
>
> Precertificates must be in scope (for the BRs) for it to be within the BRs' remit to declare them to be out of scope for RFC5280!
>
> CT assists with "authenticating servers accessible through the Internet", because it helps detect misissued certs. When CT is enforced, you can have increased confidence that the server you've connected to is indeed "authentic".
>
> I think it's clear that precertificates _are_ "intended to be used for authenticating servers accessible through the Internet" and that they are in-scope for the BRs.
>
>> Sha1 certs are only considered misissued because the BRs say issuance of a SHA1 certificate is prohibited. If the certificate is never issued, the misissuance never occurred because the precertificate was not missused (no reqs against SHA1 precerts) and a certificate in violation of the BRs was never created.
>>
>>
>> Rob Stradling <rob.st...@comodo.com> wrote:
>>
>> On 03/03/16 04:52, sanja...@symantec.com wrote:

>>> On Wednesday, March 2, 2016 at 7:07:23 AM UTC-8, Rob Stradling wrote:
>> <snip>

>>>> I couldn't help but notice this SHA-1 precertificate issued by
>>>> Symantec a couple of days ago:
>>>> https://crt.sh/?id=13407116&opt=cablint

>> <snip>
>>> Rob,
>>
>> Sanjay, thanks for investigating.
>>
>>> This was a pre-certificate. Our systems do not allow issuance of SHA-1 certificates and no certificate was issued.
>>
>> Were you aware that RFC6962 says that "misissuance of the
>> Precertificate is considered equal to misissuance of the final certificate"?
>>
>>> The pre-certificate was logged but then rejected. We are still investigating.
>>
>> What do you mean by "...but then rejected"?
>>
>> Serial number 64:a9:32:73:a4:19:d1:64:3f:6b:2d:a3:ca:97:f0:89 is not
>> currently listed on the CRL.
>

> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Matt Palmer]

On Fri, Mar 04, 2016 at 09:19:36PM +0000, Rob Stradling wrote:
> Maybe we need to take a different approach that ignores the end-entity
> certificate profile completely. How about we propose that...
>
> - An X.509 certificate is in scope for the BRs if it's signed by an
> Issuing CA that is in scope.
>
> - An Issuing CA is in scope if:
> i) it chains to a Root Certificate that is trusted for server
> authentication

You'll want to describe *who* trusts the root. I trust lots of private PKI
roots for server authentication in my own gear, but they're never going
mainstream.

Perhaps "it chains to a Root Certificate that is trusted, or is intended to
be trusted, by one or more Browser members of the CA/Browser Forum for
server authentication"? The "intended to be trusted" is to make sure that
candidates for browser trust programs know they're on the hook, too.

- Matt

[Rob Stradling]

On 04/03/16 23:14, Matt Palmer wrote:
> On Fri, Mar 04, 2016 at 09:19:36PM +0000, Rob Stradling wrote:
>> Maybe we need to take a different approach that ignores the end-entity
>> certificate profile completely. How about we propose that...
>>
>> - An X.509 certificate is in scope for the BRs if it's signed by an
>> Issuing CA that is in scope.
>>
>> - An Issuing CA is in scope if:
>> i) it chains to a Root Certificate that is trusted for server
>> authentication
>
> You'll want to describe *who* trusts the root.

Hi Matt. I thought somebody might point that out. Sorry for my
handwaviness. ;-)

"*who* trusts" is indeed important, but it wasn't the aspect of the
scope problem I was trying to solve with my previous post.

> I trust lots of private PKI
> roots for server authentication in my own gear, but they're never going
> mainstream.
>
> Perhaps "it chains to a Root Certificate that is trusted, or is intended to
> be trusted, by one or more Browser members of the CA/Browser Forum for
> server authentication"? The "intended to be trusted" is to make sure that
> candidates for browser trust programs know they're on the hook, too.
>
> - Matt

[Rob Stradling]

On 04/03/16 23:41, Jeremy Rowley wrote:
> > My fix is much simpler (because the BRs have traditionally avoided requiring reissuance of sub CAs). Require that all certs with serverauth, anyEKU, or no EKU be covered by the BRs. CAs required to issue certs that are covered but cannot conform (because of another policy) will get a qualified audit that can then be addressed with the browsers. There's no reason to make an exception since all three types can be used for server authentication. This gives everyone notice the CA is issuing non-compliant certs that may be risky but lets the browsers decide whether to accept the risk.

[It's clearly time to change the Subject line :-) ]

Hi Jeremy. Your fix would be an improvement over the current BR scope,
but I agree with Andrew and Ryan [1] that we need to go further than
that: if a cert is in scope, then all certs issued by its issuer need to
be in scope.

I don't think relying on qualified audits is the way to go. I'd like to
see programmatic enforcement. I think browsers should "blacklist"
intermediates that don't intend to issue, but are nonetheless capable of
issuing, publicly trusted TLS certs.


[1]
https://www.mail-archive.com/dev-security-policy%40lists.mozilla.org/msg02985.html

[Jakob Bohm]

How about "It chains to a Root certificate claiming compliance with
these BRs". This is a clear condition with a well-defined and
controllable meaning. Either a CA root is intended as a CAB/F
compliant root submitted to all the relevant browser related trust
lists and thus would seek compliance with the BR, or that root (even if
operated by the same entity as a BR compliant root) doesn't do that.

And while we are at it, we also need to look at what the scope rules
would be for e-mail and code certificates and CAs. E-mail because of
Thunderbird.

Code certificates because while the Mozilla corporate folks have
abandoned the concept, many other people have not, and this Mozilla
forum remains the primary contact point between the open source
community and the CAs, partially because many Open Source distributions
(including at least Debian and Ubuntu) use the Mozilla CA list as the
basis for their system-wide general purpose certificate stores.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Eric Mill]

On Mon, Mar 7, 2016 at 12:04 PM, Jeremy Rowley <jeremy...@digicert.com>
wrote:

> Programmatic enforcement is outside the scope of the BRs. I'd like to do
> something (as CAs) to remediate the issue.
>

But the potential for programmatic enforcement by browsers is a factor for
all CABF members to consider when creating the BRs.

-- Eric

>
> -----Original Message-----
> From: Rob Stradling [mailto:rob.st...@comodo.com]
> Sent: Monday, March 7, 2016 4:04 AM
> To: Jeremy Rowley
> Cc: mozilla-dev-s...@lists.mozilla.org

> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
>

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

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

[Richard Barnes]

On Wed, Mar 9, 2016 at 4:01 PM, Jeremy Rowley <jeremy...@digicert.com>
wrote:

> Restricting by root isn't feasible. The browsers limit the number of root
> CAs each CA can have.


[citation-needed] (?)

I'm not aware of any such restriction in the Mozilla policy. And in fact,
this discussion seems like a good reason for removing one if there is.

--Richard


> , meaning most CAs chain Code Signing and Client chain
> to the same root as server certs.

>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley
> =digice...@lists.mozilla

> .org] On Behalf Of Jakob Bohm
> Sent: Monday, March 7, 2016 4:50 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: More SHA-1 certs
>

> On 07/03/2016 11:36, Rob Stradling wrote:

> How about "It chains to a Root certificate claiming compliance with
> these BRs". This is a clear condition with a well-defined and
> controllable meaning. Either a CA root is intended as a CAB/F compliant
> root submitted to all the relevant browser related trust lists and thus
> would seek compliance with the BR, or that root (even if operated by the
> same entity as a BR compliant root) doesn't do that.
>
> And while we are at it, we also need to look at what the scope rules would
> be for e-mail and code certificates and CAs. E-mail because of
> Thunderbird.
>
> Code certificates because while the Mozilla corporate folks have abandoned
> the concept, many other people have not, and this Mozilla forum remains the
> primary contact point between the open source community and the CAs,
> partially because many Open Source distributions (including at least Debian
> and Ubuntu) use the Mozilla CA list as the basis for their system-wide
> general purpose certificate stores.
>
>
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej
> 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion
> message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

[Rob Stradling]

On 09/03/16 21:04, Richard Barnes wrote:
> On Wed, Mar 9, 2016 at 4:01 PM, Jeremy Rowley <jeremy...@digicert.com>
> wrote:
>
>> Restricting by root isn't feasible. The browsers limit the number of root
>> CAs each CA can have.
>
> [citation-needed] (?)

Here's one example:

https://www.apple.com/certificateauthority/ca_program.html

"A maximum of three roots per CA provider can be accepted because each
additional root negatively impacts users by increasing download time."

<snip>

[Charles Reiss]

On 03/03/16 19:48, Ryan Sleevi wrote:
> On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote:
>> It's also troubling that a CA may be allowed to continue issuing
>> non-serverAuth certs with SHA-1 from an issuer that is also used
>> for serverAuth certs. Again, a collision attack could be used to
>> forge a trusted serverAuth cert.
>>
>> I urge that this hole be fixed in both Mozilla policy and the BRs,
>> not just by clarifying the cert/pre-cert equivalence, but also by
>> forbidding an issuer that is trusted for serverAuth from signing
>> _anything_ with SHA-1.
>
> A resounding +1 to this. This goes back to the core goal - if a
> certificate has id-kp-serverAuth / is in scope for the BRs, the only
> way to make a reasonable argument about the cryptographic operations
> is if _everything_ issued by that CA is seen in scope.
>
> This is not just a matter for SHA-1; consider an intermediate with
> id-kp-serverAuth and id-kp-emailProtection. If, in the issuance of
> S/MIME certificates, the CA leaves off the EKU from the leaf, and
> issues a commonName of "example.com", then that certificate - though
> intended for email - can now be used for TLS authentication. This is
> wholly independent of SHA-1 deprecation.

And I'd guess that (based on lack of EKU and existence of rfc822Name
SAN) this SHA-1 certificate is an example of precisely that problem:
https://crt.sh/?id=15019496
(used in the wild for a TLS server as of this writing:
https://censys.io/ipv4/194.145.239.217)

[Jakob Bohm]

That seems a particularly clumsily generated certificate:

- DNS name (for https?) in CN, but not repeated as a SAN (as per PKIX).

- SAN present but does not include the server name from the CN, this
might make some PKIX-based clients fail to match the name to the
certificate.

- SHA-1 certificate with apparently intended https usage issued after
2016-01-01.

- e-mailaddress in DN placed before CN (tradition is after, so the
matchable CN for older browsers is the first element of the DN).

- No EKU extension and no Netscape usage extension.

>
>>
>> For this reason, I'm a strong supporter in mandating that the scope
>> of Mozilla's policies - and, more importantly, the expectation of BR
>> compliance - extends to include _all_ certificates issued from an
>> intermediates capable of causing TLS certificate issuance, even if
>> those leaves are not intended for TLS.
>>
>

Indeed, if an intermediary is not technically constrained, it should be
subject to the BRs. But if it is technically constrained to the
maximum extent possible and audited for anything that could not be
constrained away, it should remain exempt, such that CAs can continue
to support platforms that are stuck in the past for purposes that don't
interfere with modern clients.

Code signing for various Microsoft platforms is a key example of such a
situation. The Microsoft platforms that are still restricted to SHA-1
signatures are also restricted to old CA lists, so setting up new roots
for supporting those is not viable, and not every CA has an old root
they can "throw away", like Symantec did with some of the branded roots
they had accumulated.

[Ryan Sleevi]

On Thursday, March 10, 2016 at 11:07:51 PM UTC-8, Jakob Bohm wrote:
> - DNS name (for https?) in CN, but not repeated as a SAN (as per PKIX).

Not PKIX. It's the Baseline Requirements.

> - SAN present but does not include the server name from the CN, this
> might make some PKIX-based clients fail to match the name to the
> certificate.

Again, not a PKIX thing. You're thinking RFC 2818 (HTTPS) or RFC 6125. However, as detailed in both documents, it's not the presence of the sAN that makes the CN ignored, it's the presence of a SAN with the dNSName (or iPAddress, as appropriate) type.

Which is to say, any conforming RFC 6125 or RFC 2818 client that recognizes the commonName field *should* still accept this as valid, as the certificate lacks a dNSName SAN that would cause only the SAN values to be used.

> - SHA-1 certificate with apparently intended https usage issued after
> 2016-01-01.

Quite. This is a BR violation (not a PKIX violation)

> - e-mailaddress in DN placed before CN (tradition is after, so the
> matchable CN for older browsers is the first element of the DN).

This is simply not true. You're conflating the presence of multiple commonNames with the general name type. The compatability issues do not arise with respect to where the commonName field appears within the Subject, only what happens when multiple commonName fields appear. And even then, there is no 'tradition' here - some clients respect the first appearance of the commonName, others the last, and yet others still all.

It is at least to their credit that they ordered the SEQUENCE-SET-SEQUENCE tuples of AVAs such that there's only one SEQUENCE per SET; when multiple AVAs appear within a SET, there are further compatability issues (because all name types nested within the SET are considered equivalent)

> - No EKU extension and no Netscape usage extension.

>From a PKIX perspective, this is perfectly fine - the absence of the EKU means this certificate is unrestricted from an RFC 5280 standpoint (although from a modern client library behaviour, the restriction is the intersection of the intermediate and root CAs' EKUs)

>From a Baseline Requirements perspective, this is also a BR violation (item 7.1.2.3, item f)

> Code signing for various Microsoft platforms is a key example of such a
> situation. The Microsoft platforms that are still restricted to SHA-1
> signatures are also restricted to old CA lists, so setting up new roots
> for supporting those is not viable, and not every CA has an old root
> they can "throw away", like Symantec did with some of the branded roots
> they had accumulated.

And Comodo. And Entrust. And I think there were one or two more.