<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 29, 2018 at 5:05 PM Bruce Morton via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-CA" link="#0563C1" vlink="#954F72">
<div class="m_8967584858131063998WordSection1">
<p class="MsoNormal"><span style="color:#1f497d">Hi Ben,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">I thought that I would provide some input on Code Signing and hopefully it will be considered for the charter.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">The public CAs are currently working with two orphaned code signing certificate guidelines. Here are some issues:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="m_8967584858131063998MsoListParagraph"><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Documents are be out of date as such software suppliers, CAs, subscribers and relying parties are not benefiting from lessons learned or ecosystem updates<u></u><u></u></span></p>
<p class="m_8967584858131063998MsoListParagraph"><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Clients of software suppliers may be at higher risk than necessary<u></u><u></u></span></p>
<p class="m_8967584858131063998MsoListParagraph"><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Subscribers of code signing certificates are required to meet dated specifications which may be costly<u></u><u></u></span></p>
<p class="m_8967584858131063998MsoListParagraph"><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Cloud provision of subscriber HSM has not been addressed<u></u><u></u></span></p>
<p class="m_8967584858131063998MsoListParagraph"><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">The two documents specify different requirements to address the same problem<u></u><u></u></span></p>
<p class="m_8967584858131063998MsoListParagraph"><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">CAs that issue both OV and EV code signing certificates must manage two sets of controls<u></u><u></u></span></p>
<p class="m_8967584858131063998MsoListParagraph"><u></u><span style="font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">CAs that issue both OV and EV will have to undergo two different audits in 2019<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">It would be great if an outcome of the Working Group is one document for code signing certificates. I think that the one document can address both the EV and OV code signing certificate
types, especially since many of the requirements are just references to the Baseline Requirements or EV SSL Guidelines.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">I would also consider creating a Time-stamp certificate document. The advantage is that we could set a standard for time-stamp certificate and time-stamp authorities to support code
signing, document signing, etc.</span></p></div></div></blockquote><div><br></div><div>I would suggest that this be out of scope of Code Signing - there are significant differences, there exist industry standards already (within the IETF and within ETSI), and these have different purposes: timestamping extends beyond code-signing, as you note.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-CA" link="#0563C1" vlink="#954F72"><div class="m_8967584858131063998WordSection1">
<p class="MsoNormal"><span style="color:#1f497d">I would be interested in helping out with the Code Signing Working Group charter drafting.</span></p></div></div></blockquote><div><br></div><div>As noted, Google is very concerned that, given the confusion the market shares around what the CA/Browser Forum is and is not, a code signing WG may be seen as either impacting non-third-party mediated code signing, or somehow encouraging third-party mediated code-signing as being an improvement over first-party mediated code-signing, which it is not.</div><div><br></div><div>In this regard, and as discussed during the Shanghai F2F, ensuring that the scope of any charter makes it very clear that the scope of activities, and work product, are specifically limited to those software suppliers that engage with third-party CAs to perform identity validation and assessment, and to explicitly exclude from the scope, goals, and activities the broader discussion of code-signing, including that of first-party mediated code-signing.</div></div></div>