> #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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
