[Cscwg-public] Code Signing Dedicated Root

Bruce Morton Bruce.Morton at entrust.com
Mon Apr 12 14:29:54 UTC 2021

Another action is that we should create a timestamping certificate policy OID to add to into the timestamping certificates, where the OID is referenced from the CSBRs. This would mean that any timestamping certificate with this OID would meet the requirements of the CSBRs.

If agreed, I suggest:  codesigning-requirements(4) timestamp(2) -  (Timestamp Certificate issued in compliance with the Code Signing Baseline Requirements)


From: Ian McMillan <ianmcm at microsoft.com>
Sent: Wednesday, March 17, 2021 4:10 PM
To: Bruce Morton <Bruce.Morton at entrust.com>; cscwg-public at cabforum.org
Subject: [EXTERNAL] RE: Code Signing Dedicated Root

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
Thank you Bruce!

This is a great subject to bring forward, and one that has been on my mind as well (especially after Ryan's presentation at the last F2F).


From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Bruce Morton via Cscwg-public
Sent: Wednesday, March 17, 2021 12:44 PM
To: cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Subject: [EXTERNAL] [Cscwg-public] Code Signing Dedicated Root

Based on the F2F discussion of dedicated PKI hierarchy for TLS and S/MIME, I think we should also discuss for Code Signing.

My understanding is that the direction is to have 1) one policy, 2) one (or more) dedicated hierarchies to support the policy, and 3) one audit.

The good news is the CSWG is ready going in the right direction. We have created one policy per the CSBRs which cover non-EV/EV code signing certificates and the associated time-stamping certificates. In addition, WebTrust has created one audit criteria, which would be able to cover dedicated roots, subordinates CAs and subscriber certificates

To address a dedicated hierarchy for Code Signing, a simple implementation would be:

  *   One RSA root (or ECC root) for non-EV codesigning, EV code signing and time-stamping subordinate CAs, and associated subscriber certificates
  *   The hierarchy is to support the policy associated with only the CSBRs only and would not by other requirements which would impact the CSBR policy
  *   Subscriber certificates would have the applicable CA/Browser Forum certificate policy OID to indicate they were issued iaw the CSBRs

I have thought about other requirements for a Time-stamping dedicated root and hierarchy. As Time-stamping only is out of scope for the CSWG, I think we can only address time-stamping as it applies to code signing certificates per the CSBRs. I also think that a single root to cover both code signing and time-stamping would make it easier for ubiquity and for end user validation of signatures.

Regarding testing of roots, the CSBRs refer to SSL BR Appendix C. This is an incorrect reference as the requirement is now in SSL BR 2.2, which states:
"The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired."
With a dedicated hierarchy which only issues code signing and time-stamping certificates, we cannot issue SSL certificates for Web pages. This only works now as we use multi-purpose roots. I think we should change this requirement or allow an option, where the CA must post on a test-site, signed/time-stamped code where the certificates were issued from Subordinate CAs which were issued from the Root being tested.

Since we are in the early phase of moving to 4096-bit RSA CAs for code signing, it would be great if we can agree as to what would be acceptable for dedicated hierarchy with the goal of getting this right from the beginning.

Thanks, Bruce.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210412/8546bf66/attachment.html>

More information about the Cscwg-public mailing list