Applicability of SHA-1 Policy to Timestamping CAs

[Wayne Thayer]

I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply
to timestamping CAs. Specifically, does Mozilla policy apply to the
issuance of a SHA-1 CA certificate asserting only the timestamping EKU and
chaining to a root in our program? Because this certificate is not in scope
for our policy as defined in section 1.1, I do not believe that this would
be a violation of the policy. And because the CA would be in control of the
entire contents of the certificate, I also do not believe that this action
would create an unacceptable risk.

I would appreciate everyone's input on this interpretation of our policy.

- Wayne

[Doug Beattie]

GlobalSign concurs.

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

[Andrew Ayer]

On Fri, 22 Mar 2019 12:50:43 -0600
Wayne Thayer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> I've been asked if the section 5.1.1 restrictions on SHA-1 issuance
> apply to timestamping CAs. Specifically, does Mozilla policy apply to
> the issuance of a SHA-1 CA certificate asserting only the
> timestamping EKU and chaining to a root in our program? Because this
> certificate is not in scope for our policy as defined in section 1.1,
> I do not believe that this would be a violation of the policy. And
> because the CA would be in control of the entire contents of the
> certificate, I also do not believe that this action would create an
> unacceptable risk.

It was the intent of section 5.1.1 to apply to such certificates, and
the wording in 5.1.1, which talks about "CAs" signing "SHA-1 hashes"
means that 5.1.1 applies even when the apparent signed data isn't a
certificate in scope of Mozilla policy. This is necessary because the
problem with hash collisions is that while the data the CA thinks it's
signing might not be a certificate in scope of Mozilla policy, the hash
might collide with a certificate that *is* in scope.

Although this isn't a risk when the CA controls all the data to be signed,
5.1.1 doesn't distinguish this case.

However, 5.1.1 provides an exception if a CA needs to issue a SHA-1
intermediate certificate:

> CAs MAY sign SHA-1 hashes over intermediate certificates which chain
> up to roots in Mozilla's program only if the certificate to be signed
> is a duplicate of an existing SHA-1 intermediate certificate with the
> only changes being all of:
>
> * a new key (of the same size);
> * a new serial number (of the same length);
> * the addition of an EKU and/or a pathlen constraint to meet the
> requirements outlined above.

This is the only compliant way a CA can sign a SHA-1 intermediate that
chains up to a root that's included by Mozilla.

Regards,
Andrew

[Andrew Ayer]

[Ryan Sleevi]

On Fri, Mar 22, 2019 at 4:00 PM Andrew Ayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Fri, 22 Mar 2019 12:50:43 -0600
> Wayne Thayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > I've been asked if the section 5.1.1 restrictions on SHA-1 issuance
> > apply to timestamping CAs. Specifically, does Mozilla policy apply to
> > the issuance of a SHA-1 CA certificate asserting only the
> > timestamping EKU and chaining to a root in our program? Because this
> > certificate is not in scope for our policy as defined in section 1.1,
> > I do not believe that this would be a violation of the policy. And
> > because the CA would be in control of the entire contents of the
> > certificate, I also do not believe that this action would create an
> > unacceptable risk.
>
> It was the intent of section 5.1.1 to apply to such certificates, and
> the wording in 5.1.1, which talks about "CAs" signing "SHA-1 hashes"
> means that 5.1.1 applies even when the apparent signed data isn't a
> certificate in scope of Mozilla policy. This is necessary because the
> problem with hash collisions is that while the data the CA thinks it's
> signing might not be a certificate in scope of Mozilla policy, the hash
> might collide with a certificate that *is* in scope.
>

I agree with Andrew - this was very much the intent. This is similar to the
advice given in a recent reply [1], is consistent with the past discussion
regarding OCSP signers, which GlobalSign had also brought up [2][3], which
past CAs have regarded as incidents [4][5], and which lead to the exception
Andrew mentions here.

