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

[Tomas Gustavsson]

Perfect. My memory is often too short to remember what I have heard
earlier :-)

See you in China.

Regards,
Tomas

On 2019-10-26 23:59, Dean Coclin wrote:
> 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
>