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

Mon Apr 26 17:22:19 UTC 2021

To make sure I follow the logic here:

EVCS states:

> "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."

The EVCS then further states, within Section 9.4:

"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.
> 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."

And then finally, in Section 16:

> (1) An EV Timestamp Authority MUST protect its Private Key in a crypto
> module validated in accordance with FIPS 140-2 Level 2.
> (2) An EV Timestamp Authority MUST be synchronized with a UTC(k) time
> source recognized by the International Bureau of Weights and Measures
> (BIPM).

Separately, in the CS 1.0 draft (
https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf
), it's scope is defined as:

> "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"

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).

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.

Within the charter of the WG (***emphasis added***)
"The authorized scope of the CSCWG SHALL be to discuss, adopt, and maintain
policies, frameworks, and sets of standards ***related to the issuance and
management of code signing certificates*** by third-party Certificate
Issuers under a publicly trusted root (and not code signing certificates
issued under a private root CA), limited as follows"

My question to the proponents is thus this:
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)?

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.

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.

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".

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.

On Mon, Apr 26, 2021 at 9:18 AM Bruce Morton via Public <public at cabforum.org>
wrote:

> To follow up, the CSCWG charter includes the following documents:
>
> a. EV Code Signing Guidelines, v. 1.4 and subsequent versions
>
> 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)
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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:
>
> {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)
>
>
>
>
>
> Bruce.
>
>
>
>
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of *Ben
> Wilson via Cscwg-public
> *Sent:* Tuesday, April 20, 2021 12:09 PM
> *To:* Dean Coclin <dean.coclin at digicert.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *Cc:* cscwg-public at cabforum.org
> *Subject:* [EXTERNAL] Re: [Cscwg-public] [cabfpub] Code signing and Time
> stamping
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
> 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.
>
>
>
> 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.
>
>
>
> The Scope in the Charter does not expressly include or exclude the
> assignment of a time stamping OID for time stamping certificates.
>
>
> https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/#1-Scope
> <https://urldefense.com/v3/__https:/cabforum.org/2019/03/26/code-signing-certificate-wg-charter/*1-Scope__;Iw!!FJ-Y8qCqXTj2!KO_2DRjCLlG3XphTaFOKt3DIbyewuzdXb3w04DZftMjNQ74YZEHuLmO13bB-Y764wXA$>
>
>
>
> 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?
>
>
>
> Ben
>
>
>
>
>
>
>
> On Mon, Apr 19, 2021 at 2:31 PM Dean Coclin via Public <
> public at cabforum.org> wrote:
>
> 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 (
> https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/
> <https://urldefense.com/v3/__https:/cabforum.org/2019/03/26/code-signing-certificate-wg-charter/__;!!FJ-Y8qCqXTj2!KO_2DRjCLlG3XphTaFOKt3DIbyewuzdXb3w04DZftMjNQ74YZEHuLmO13bB-wNVdJJQ$>).
>
>
>
>
> 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.
>
>
>
> The working group has not had a chance to discuss this since the Forum
> meeting but plans to do so on the next call.
>
>
>
> 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.
>
>
>
> Dean
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
> <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/public__;!!FJ-Y8qCqXTj2!KO_2DRjCLlG3XphTaFOKt3DIbyewuzdXb3w04DZftMjNQ74YZEHuLmO13bB-PBR_9ZU$>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20210426/c824bc54/attachment-0001.html>