<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 18, 2015 at 5:21 PM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">Hi everyone, <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Attached is a proposal from Cloudflare and Facebook creating LV certificates in the baseline requirements. This is a draft ballot for review that will, of course, change based on the debate in the forum. Although CAs will stop issuing
SHA-1 on 2016/1/1, there isn’t any reason these changes couldn’t go into effect in early January (assuming a passing vote).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If adopted, this ballot would permit continued use of SHA1 certificates past the deprecation deadline (to support older devices) but give newer browsers an easy way to reject SHA1 for users. The ballot also increases the resiliency of
SHA1 certs against attacks by requiring higher entropy serial numbers.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I look forward to your comments.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Jeremy</p></div></div></blockquote><div><br></div>I'm going to split my initial response into two emails. This one includes some specific questions about the ballot language and areas where it seems inadequate or could be improved.<div><br><div><div><br></div><div>> Such Certificates MUST NOT have Expiry Dates greater than 31 March 2019.</div><div><br></div><div>Is it accurate to state that the proposers believe that March 31, 2019 is a practical hard SHA-1 cutoff date for the affected regions described in the preamble? Or is this just a reflection of the 39 month limit on certificate lifetimes used elsewhere in the BRs?</div><div><br></div><div><br></div><div>> CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm except to Applicants requesting Legacy Validated Certificates</div><div><br></div><div>This proposal looks to explicitly define Legacy Validated certificates as only allowing the use of SHA-1. Do the proposers view Legacy Validated certificates as a long-term solution to deprecating weak algorithms? </div><div><br></div><div>If so, we should discuss the long-term impact of Legacy Validated certificates now, and the ballot language should explicitly address this. If not, then the ballot is better off simply modifying SHA-1 language and deadline, rather than creating a new certificate class.</div><div><br></div><div><br></div><div>> {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate- policies(1) baseline-requirements(2) legacy-validated(99)} (2.23.140.1.2.99), if the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with Section 3.2.2.1.</div><div><br></div><div>To be clear for those reading this discussion which are familiar with the DV/OV/EV nomenclature, but not policy identifiers: is it correct to describe these changes as meaning that LV certificates would require at least OV-level validation?</div><div><br></div><div><br></div><div>> Termination of Use of LV Certificates: An obligation and warranty to promptly cease all use of Legacy Validated Certificates when the CA/Browser Forum is notified that a reproducible method for forcing applications from major Application Software Suppliers is discovered that (a) causes said applications to accept and validate LV Certificates that the applications should otherwise have rejected due to their explicit SHA-1 rejection logic and (b) cannot be resolved by technical changes made either by the Application Software Suppliers or the Subscriber;</div><div><br></div><div>This section mandates that Subscribers stop using LV certificates if any sort of unexpected downgrade attacks become possible that cannot be resolved by updating browsers or web applications. </div><div><br></div><div>However, since CAs are already required elsewhere in the ballot to chain all LV certificates to a subordinate CA exclusively created for LV use, there should be an equivalent requirement on CAs to immediately revoke that subordinate CA, and any certificates issued from them.</div><div><br></div><div>Additionally, the use of "major" before "Application Software Suppliers" is subjective, and this word doesn't appear anywhere else in the Baseline Requirements. This section should remove "major", and rely on the same (implicit, sadly) definition of Application Software Suppliers used elsewhere in the document.</div></div><div><br></div><div><br></div><div><div>> Use of LV Certificates: An obligation and warranty to serve Legacy Validated</div><div>Certificates only ... (b) to Relying Parties whom the Subscriber</div><div>reasonably believes may not be able to utilize Certificates signed using more</div><div>modern digests, such as SHA-2;</div><div><br></div><div>This level of flexibility and trust given to Subscribers seems inappropriate for publicly trusted certificates, and inconsistent with the level of detail and scrutiny -- including third-party audits -- that the Baseline Requirements applies to certificate authorities.</div></div><div><br></div><div>It's essentially a handshake agreement between Subscribers and CAs they have a close relationship with, that (I guess) is meant to ensure that the open source code Subscribers show to the public are what is implemented in production.</div><div><br></div><div>Though CAs are given some latitude at verifying a Subscriber's identity, there's still a great deal of detail on acceptable and encouraged methods of verifying that identity. That level of detail is lacking in this ballot as proposed.</div><div><br></div></div><div>-- Eric</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</div></div>