Re: [cabfpub] [EXTERNAL] Re: [Cscwg-public] Code signing and Time stamping
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
Re: [cabfpub] [EXTERNAL] Re: [Cscwg-public] Code signing and Time stamping
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 On Behalf Of Ben Wilson
via Cscwg-public
Sent: Tuesday, April 20, 2021 12:09 PM
To: Dean Coclin ; CA/Browser Forum Public Discussion
List
Cc: cscwg-pub...@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
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
mailto:public@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/).
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
[cabfpub] Draft CA/Browser Forum agenda - Thursday, April 29, 2021 at 11:30 am Eastern Time
Here is the draft agenda for the subject call: CA/Browser Forum Agenda Time Start(ET) Stop Item Description Presenters 0:02 11:30 11:32 1. Roll Call Dean 0:01 11:32 11:33 2. Read Antitrust Statement 0:01 11:33 11:34 3. Review Agenda Dean 0:01 11:34 11:35 4. Approval of minutes of last call and March 15th call Dean/Karina 0:05 11:35 11:40 5. Forum Infrastructure Subcommittee update Jos 0:05 11:40 11:45 6. Code Signing Certificate Working Group update Bruce 0:05 11:45 11:50 7. S/MIME Certificate Working Group update Stephen 0:05 11:50 11:55 8. Open 0:04 11:55 11:59 9 Any Other Business 0:01 11:59 12:00 10. Next call: May 13th Adjourn; F2F Meeting Schedule: * 2021: June 15-17- Virtual, October- Tentative-Minneapolis (OATI) * 2022: Mar-April - TBD, June - TBD, Sept - Berlin smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://lists.cabforum.org/mailman/listinfo/public
