[cabfpub] SHA1 Deprecation Ballot

Ryan Sleevi sleevi at google.com
Tue Mar 11 15:45:06 MST 2014


I'm not sure I understand why "Cross Certificates"

Cross certificates are, by definition, Subordinate CA certificates.

Seems like we might accomplish that with a clearer definition, otherwise I
fear that it's specific inclusion here will be seen as an exemption from
other requirements placed on "Subordinate CA certificates"


On Tue, Mar 11, 2014 at 2:54 PM, Ben Wilson <ben at digicert.com> wrote:

> What about this?
>
>
>
> *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 <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<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<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<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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140311/e71cd642/attachment-0001.html 


More information about the Public mailing list