It was the intent of the policy that this be prohibited, except as noted.
[7]

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/vDhKG7T6sCM/vtGubR0pBwAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/NthdT8sOQQ0/q37006A6AAAJ
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/aCJQ5JkYcVw/diq_e0_kAQAJ
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/paXc44rj5PU/lfydcQ_HAgAJ
[5]
https://groups.google.com/d/msg/mozilla.dev.security.policy/6BdFdNQKJoY/NY_owWajAAAJ
[6]
https://groups.google.com/d/msg/mozilla.dev.security.policy/ScoboGpN4w4/GxUCmGWuBgAJ
[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/wVhRt63bTpU/FxxNlYzxCQAJ

[Ryan Sleevi]

[David E. Ross]

Services such as the PGP Digital Timestamping Service at
<http://www.itconsult.co.uk/stamper.htm> use OpenPGP keys, not X.509 keys.

--
David E. Ross

Pharmaceutical companies claim their drug prices are
so high because they have to recover the costs of developing
those drugs. Two questions:

1. Why is the U.S. paying the entire cost of development while
prices for the same drugs in other nations are much lower?

2. Manufacturers of generic drugs did not have those
development costs. Why are they charging so much for generics?

[Wayne Thayer]

Thanks Andrew and Ryan. I can certainly see the intent to implement a
comprehensive ban on SHA-1 with the "sign SHA-1 hashes" language in section
5.1.1. This implies that section 5.1.1 overrides the scope statement in
section 1.1of our policy.

However, it is also apparent that S/MIME is intentionally not in scope [1]:

Therefore, we would like to update Mozilla's CA policy to implement a
"proper" SHA-1 ban. At the moment, it seems difficult to define a SHA-1
ban for email, so the current text leaves that for a future update.

A number of CAs reported continuing issuance of code signing certificates
[2] after this policy went into effect, and it appears that section 5.1.1
permit this as well. What it does not permit is the issuance of new SHA-1
CA certificates, even if constrained for uses other than serverAuth, with
pathlen=0, containing data controlled by the CA.

The evidence that I've found points to this being an oversight rather than
an intentional ban on the issuance of the CA certificate that I described,
but under the assumption that section 5.1.1 overrides section 1.1, then I
have to agree that our policy forbids it.

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RwymOVM_Ldg/y2_OMydfDgAJ
[2]
https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011

On Fri, Mar 22, 2019 at 4:43 PM Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> On Fri, Mar 22, 2019 at 4:00 PM Andrew Ayer via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On Fri, 22 Mar 2019 12:50:43 -0600
>> Wayne Thayer via dev-security-policy

>> <dev-secur...@lists.mozilla.org> wrote:
>>
>> > I've been asked if the section 5.1.1 restrictions on SHA-1 issuance
>> > apply to timestamping CAs. Specifically, does Mozilla policy apply to
>> > the issuance of a SHA-1 CA certificate asserting only the
>> > timestamping EKU and chaining to a root in our program? Because this
>> > certificate is not in scope for our policy as defined in section 1.1,
>> > I do not believe that this would be a violation of the policy. And
>> > because the CA would be in control of the entire contents of the
>> > certificate, I also do not believe that this action would create an
>> > unacceptable risk.
>>

[Peter Bowen]

On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> I've been asked if the section 5.1.1 restrictions on SHA-1 issuance apply
> to timestamping CAs. Specifically, does Mozilla policy apply to the
> issuance of a SHA-1 CA certificate asserting only the timestamping EKU and
> chaining to a root in our program? Because this certificate is not in scope
> for our policy as defined in section 1.1, I do not believe that this would
> be a violation of the policy. And because the CA would be in control of the
> entire contents of the certificate, I also do not believe that this action
> would create an unacceptable risk.
>

> I would appreciate everyone's input on this interpretation of our policy.
>

Do you have any information about the use case behind this request? Are
there software packages that support a SHA-2 family hash for the issuing CA
certificate for the signing certificate but do not support SHA-2 family
hashes for the timestamping CA certificate?

[Wayne Thayer]

I was simply asked if our policy does or does not permit this, so I can
only speculate that the use case involves code signing that targets an
older version of Windows. If the person who asked the question would like
to send me specifics, I'd be happy to relay them to the list.

[Jakob Bohm]

As a matter of general information (I happen to have investigated MS
"AuthentiCode" code signing in some detail):

1. Some parts of some Windows versions will only accept certificate
chains using the RSA-SHA1 (PKCS#1 v1.x) signature types. Those
generally chain to a root of similar vintage, which may or may not
still be issuing SHA-2 intermediary certificates under Mozilla
Policy.

2. Some parts of some Windows versions will only accept EE certs using
RSA-SHA1, but will accept RSA-SHA2 higher in the certificate chain.

3. Recent Windows versions will accept RSA-SHA2 signatures, but may or
may not accept RSA-SHA1 signatures.

4. Most parts of Windows versions that accept RSA-SHA2 signatures allow
dual signature configurations where items are signed with both RSA-SHA2
and RSA-SHA1 signatures in such a way that older versions will see
and accept the RSA-SHA1 signature while newer versions will see and
check the RSA-SHA2 signature (or both signatures).

5. All post-1996 MS code signing systems expect and check the presence of
countersignatures by a timestamping authority with long validity period
(many decades). These signatures verify that the signature made by the
EE certificate existed on or before a certain time within the (1 to 5
year) validity period of the EE cert itself. Thus barring an existential
forgery of the timestamping signature, most other aspects need only
resist second pre-image style attacks on the EE signature.

Type 1 and 2 subsystems are still somewhat widespread as official
attempts to backport RSA-SHA2 support have failed or never been made.

Thus there is an ongoing need for certificate subscribers to obtain and
use both types of certificates and the corresponding timestamp
countersignature services.

The ongoing shutdown of old Symantec infrastructure has left a lot of
subscribers to these certificates looking for replacement CAs, thus
making it interesting for CAs that were included in the relevant MS root
program back in the day to begin or restart providing those services to
former Symantec subscribers.

As for myself and my company, we switched to a non-Symantec CA for these
services before the general SHA-1 deprecation and thus the CA we use can
continue to update relevant intermediary CAs using the exception to
extend the lifetime of historic issuing CAs. However it would probably
be more secure (less danger to users) if CAs routinely issued
sequentially named new issuing CAs for these purposes at regular
intervals (perhaps annually), however this is against current Mozilla
Policy if the root is still in the Mozilla program (as an anchor for
SHA2 WebPKI or e-mail certs).


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

[Wayne Thayer]

My general sense is that we should be doing more to discourage the use of
SHA-1 rather than less. I've just filed an issue [1] to consider a ban on
SHA-1 S/MIME certificates in the future.

On Mon, Mar 25, 2019 at 10:54 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> As for myself and my company, we switched to a non-Symantec CA for these
> services before the general SHA-1 deprecation and thus the CA we use can
> continue to update relevant intermediary CAs using the exception to
> extend the lifetime of historic issuing CAs. However it would probably
> be more secure (less danger to users) if CAs routinely issued
> sequentially named new issuing CAs for these purposes at regular
> intervals (perhaps annually), however this is against current Mozilla
> Policy if the root is still in the Mozilla program (as an anchor for
> SHA2 WebPKI or e-mail certs).
>
>

I do acknowledge the legacy issue that Jakob points out, but given that it
hasn't come up before, I question if it is a problem that we need to
address. I would be interested to hear from others who have a need to issue
new SHA-1 subordinate CA certificates for uses beyond the scope of the BRs.
We could consider a loosening of the section 5.1.1 requirements on
intermediates, but I am concerned about creating loopholes and about
contradicting the BRs (which explicitly ban SHA-1 OCSP signing certificates
in section 7.1.3).

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/178

[Jakob Bohm]

The situation has resurfaced due to recent developments affecting the
original workarounds.

I will have to remind everyone, that when SHA-1 was deprecated, Symantec
handled this legacy issue by formally withdrawing a few of their many
old (historically Microsoft trusted) roots from the Mozilla root
program, allowing those roots to continue to run as "SHA-1-forever"
roots completely beyond all "modern" policies.

As Digicert winds down the legacy parts of Symantec operations, Windows
developers that didn't leave Symantec early will be hunting for
alternatives among the CAs whose SHA-1 roots were trusted by the
affected MS software versions. A number of those CAs don't have such a
stockpile of legacy roots that could be removed from the modern PKI
ecosystem without affecting the validity of current SHA-2 certificates.

For example GlobalSign, another large CA, only has one root trusted by
legacy SHA-1 systems, their R1 root. That root is unfortunately also
their forward compatibility root that provides trust to modern WebPKI
certificates via cross-signing of later GlobalSign roots. This means
that anything GlobalSign does in the SHA-1 compatibility space is
constrained by CAB/F, CASC and Mozilla policies, such as the Mozilla
restriction to not cut new issuing compatibility CAs and the CASC
restriction to stop all SHA-1 code signing support in 2021.

Creating new SHA-1-only roots (outside the modern PKI) for this job is
not viable, as the roots need to be in the historic versions of the MS
root store as bundled by affected systems. For some code, the roots
even need to be among the few that got a special kernel mode cross-cert
from Microsoft. Those legacy root stores were completely dominated by
roots that were bought up by Symantec.

Raw data:

The full historic list of roots with kernel mode MS cross certs [Apologies if
root transfers have sent some to different companies than indicated]

Trusted until 2023 (in alphabetical order by brand):

[GoDaddy] C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority

[GoDaddy] C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority

[Sectigo] C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root

[Sectigo] C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Object



Trusted until 2021 Not Digicert/Symantec (in alphabetical order by brand):

[EnTrust] O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)

[GlobalSign] C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA

[GoDaddy] C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

[GoDaddy] C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2

[NetLock] C=HU, L=Budapest, O=NetLock Kft., OU=Tanúsítványkiadók (Certification Services), CN=NetLock Arany (Class Gold) Főtanúsítvány

[NetLock] C=HU, L=Budapest, O=NetLock Kft., OU=Tanúsítványkiadók (Certification Services), CN=NetLock Platina (Class Platinum) Főtanúsítvány

[Quihoo] C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority

[SECOM] C=JP, O=SECOM Trust.net, OU=Security Communication RootCA1

[Sectigo] C=PL, O=Unizeto Technologies S.A., OU=Certum Certification Authority, CN=Certum Trusted Network CA



Trusted until 2021 DigiCert/Symantec owned (in alphabetical order by brand)

C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA

C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA

C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Asurance EV Root CA

C=US, O=GeoTrust Inc., CN=GeoTrust Primary Certification Authority

C=US, O=GeoTrust Inc., OU=(c) 2008 GeoTrust Inc. - For authorized use only, CN=GeoTrust Primary Certification Authority - G3

C=DE, O=TC TrustCenter GmbH, OU=TC TrustCenter Class 2 CA, CN=TC TrustCenter Class 2 CA II

C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2008 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA - G3

C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5

C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority


There was also a list of 6 CAs trusted until 2016 (Baltimore, Equifax 1024 bit, GlobalSign, GTE CyberTrust and two Symantec roots).