<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 11:50 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I don’t see why Browsers are blocked from adding support before CABF permits use or HSM vendors ship product.</div><div><br></div><div>I think the correct dependencies are as follows:</div><div><br></div><div>(1) IETF (or other standards org) publishes specification</div><div>(2) HSM vendors ship product (depends on 1)</div><div>(3) CABForum permits use (depends on 1 + may depend on 2, assuming HSM req needs to change)</div><div>(4) Browsers add support (depends on 1)</div><div>(5) Private CAs issue certificates (depends on 1)</div><div>(6) Public CAs issue certificates (depends on 2 + 3)</div><div>(7) Customers can use certificates (depends on 4 + (5 or 6))</div><div><br></div><div>Why do you think browsers are blocked on anything other than #1?</div></div></blockquote><div><br></div><div>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)).</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>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)).</div><div><br></div><div>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).</div><div><br></div><div>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.</div></div></div></div>