[Cscwg-public] Code Signing BRs Subscriber Private Key Protection (16.3)

Dean Coclin dean.coclin at digicert.com
Sat Oct 26 14:59:50 MST 2019

Your item 3 was specifically requested by Microsoft early on. There were
many that felt as you do per your suggestion but Microsoft felt it was too
high a bar for most developers. We should certainly revisit that now and
discuss, perhaps at the F2F meeting.

-----Original Message-----
From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Tomas
Gustavsson via Cscwg-public
Sent: Friday, October 25, 2019 6:57 AM
To: cscwg-public at cabforum.org
Subject: [Cscwg-public] Code Signing BRs Subscriber Private Key Protection


Sorry for not being able to attend the latest meetings.

Section 16.3 in our newly adopted BRs have been brought to my attention.
"Subscriber Private Key Protection"

So I wanted to throw it into the discussion forum, to be put on the list of
technical items for BR updates (I can't find that list on the wiki btw, is
it stored somewhere central?).

There are a few items in this section that I think needs oversight.

The section describes three ways a code signing key can be held.
Nr 1 specifies the use of "a TPM key attestation." is a TPM is used. The
definition of Trusted Platform Module in the beginning of the document is
very generic and fits may description. "a TPM Key attestation" is not
defined at all.
Assuming it actually refers to method described in this microsoft doc:

If we have a MUST of key attestation don't we need to define it?
Preferably it should reference the relevant Trusted Computing Group

We see a fear from consumers that key attestation will also be asked by CAs
when an HSM is used, albeit it is not defined in the BRs, and there is no
standard for HSM key attestation (to my knowledge?).

The specification of an HSM is:
"at least FIPS 140 Level 2, Common Criteria EAL 4+, or equivalent."

"Common Criteria EAL 4+" is an outdated specification that has no meaning:
- unless a Protection Profile is also specified such as the ETSI CP5 PP
- Collaborative Protection Profiles, used by NIAP does not have EAL levels.

Token type number 3 in the list can mean anything, and offer no key
I can understand a need for using USB tokens that are not FIPS certified,
and they don't have to be any less secure. But point three sets a very low
bar as written today.

Some cabforum strawman suggestions:

1. Remove the requirement of Key Attestation for TPMs. Or assuming Microsoft
is behind it(?), re-write it more explicit what is expected.
And that it is only expected for TPMs(?)

2. Remove "Common Criteria EAL 4+". A CC certification could be considered
covered in "or equivalent" already.

3. Update token type 3 to mean smart card (PKI) types of tokens, that can be
either a smart card or a USB token with key generation and protection. Even
requiring "FIPS 140-2 level 3 or equivalent" allows enough tokens that are
used in practice perhaps? (such as Yubikeys, YubiHSM, Nitrokey HSMs etc)

Cscwg-public mailing list
Cscwg-public at cabforum.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/cscwg-public/attachments/20191026/3129ded9/attachment.p7s>

More information about the Cscwg-public mailing list