<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 29, 2021 at 10:36 AM Rob Stradling 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 dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
> I don’t think the creation of another WG would be justified or useful</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Practically, that may well be the case, but I think it's right to arrive at that conclusion by going through this thought process rather than circumventing it.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
> I don’t see an issue with the CS WG defining requirements for timestamping as long as it’s very clear that this is ONLY for timestamping used with CodeSigning certificates so that is no violation of the scope of the WG.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Policing "ONLY for timestamping used with CodeSigning certificates" seems like it would be hard.  <span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">A timestamping server has no idea whether it's being asked
 to timestamp signed code or some other "datum" (to quote RFC3161).</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Sectigo's publicly-trusted RFC3161 timestamping service (and the timestamping certificates that it uses) is expected to be used in conjunction with both Code Signing and Document Signing.</div></div></blockquote><div><br></div><div>Indeed Rob, I think this gets to the heart of the concern.</div><div><br></div><div>If the CSC WG is expecting that CAs will stand up separate EVCS Timestamping services, exclusively to be used for code signing (which cannot be enforced by the TSA), from a separate hierarchy, then at least we should be clear about that.</div><div><br></div><div>The fundamental issue here is that the references to timestamping appear to be implementation/policy-specific to a particular implementor, rather than generalized regarding code signing. I appreciate the challenge here (code outliving the code signing certificate), and I can understand the rationale for wanting to address it, but it fundamentally feels like an attempt to scope an entirely unrelated service, which has no <i>*defined</i>* interaction, and which fundamentally is a matter of Relying Party policy.</div><div><br></div><div>It seems the CSC WG should define how the CS <i>certificates</i> work, and the broader question about how code signing is conveyed (e.g. PKCS#7/CMS, ZIP files, bespoke vendor format - all of which are practically deployed today), or how those <i>certificates</i> are authenticated after their useful lifetime, is really a question for root program policies, in the absence of industry norms. And there could be opportunity here for something. However, if the CSC WG is determined to have this scoped within its charter, which is still something highlighted previously as problematic, then it really is and must simply be scoped to CS, and that's fundamentally saying a new, separate trust hierarchy "should" be established.</div><div><br></div><div>We previously discussed, during the chartering of the S/MIME WG, exactly this issue (the need for a separate WG), due to the attempts to conflate S/MIME WG with document signing, since they both may choose to use legal identities in addition to or in lieu of technical identities (like an email address). This was the major blocker to getting the S/MIME charter approved, but we managed to eventually do so by making it clear document signing (and the related support services, including timestamping) are out of scope of S/MIME.</div></div></div>