[cabfpub] SHA-1 Collision Found

[Ryan Sleevi]

On Fri, Feb 24, 2017 at 11:50 AM, Peter Bowen <pzb at amzn.com> wrote:
>
> I don’t see why Browsers are blocked from adding support before CABF
> permits use or HSM vendors ship product.
>
> I think the correct dependencies are as follows:
>
> (1) IETF (or other standards org) publishes specification
> (2) HSM vendors ship product (depends on 1)
> (3) CABForum permits use (depends on 1 + may depend on 2, assuming HSM req
> needs to change)
> (4) Browsers add support (depends on 1)
> (5) Private CAs issue certificates (depends on 1)
> (6) Public CAs issue certificates (depends on 2 + 3)
> (7) Customers can use certificates (depends on 4 + (5 or 6))
>
> Why do you think browsers are blocked on anything other than #1?
>

The value of (4) depends on two things - the security analysis of the
algorithm itself (which is done in (1)), and the industry balancing of
risks (which is done in (3)).

In particular, we see and know that spaces like (1) tend to be maximally
permissive and descriptive, while leaving policy out of scope.
Alternatively, if something has a large set of parameters (e.g. RSA-PSS),
it's left to consumers to appropriately define the acceptable permutations
and acceptability (e.g. as the TLS WG has done with respect to RSA-PSS in
TLS 1.3)

The process of (4) is gated on ensuring that (1) is adequately specified
for the appropriate use, which is defined by (3), and which is influenced
by (2) - as you note, depending on the purpose and intent of the HSM policy.

For example, adding support for RSA-PSS as specified in (1), as part of
(4), doesn't consider the impact of the permutation of parameters, and that
(4) only desires to support (3), not everything permissible in (1). While I
can understand that private CAs in (5) may wish to take advantage of the
flexibility in (1), it's not an intrinsic property of browsers wanting to
support that (hence, as you note, (7) depends on (4)).

Since (4)'s implementation is defined by (3)'s discussions (and (2)'s
limitations, if part of (3)'s dependencies), I believe that (4) depends on
(3).

Otherwise, (4) ends up treating (1) like Postelmon; liberal in what you
accept, and gotta accept it all. That's not a desirable outcome for (4),
even if (5) may desire it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170224/84e0da13/attachment-0001.html>