Re: [jose] #82: Section 6. Encrypted JWK and Encrypted JWK Set Format

["Manger, James H" <[e-mail]>]

> #82: Section 6. Encrypted JWK and Encrypted JWK Set Format
> 
>  A. The existence of private material is not easily identifiable for an
> entity that does not have full and update information on a kty value.
>  This means that they either need to not allow them to be processed or
> they  need to not worry about the fact that information may be private.
> This  can be fixed by defining a JWK element "private" and requiring
> that all  private material be placed in that object. This should be
> evaluated


Perhaps instead of (or in addition to) a "private" field, JWK should have a "pub" field.

"pub" would hold just those components needed to perform a public key calculation (eg "n" and "e"; or "crv", "x", and "y"). Metadata such as "use", "kid", "x5*" etc would not be under "pub". The JWE "epk" field, for instance, would be defined to hold the "pub" field of a JWK, not a whole JWK.

That would avoid the current ambiguity in which kid/x5c/x5u/x5t can appear at the top-level of a JWE/JWS and can also appear one layer down in a "jwk" (or "epk") field.


JWK has no current way to represent a key when the private components are hardware-protected. For instance, on a TPM chip, Secure Element, or smart card (or just behind a crypto API such as PKCS#11). To use such a key you need its "address" (eg TPMKEY URI [draft-mavrogiannopoulos-tpmuri]) and perhaps a password. Should a JWK for such a key use a different "kty" value, or would unnecessarily break apps that only want to use the public components?

--
James Manger