[cabfpub] FW: Ballot - expiration of SHA1 certificates

Doug Beattie doug.beattie at globalsign.com
Mon Sep 8 15:08:44 UTC 2014

Hi Tom,


GlobalSign cannot support this draft ballot as written.

1)      The location of these new requirements (under validity period) are
mis-placed and incomplete.  This should be a new section (9.8?) where the
subject can be addressed clearly and any exceptions to the policy clearly
listed.  This section should describes the deprecation of SHA-1 and list all
the locations where SHA-1 can or cannot be used:

a.      SHA-1 MUST NOT be used as the certificate, CRL(?) and OCSP(?)
signature hash algorithm

b.      This section should also clearly call out other places where SHA-1
is used today and where it may continue to be used (OCSP responses, CRLs,
SKI, Auth Key ID, etc)

c.      This section must call out dates when SHA-1 must be depreciated for
OCSP, CRLs and the other uses not covered by a) above.

2)      The 1 November date (8 weeks) is too soon for this change as stated

a.      CAs have taken different approaches to meeting the 1 January 2017
date based on the MS Root policy.  Not all CAs are in a position to change
agreements with their customers and limit SHA-1 certificate issuance to
1-year by 1 January 2015 (or to 2-years by 1 November 2014, then change
again starting in 2015)

b.      CAs have customers with Subordinate CAs signed by their roots with
SHA-1 signatures and are actively issuing SHA-1 SSL certificates.  While I'm
sure many have been transitioned to SHA-256 subordinate CAs, not all have
been migrated yet and that will take a while to implement.  The MS Root
policy allows them to use these CAs for 2 more years, but a BR mandates a
system wide change on the effective date.  This can't be supported in a
matter of weeks.

3)      If the list of 5 "Exceptions" listed as a) - e) is meant to apply to
both long validity period certificates and those with SHA-1, then they need
to be refined and updated specifically for SHA-1 or this change will be
ineffective (too many loopholes).


I suggest the following approach:

-        Move this to a new section: 9.8

-        More clearly stating where this change is mandated (and where it is

-        Create a new well defined set of exceptions for the use of SHA-1

-        Clearly identify the dates and changes needed for Subordinate CAs
and what is permitted and what is not

-        Define the dates (perhaps different dates) for the conversion from
SHA-1 to SHA-2 for CRLs, OCSP services and any/all other uses of SHA-1 that
are being contemplated

-        Change the Effective Date from 1 November 2014 to "3 months from
the approval of the ballot"

-        Allow certificates issued prior to the effective date to be
re-issued as SHA-1 certificates






From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Tom Albertson
Sent: Friday, September 5, 2014 6:47 PM
To: public at cabforum.org
Subject: [cabfpub] FW: Ballot - expiration of SHA1 certificates


Hi there,


I have produced a ballot for discussion, which aligns the Baseline
Requirements (v1.1.9)  with the planned deprecation of SHA-1.   This ballot
uses the dates in the Microsoft SHA-1 deprecation policy
spx>  as a reference, and right now only addresses SSL certs.  I think we
can offer similar language for code signing certs and possibly other BRs
once we have hashed this out for SSL.


New text appears as red underlined.   A small amount of text in Appendix A
is proposed for deletion (black strikethrough)  The amendments relate mainly
to Section 9.4 Validity Period, with minor conforming changes to Appendix A.


Special thanks to Ben and Gerv and others, who already struggled through
this issue in March 2014, that ballot discussion was most instructive.  I
have made no efforts to collaborate with other Forum members on this issue
except to go back and forth with Kelvin and Aaron here at Microsoft on the
best text to offer to represent the Microsoft policy.  


Your comments and questions are appreciated, and ultimately we could use an
endorser or two of the ballot measure.  





Ballot NNN -expirations of SHA1 certificates (FINAL VERSION)



9.4 Validity Period


9.4.1 Subscriber Certificates

Subscriber Certificates issued after the Effective Date MUST have a Validity
Period no greater than 60 months.


Except as provided for below, Subscriber Certificates issued after 1 April
2015 MUST have a Validity Period no

greater than 39 months.


Effective 1 November 2014, CAs MUST NOT issue Subscriber Certificates
utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January


Except as provided for below, effective 1 January 2016, CAs MUST NOT issue
Subscriber Certificates that utilize the SHA-1 algorithm. 


Effective 1 April 2015, CAs MAY continue to issue Subscriber Certificates
with a Validity Period greater than 39

months but not greater than 60 months provided that the CA documents that
the Certificate is for a system or

software that:

(a) was in use prior to the Effective Date;

(b) is currently in use by either the Applicant or a substantial number of
Relying Parties;

(c) fails to operate if the Validity Period is shorter than 60 months;

(d) does not contain known security risks to Relying Parties; and

(e) is difficult to patch or replace without substantial economic outlay.



9.4.2 Root CA Certificates


The SHA-1 deprecation policy and Validity Dates DO NOT apply to Root CA
certificates.  CAs MAY continue to use their existing SHA-1 Root
Certificates.  CAs MUST use SHA-2 or successor hash algorithms to sign any
Subscriber certificates, Subordinate CA certificates, and CRLs effective 1
January 2016.



9.4.3 Subordinate CA Certificates


Effective 1 January 2016, CAs MUST NOT issue Subordinate CA Certificates
that utilize the SHA-1 algorithm.  CAs MUST NOT issue SHA-2 Subscriber
certificates under SHA-1 Subordinate CA Certificates.  



Appendix A - Cryptographic Algorithm and Key Requirements (Normative)



Add this note under Table 2, Subordinate CA certificates:


* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in
Section 9.4.3.


And amend this note at the end of the 3 tables.  


* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in
Section 9.4.1  until SHA-256 is supported widely by browsers used by a

portion of relying-parties worldwide.                              


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140908/62f945f7/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5615 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140908/62f945f7/attachment-0001.p7s>

More information about the Public mailing list