<div dir="ltr"><div dir="ltr">To make sure I follow the logic here:</div><div dir="ltr"><br></div><div>EVCS states:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"These Guidelines describe the minimum requirements that apply to the issuance of Extended Validation Code Signing Certificates and EV signatures. Certification Authority, Timestamp Authority and Signing Authority are all governed by these Guidelines. The Timestamp Authority and the Signing Authority are optional components of the environment."</blockquote><div><br></div><div>The EVCS then further states, within Section 9.4:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Timestamp Authorities and Signing Authorities may obtain an EV Timestamp Certificate or EV Code Signing Certificate (respectively) with a validity period not exceeding one hundred and thirty five months. The validity period for an EV Code Signing Certificate issued to a Subscriber MUST NOT exceed thirty-nine months.<br>The validity period for an EV Code Signing Certificate issued to a Signing Authority that fully complies with these Guidelines MUST NOT exceed one hundred and thirty five months. The validity period for an EV Timestamp Certificate issued to a Timestamp Authority that fully complies with these Guidelines MUST NOT exceed one hundred and thirty five months."</blockquote><div><br></div><div>And then finally, in Section 16:</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(1) An EV Timestamp Authority MUST protect its Private Key in a crypto module validated in accordance with FIPS 140-2 Level 2.<br>(2) An EV Timestamp Authority MUST be synchronized with a UTC(k) time source recognized by the International Bureau of Weights and Measures (BIPM). </blockquote><div><br></div><div>Separately, in the CS 1.0 draft ( <a href="https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf">https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf</a> ), it's scope is defined as:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"The scope of these Requirements includes all “Code Signing Certificates”, as defined below, and associated Timestamp Authorities, and all Certification Authorities technically capable of issuing Code Signing Certificates, including any Root CA that is publicly trusted for code signing and all other CAs that might serve to complete the validation path to such Root CA"</blockquote><div><br></div><div>Section 9.4, similar to EVCS, places a requirement on validity, but also on the private key usage period and strength (by reference to Appendix A).</div><div><br></div><div>Section 13.2.1 places requirements that the CA needs to maintain revocation information for the Timestamp Certificate for 10 years past expiration, and must provide notice to Application Software Suppliers of at least 90 days if they intend to YOLO it and start ignoring requirements.</div><div><br></div><div><br></div><div>Within the charter of the WG (**<b>emphasis added</b>**)</div><div>"The authorized scope of the CSCWG SHALL be to discuss, adopt, and maintain policies, frameworks, and sets of standards **<b>related to the issuance and management of code signing certificates</b>** by third-party Certificate Issuers under a publicly trusted root (and not code signing certificates issued under a private root CA), limited as follows"</div><div><br></div><div>My question to the proponents is thus this:</div><div>Do you believe the existing language (both charter and documents) allows the arbitrary addressing of Timestamping Authorities, or does it specifically pertain to Timestamping Authorities used to provide timestamps for codesigning (which neither of the documents actually details how such timestamp tokens or certificates are included, presumably to be left up to code signing implementers)?</div><div><br></div><div>It would seem that those arguing that TSAs are in-scope are suggesting that Timestamping is part of "the policies, frameworks, and set of standards" related to code signing certificates, even though no part of either draft actually details how such certificates are consumed. My minimal hope is that there's agreement that the CSWG is not chartered to tackle Timestamping in general - i.e. a Timestamp Baseline Requirements - and is only narrowly chartered to the extent such information pertains to code signing certificates (if the argument that it's related is accepted). Yet it also seems to ignore the limits further placed within the charter (i.e. points c - j of the charter), suggesting those are not restrictions on those documents but rather additions to the scope.</div><div><br></div><div>Part of the reason of the concern is simple: If we accept and acknowledge this interpretation as valid, what would prevent the CSCWG from saying "Oh, hey, submissions to the Signing Authority need to be secured via TLS", and then arguing that because TLS is used as part of generating code signatures, TLS profiles are in scope for the CSC WG. You might say that sounds extreme, but I hope you can see why it's concerning that a dependent service is being seen as in-scope of a charter limited to a particular type of certificate.</div><div><br></div><div>It's the same reason to feel uncomfortable about trying to, say, redefine a "code signing certificate" to include a TSA by saying "Well, when you think about it, a TSA is really signing a hash of code that already has a signature, so a TSA is in a way a code signing certificate as well, so it's in scope", because that logic could also say "Well, code is delivered via TLS, and the certificate is used to sign the TLS handshake transcript, so in a way, a TLS certificate is a code signing certificate".</div><div><br></div><div>While we're sympathetic to understand the role that timestamping can play within code signing, particularly with respect to validation and the operation of revocation services, we're interested in finding a workable path forward here, but we want to make sure we've got a clear understanding of the scope that participants have agreed upon, to ensure we don't create a situation that is going to further creep in scope.</div><div><br></div><div> <br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 26, 2021 at 9:18 AM Bruce Morton via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_5332514650823276160WordSection1">
<p class="MsoNormal">To follow up, the CSCWG charter includes the following documents:<u></u><u></u></p>
<p class="MsoNormal">a. EV Code Signing Guidelines, v. 1.4 and subsequent versions<u></u><u></u></p>
<p class="MsoNormal">b. Version 1.0 Draft of November 19, 2015, Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates (subject to the CSCWG making a written finding that the provenance of such document is sufficiently
covered by the Forum’s IPR Policy)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The documents define requirements or reference: timestamp authority (TSA), timestamps, timestamp implementation method, timestamp certificate, timestamp signed objects, TSA logging, and timestamp key protection. The documents also define
the certificate profiles for timestamp root, timestamp subordinate CA and timestamp authority. As such, the CSCWG has considered it is in scope to manage these documents and the requirements associated to allow timestamp signatures with code signed using certificates
conforming to the CSBRs.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The CSBRs also state, “CAs complying with these Requirements MAY also assert the reserved policy OIDs in such Certificates.” The reserved policy OIDs reference those required for Non-EV and EV code signing certificates. The CSBRs do not
reference an OID for a timestamp certificate, since the OID has not been reserved. It is also considered appropriate to use all applicable reserved certificate policy OIDs as we consider deploying dedicated PKI hierarchies to support code signing.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As such, the CSCWG plans to add the following reserved certificate policy OID to the CSBRs, which may be included in a timestamp certificate, which meets the requirements of the CSBRs:<u></u><u></u></p>
<p class="MsoNormal">{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) code-signing-requirements(4) timestamping(2)} (2.23.140.1.4.2)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Bruce.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org" target="_blank">cscwg-public-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Ben Wilson via Cscwg-public<br>
<b>Sent:</b> Tuesday, April 20, 2021 12:09 PM<br>
<b>To:</b> Dean Coclin <<a href="mailto:dean.coclin@digicert.com" target="_blank">dean.coclin@digicert.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
<b>Cc:</b> <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [Cscwg-public] [cabfpub] Code signing and Time stamping<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<u></u><u></u></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<div>
<div>
<p class="MsoNormal">Just a few thoughts to move this conversation forward, and speaking as a CSCWG interested party and not to advocate any position of Mozilla, I think the answer depends on how strict or flexible the CABF wants to be as an organization when
it comes to interpreting the scope of a working group charter.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It seems that the mention of time stamping in a code signing work product would be allowed even under a strict interpretation. While creating standards for issuing and managing time stamping certificates would certainly be out of scope
with a flexible interpretation. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The Scope in the Charter does not expressly include or exclude the assignment of a time stamping OID for time stamping certificates.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://urldefense.com/v3/__https:/cabforum.org/2019/03/26/code-signing-certificate-wg-charter/*1-Scope__;Iw!!FJ-Y8qCqXTj2!KO_2DRjCLlG3XphTaFOKt3DIbyewuzdXb3w04DZftMjNQ74YZEHuLmO13bB-Y764wXA$" target="_blank">https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/#1-Scope</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Included in the scope is "Version 1.0 Draft of November 19, 2015, Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates (subject to the CSCWG making a written finding that the provenance of
such document is sufficiently covered by the Forum’s IPR Policy)." Time stamping was discussed in that draft, and I recall that the CSCWG did make the required written finding of provenance. Is the assignment of a timestamping OID a logical outcome of the
continued work on that earlier document?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Ben<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Apr 19, 2021 at 2:31 PM Dean Coclin via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">A discussion on last week’s CA/B call about code signing and time stamping brought up a question as to whether the latter was in scope of the CSCWG charter (<a href="https://urldefense.com/v3/__https:/cabforum.org/2019/03/26/code-signing-certificate-wg-charter/__;!!FJ-Y8qCqXTj2!KO_2DRjCLlG3XphTaFOKt3DIbyewuzdXb3w04DZftMjNQ74YZEHuLmO13bB-wNVdJJQ$" target="_blank">https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/</a>).
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Bruce said there was no CP OID for time stamping and that the group wanted to create one IAW with the CA/B Forum registry. Ryan was concerned that this was outside the CSCWG charter
as it was not specifically mentioned therein. Dimitris commented that it was included in charter scope 1a which pulls in the EV CS guidelines where time stamping is specified. Ryan did not seem convinced and asked that the discussion continue on the list.
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The working group has not had a chance to discuss this since the Forum meeting but plans to do so on the next call.
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I’ve included the CS Public list on this thread since the topic is of interest to members/observers there. If a respondent does not have posting rights, I can re-post for them.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Dean<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/public__;!!FJ-Y8qCqXTj2!KO_2DRjCLlG3XphTaFOKt3DIbyewuzdXb3w04DZftMjNQ74YZEHuLmO13bB-PBR_9ZU$" target="_blank">https://lists.cabforum.org/mailman/listinfo/public</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/public</a><br>
</blockquote></div></div></div></div>