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

[Tomas Gustavsson]

Hi,

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.

1.
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:
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation

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

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

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

3.
Token type number 3 in the list can mean anything, and offer no key
protection.
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)

Regards,
Tomas