[cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping

[Ryan Sleevi]

On Thu, Apr 29, 2021 at 10:36 AM Rob Stradling via Public <
public at cabforum.org> wrote:

> > I don’t think the creation of another WG would be justified or useful
>
> 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.
>
> > 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.
>
> Policing "ONLY for timestamping used with CodeSigning certificates" seems
> like it would be hard.  A timestamping server has no idea whether it's
> being asked to timestamp signed code or some other "datum" (to quote
> RFC3161).
>
> 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.
>

Indeed Rob, I think this gets to the heart of the concern.

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.

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 **defined** interaction,
and which fundamentally is a matter of Relying Party policy.

It seems the CSC WG should define how the CS *certificates* 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 *certificates* 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20210429/5ab95a00/attachment.html>