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

[Dean Coclin]

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


-----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
(16.3)


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/compon
ent-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
_______________________________________________
Cscwg-public mailing list
Cscwg-public at cabforum.org
http://cabforum.org/mailman/listinfo/cscwg-public

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