[cabfpub] SHA1 Deprecation Ballot

Tue Mar 11 17:53:40 UTC 2014

Sounds good.  Thanks.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Erwann Abalea
Sent: Tuesday, March 11, 2014 11:18 AM
To: public at cabforum.org
Subject: Re: [cabfpub] SHA1 Deprecation Ballot

L=3072,N=256 is a possible choice for CAs, FIPS186-4 says that non CA SHOULD
NOT use it.
L=1024,N=160 isn't valid anymore for us (equivalent strength to a 1024 bits
RSA key, and offering only 2^80 resistance against signature).

I think the "modulus" and "divisor" rows should be merged again. L is the
length of the modulus p, N is the length of the divisor q of p-1, and all
possible tuples (L,N) are set by FIPS186. For example, L=3072,N=224 isn't
accepted by FIPS186.

-- 
Erwann ABALEA

Le 11/03/2014 17:46, Ben Wilson a écrit :

Thanks, Doug.  I’ll revise it and recirculate.  I looked up the NIST
standard for DSA and it similar to the following, which I think we should
use:

Allowed choices for the pair L and N , where each represents the bit lengths
of p and q, respectively: 

L = 1024, N = 160 

L = 2048, N = 224 

L = 2048, N = 256 

L = 3072, N = 256

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Doug Beattie
Sent: Tuesday, March 11, 2014 8:31 AM
To: ben at digicert.com; 'CABFPub'; 'Ryan Sleevi'
Subject: Re: [cabfpub] SHA1 Deprecation Ballot

Hi Ben,

I’m not sure this entirely captures the requirements for the deprecation of
SHA-1.  Here are my thoughts and suggestions:

While I agree with the requirement that Root and Subordinate CA Certificates
generated after 31 December 2015 should not be SHA-1, I don’t think this
accurately defines the 1 January 2017 “event”.  While all certs issued after
31 December 2015 should not be SHA-1, it implies that SHA-1 certificates
issued before this date will be valid until they expire.  Microsoft has
stated that on 1 January 2017 if any certificates in the chain up to, but
not including, the root (including cross certificates) are SHA-1, the
certificate validation will fail.  Isn’t this the point we want to make?
I’m not sure we need to state in the BR when SHA-1 certificates should no
longer be issued, or when they must expire, just when they won’t be
validated.  If some CAs want to dig a big hole by issuing lots of SHA-1
certificates that expire after 1 January 2017, that is their challenge to
resolve.

I attempted to document this in the attached for your consideration.   The
first page of the attachment summarizes the suggested changes while the next
2 are redlined changes for Appendix A, much like your attachment.

Doug

From: Ben Wilson [mailto:ben at digicert.com] 
Sent: Sunday, March 09, 2014 3:20 AM
To: 'CABFPub'; 'Ryan Sleevi'; Doug Beattie
Subject: RE: [cabfpub] SHA1 Deprecation Ballot

All,

Here is a draft of Ballot 118 – SHA1 Sunset.  

I’ve proposed language to replace the current footnote concerning SHA1 in
Appendix A, feel free to edit:

*   "Effective immediately CAs SHOULD begin migrating away from using the
SHA-1 hashing algorithm to sign Subscriber Certificates.  CAs SHOULD advise
Applicants that Microsoft has indicated that Windows will stop accepting
SHA1 certificates on 1 January 2017 or sooner if the algorithm becomes
vulnerable to cryptographic attack."  Alternatively, it could  be re-phrased
to say, “CAs may want to advise Applicants that 
”, but this draft has
“SHOULD”.

Also, if your look at table (1) Root CA Certificates, it still allows legacy
SHA1 Roots created before January 1, 2016, to serve as trust anchors.  The
language is Root Certificates “with a validity period beginning after 31
Dec. 2015”, which means that starting Jan. 1, 2016, CAs shouldn’t be
submitting new roots signed using SHA1, but I doubt that few CAs are still
submitting SHA1 signed roots, so I don’t think that is an issue that we need
to call out specially in the table below.  

Ben Wilson of DigiCert made the following motion, and ____ from _______ and
_________ from __________ endorsed it: 

Motion Begins

In order to bring CA practices in line with SHA1 deprecation plans for the
industry, Appendix A of the Baseline Requirements is amended effective
immediately as follows:

In each of the three tables in Appendix A, delete the middle column (because
it is applicable mostly for certificates valid through 2013, which have
expired anyway by now) and insert a new column on the right side of each of
the tables with a column heading that reads, 

"Validity period beginning after 31 Dec 2015".  

Add the following for the first and last column of each row in the following
tables:

(1)          Root CA Certificates

Digest algorithm - SHA-256, SHA-384 or SHA-512

Minimum RSA modulus size (bits) - 2048

ECC curve - NIST P-256, P-384, or P-521

Minimum DSA modulus and divisor size (bits) -  L= 2048, N= 224 or L= 2048,
N= 256, L= 2048, N= 224 or L= 2048, N= 256  

(2)          Subordinate CA Certificates

Digest algorithm - SHA-256, SHA-384 or SHA-512

Minimum RSA modulus size (bits) - 2048

ECC curve - NIST P-256, P-384, or P-521

Minimum DSA modulus and divisor size (bits) -  L= 2048, N= 224 or L= 2048,
N= 256, L= 2048, N= 224 or L= 2048, N= 256  

