[cabfpub] SHA1 Deprecation Ballot

[Ryan Sleevi]

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: <http://lists.cabforum.org/pipermail/public/attachments/20140228/94048fd4/attachment-0003.html>