[cabfpub] SHA1 Deprecation Ballot

Tue Mar 11 17:18:25 UTC 2014

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> 
> [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> 
> [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 <http://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 
> <mailto: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> 
> [mailto: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 <mailto:ben at digicert.com>; public at cabforum.org 
> <mailto: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> 
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Ben Wilson
> *Sent:* Wednesday, February 19, 2014 3:02 PM
> *To:* public at cabforum.org <mailto: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 <mailto: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/7ef86231/attachment-0003.html>