(3)          Subscriber Certificates

Digest algorithm - SHA-256, SHA-384 or SHA-512

Minimum RSA modulus size (bits) - 2048

ECC curve - NIST P-256, P-384, or P-521

Minimum DSA modulus and divisor size (bits) -  L= 2048, N= 224 or L= 2048,
N= 256, L= 2048, N= 224 or L= 2048, N= 256  

Replace the footnote "*" in Appendix A with the following:  "Effective
immediately CAs SHOULD begin migrating away from using the SHA-1 hashing
algorithm to sign Subscriber Certificates.  CAs SHOULD advise Applicants
that Microsoft has indicated that Windows will stop accepting SHA1
certificates on 1 January 2017 or sooner if the algorithm becomes vulnerable
to cryptographic attack."

Motion Ends

The review period for this ballot shall commence at 2200 UTC on Monday, 10
March 2014, and will close at 2200 UTC on Monday, 17 March 2014. Unless the
motion is withdrawn during the review period, the voting period will start
immediately thereafter and will close at 2200 UTC on Monday, 24 March 2014.
Votes must be cast by posting an on-list reply to this thread. 

A vote in favor of the motion must indicate a clear 'yes' in the response. A
vote against must indicate a clear 'no' in the response. A vote to abstain
must indicate a clear 'abstain' in the response. Unclear responses will not
be counted. The latest vote received from any representative of a voting
member before the close of the voting period will be counted. Voting members
are listed here:  https://cabforum.org/members/

In order for the motion to be adopted, two thirds or more of the votes cast
by members in the CA category and greater than 50% of the votes cast by
members in the browser category must be in favor. Also, at least six members
must participate in the ballot, either by voting in favor, voting against,
or abstaining

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Monday, March 03, 2014 11:05 AM
To: 'Ryan Sleevi'
Cc: 'CABFPub'
Subject: Re: [cabfpub] SHA1 Deprecation Ballot

Ryan,

I agree with your view.  I’m just trying to get the “what-ifs” out in the
open for discussion.  

Several times in the past the Forum has been criticized for not doing enough
to consider the whole ecosystem.  

I’m just giving everyone heads-up on a potential future issue.

Ben

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ryan Sleevi
Sent: Friday, February 28, 2014 1:57 PM
To: Ben Wilson
Cc: CABFPub
Subject: Re: [cabfpub] SHA1 Deprecation Ballot

Ben,

Why do you believe that Microsoft's review is the only way to discover
"Application X" and its existence? Why wouldn't we, within the CA/B Forum,
except either member CAs (or CAs affected by but not members) to mention
"Application X" exists?

Likewise, it seems reasonable to presume that "Application X" is not a
common scenario to begin with - otherwise, we expect CAs would already be
talking about "Application X" and its impact to their issuance practices.

As such, it seems like the scope of "Application X" is going to be so
minimal, that it would be entirely reasonable/preferable/better for the
Internet to let "We still issue SHA-1 for Application X" to be a qualified
finding during an Audit (presuming, of course, that such timelines are
incorporated within the audit framework in a timely manner), and then allow
Root Programs to make a decision about "Application X"?

I see no reason to hold up the entire progress based on a hypothetical
"Application X". And if such a blanket exception to security needs to be
carved out, Root Programs are perfectly capable of doing so - as they have
already done for other such "Application X" exceptional scenarios (eg:
RSA-1024 bit certs for certain applications - such as Symantec's issuance of
a pb.com certificate that conflicts with the BRs in
https://bugzilla.mozilla.org/show_bug.cgi?id=966350 )

On Thu, Feb 27, 2014 at 4:59 PM, Ben Wilson <ben at digicert.com> wrote:

Let’s say we adopt this as a guideline.  Then, what if we want to fine-tune
it based on Microsoft’s July 2015 review of progress made?  How can we amend
the guideline and put that amendment in place before January 1, 2016?
(Let’s say that based on Microsoft’s review, it appears that Application X
and its users need more time.  Won’t a CA that is providing SSL services for
Application X say that six months is not enough time for the CAB Forum to
adopt an exception and for it to change its code and certificate issuance
processes to allow an exception for Application X and its users)?  In other
words, don’t we need feedback from Microsoft prior to July 2015 in order to
put an amendment in place?   If we adopt this provision, won’t we need to
revisit it in about 12 months? 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Doug Beattie
Sent: Thursday, February 20, 2014 11:55 AM
To: ben at digicert.com; public at cabforum.org

Subject: Re: [cabfpub] SHA1 Deprecation Ballot

Ben,

While this may be obvious to most of us, we should explicitly state that all
CA certificates in the hierarchy up to, but not including the publicly
trusted root, must also not be SHA-1.

Doug

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Wednesday, February 19, 2014 3:02 PM
To: public at cabforum.org
Subject: [cabfpub] SHA1 Deprecation Ballot

I’m not sure whether I’ve captured it all, but here is a rough draft of a
possible ballot for the Baseline Requirements. 

Effective immediately CAs SHOULD begin migrating away from using the SHA-1
hashing algorithm to sign SSL/TLS and code signing certificates.   

Beginning January 1, 2016, CAs SHALL NOT use the SHA-1 hashing algorithm to
sign SSL/TLS or code signing certificates.

Please provide your comments, edits, etc., 

Thanks,

Ben

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

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