<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 11, 2016 at 5:39 AM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Ryan – have you heard back from the team on this? I’d like to keep this discussion going. </span></p></div></div></blockquote><div><br></div><div>I can't guarantee that there will be any feedback, nor should we gate it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Is this an accurate summary of where we are?</span></p></div></div></blockquote><div><br></div><div>I don't believe so. You seem to have introduced several new requirements, and also omitted several others - such as the previously discussed public-discussion and set of questions. As expressed previously, this is for us something that is mandatory to even consider such issuance.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Allow the cloning of an existing SHA-1 or SHA-2 signed SSL certificate (the Target Certificate) for the purposes of generating a SHA-1 signed certificate (the
Cloned Certificate) as of the effective date of this agreement (ballot or some other agreement we can all point to?) and continuing until December 31, 2016 where:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- The Target Certificate must be posted to at least one Google and one non-Google CT log prior to May 31, 2016.</span></p></div></div></blockquote><div><br></div><div>You've seemingly introduced this as a new requirements. As I've expressed multiple times in the Forum, I think it would be fairly inappropriate to mandate, via the CA/Browser Forum, any dependency on Google infrastructure, much like it would likely be inappropriate to mandate any dependency on Microsoft, Apple, Mozilla, Opera, or Qihoo360.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- The issuing CA must announce their intent to clone a certificate by posting a link (using crt.sh) on the Public list of each Target Certificate that they intend
to clone.</span></p></div></div></blockquote><div><br></div><div>This omitted several steps from past discussion.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- The CA must perform an OV level vetting and issue the certificate from a SHA-1 OV CA.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- The Cloned Certificate must be posted at least one Google and one non-Google CT log after issuance.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- The issuing CA must complete the disclosure and cloning process by sending links of the Target Certificate and Cloned Certificate to the Public list.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- The CA must keep a record of the certificates issued via this process for their auditors along with sufficient proof they followed this process, otherwise these
would be considered mis-issued certificates.</span></p></div></div></blockquote><div><br></div><div>This also omits the previous discussion of all such audits becoming qualified audits.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The following fields in the Cloned Certificate must be identical to the Target Certificate<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Public Key<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Subject DN<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Certificate version (of course)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- SKI (if SKI is present in the Cloned Certificate)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The following will have values identical with the CAs standard policy for the type of SSL certificate being issued:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- AIA<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- CDP<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- CP<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- EKU<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- KU<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- BC<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Issuer DN</span></p></div></div></blockquote><div><br></div><div>This isn't the same as what was discussed previously, and introduces new attack surface via unspecified extensions.</div><div><br></div><div>And while this was floated as an option, I'm not sure it's necessarily an appealing one, because of this. The unease caused by this, and opportunity for abuse, perhaps should mandate that you simply must use the pre-existing certificate, and if unavailable, that the issuance of SHA-1 may not be available. This is objective and vendor-neutral, but it does mean that some CAs may not be able to offer such services, just as some CAs may not offer EV certificates.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The following will be present but the values will be different:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- NotBefore: must be the current date/time and NotAfter where
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- NotAfter: must be no later than 12/31/2016<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Serial number with at least 20 bits of entropy<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- AKI<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Not to sidetrack the above process, but I’m still a bit concerned about how we handle those customers who don’t realize they have an issue until after May 31,
2016. Would it be possible to require the CA to generate the key pair in these cases under auditable circumstances with the relevant disclosure to the public list?</span></p></div></blockquote><div><br></div><div>Unfortunately, I think this gets to the heart of why such discussions about SHA-1 extensions are problematic - because now you're exploring ways to indefinitely issue them, which directly undermines the ability of the CA/Browser Forum to set any reasonable policies in the future, or sunset anything on an effective timetable. At some point, enough is enough - and if you didn't realize by Jan 1, 2016 - despite years of warning - and didn't realize by May 31, 2016 - despite half a year of effort - I don't believe it's reasonable to expect or accept you're being a responsible participant in the Web PKI. </div></div></div></div>