[Rats] draft-ietf-rats-pkix-key-attestation-07

[Richard Kettlewell <[e-mail]>]

Hi folks,

Mike asked me for feedback on draft-ietf-rats-pkix-key-attestation-07 
and whether an nShield HSM implementation was practical.

TLDR: yes, but I think there are a number of issues that need some work 
(largely independent of any particular HSM).

https://www.ietf.org/archive/id/draft-ietf-rats-pkix-key-attestation-07.html#name-claim-type
 > [4.3] It is RECOMMENDED that a claim type be defined for a specific 
element type, to reduce confusion when it comes to interpretation of the 
value. In other words, a claim type SHOULD NOT be used by multiple 
element types

Is there any reason this cannot be elevated from RECOMMEND to MUST (and 
SHOULD NOT to MUST NOT)? As a 'green field' spec, there are presumably 
no existing multi-element-type claims to be compatible with.

https://www.ietf.org/archive/id/draft-ietf-rats-pkix-key-attestation-07.html#name-data-model
 > [5] It is expected that a X.509 certificate will be generally used

The ASN.1 definition would appear to require an X.509 certificate (via 
the RFC5912 Certificate definition), so how would a certificate of a 
different format be used? Wouldn't it lead to a DER parse failure?

https://www.ietf.org/archive/id/draft-ietf-rats-pkix-key-attestation-07.html#name-fipsboot-fipsver-fipslevel-
 > [5.1.4] Among other restrictions, [fipsboot] means that only 
FIPS-approved algorithms are available.

FIPS modules (in their FIPS mode) may offer non-approved algorithms 
(under certain constraints). I think the definition of 'fipsboot' should 
be broadened to reflect this.

https://www.ietf.org/archive/id/draft-ietf-rats-pkix-key-attestation-07.html#name-extractable-sensitive-never
 > [5.2.3] The claim "extractable" indicates that the key can be 
exported from the HSM. Corresponds directly to the attribute 
CKA_EXTRACTABLE found in PKCS#11.
 >
 > The claim "sensitive" indicates that the value of key cannot leave 
the HSM in plaintext. Corresponds directly to the attribute 
CKA_SENSITIVE found in PKCS#11.

In PKCS#11 if a key has CKA_SENSITIVE=true and CKA_EXTRACTABLE=true then 
key plaintext can still leave the HSM, by wrapping it under a wrapping 
key with decrypt permission or a public key corresponding to a known 
private key (an observation made by Jolyon Clulow at least 20 years 
ago). Both attributes indicate (with opposing sense) an ability to 
recover plaintext key material; the only difference is in how involved 
the process is.

I think the draft would be better served with a single claim indicating 
whether the key plaintext can be extracted, without concerning itself 
with the mechanism used to achieve that extraction and without tying it 
to PKCS#11's definitions. The idea of borrowing attribute definitions 
from a widely used existing source is a good one but the PKCS#11 
definitions are not quite right.

nShield can synthesize these claims as stated but in practice if we ever 
synthesized "extractable"=true we would also synthesize 
"sensitive"=false, since anything else would mislead the relying party 
about the security of the key.

https://www.ietf.org/archive/id/draft-ietf-rats-pkix-key-attestation-07.html#name-extractable-sensitive-never
 > [5.2.3] The claim "never-extractable" indicates if the key was never 
extractable from the HSM throughout the life of the key. Corresponds 
directly to the attribute CKA_NEVER_EXTRACTABLE found in PKCS#11.
 >
 > The claim "local" indicates whether the key was generated locally or 
imported. Corresponds directly to the attribute CKA_LOCAL found in PKCS#11.

When generating an attestation at key generation or import time, nShield 
can synthesize these claims (with the above caveats about their 
meaning). However it cannot necessarily distinguish between a key that 
was imported and a key that was generated in an HSM, at some point in 
the past. The attributes would be absent in these cases. (I don't think 
this is really a practical problem.)

https://www.ietf.org/archive/id/draft-ietf-rats-pkix-key-attestation-07.html#name-purpose
 > [5.2.5] [purpose] reports the key purposes, also referred to as key 
capabilities, associated with the subject key.

Since the subject key is a private key, 'encrypt', 'wrap' and 'verify' 
would seem to be redundant?

The mapping of permissions to actual operations should be made explicit. 
It should be possible to unambiguously answer questions such as:
* For a DH/ECDH key which purpose covers key agreement?
* For a KEM key which purpose covers decapsulation?
* Which purpose(s) cover(s) the combination of a 
decrypt/agree/decapsulate operation with a KDF operation?
* For a 'fully cooked' key unwrapping mechanism like ECIES, should 
'decrypt' (or whatever is chosen for key agreement) be advertised as 
well as 'unwrap'?
* Do logically harmless operations like deriving a public key from a 
private key need to be reported as 'derive'?

(Various locations)
 > certain protection properties such as Non-Exportable and Dual-Control
 > the constraints applied to the key (such as whether is it extractable).
 > "extractable" may always be false for all keys since the devices are 
not capable of key export
 > a claim that reports whether the key is extractable or not.
 > The claim "extractable" indicates that the key can be exported from 
the HSM.
 > if the key was never extractable from the HSM throughout the life of 
the key

The draft seems to use 'export' and 'extract' interchangeably. I think 
it should pick a single term and define it explicitly in the s3 glossary.

'Extract' seems the more common term in -07, so perhaps the following 
would be suitable:

Extract:
   Extracting a private key means recovering the plaintext of the key 
outside an Attester, by any means, and without appropriate authorisation 
from the owner of the key.

ttfn/rjk