Re: Applicability of SHA-1 Policy to Timestamping CAs
On 25/03/2019 23:42, Wayne Thayer wrote: > 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-security-policy@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 > 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
Re: Applicability of SHA-1 Policy to Timestamping CAs
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-security-policy@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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
On 23/03/2019 02:03, Wayne Thayer wrote: > On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen wrote: > >> >> >> On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < >> dev-security-policy@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? >> > > 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. > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
On Fri, Mar 22, 2019 at 6:54 PM Peter Bowen wrote: > > > On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < > dev-security-policy@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? > 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
On Fri, Mar 22, 2019 at 11:51 AM Wayne Thayer via dev-security-policy < dev-security-policy@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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
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=a05o00iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 On Fri, Mar 22, 2019 at 4:43 PM Ryan Sleevi wrote: > > > On Fri, Mar 22, 2019 at 4:00 PM Andrew Ayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Fri, 22 Mar 2019 12:50:43 -0600 >> Wayne Thayer via dev-security-policy >> 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
On Fri, Mar 22, 2019 at 4:00 PM Andrew Ayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, 22 Mar 2019 12:50:43 -0600 > Wayne Thayer via dev-security-policy > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Applicability of SHA-1 Policy to Timestamping CAs
On Fri, 22 Mar 2019 12:50:43 -0600 Wayne Thayer via dev-security-policy 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Applicability of SHA-1 Policy to Timestamping CAs
GlobalSign concurs. -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, March 22, 2019 2:51 PM To: mozilla-dev-security-policy Subject: Applicability of SHA-1 Policy to Timestamping CAs 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 ___ 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
Applicability of SHA-1 Policy to Timestamping CAs
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
