Re: [jose] JWK Parameter Registry Considerations

["Matt Miller (mamille2)" <[e-mail]>]

On Mar 19, 2013, at 11:30 AM, Richard Barnes <[e-mail]>
 wrote:

>> 1) Should JWK parameter names be absolutely unique, or are they
>> potentially tied to a specific JWK type?  In looking at the specs to date,
>> I think there's only one case where a parameter name is re-used ("d" for
>> both private RSA and ECC keys); currently syntactically and semantically
>> identical, but I'm not sure that's adequate.
>> 
> 
> I think it makes sense for parameter names to be potentially contingent on
> key type.  Emphasis on "potentially" -- there could be attributes that are
> the same for all key types.  I would also propose that we make "kty" a
> mandatory attribute.
> 

I do think there are attributes that have identical semantics regardless of key type ("kid", "x5c"? (-: ).  Requiring "kty" is probably necessary, but I don't have a firm opinion yet.

> 
> 
>> 2) Should JWK parameters be marked as private (confidential, secret,
>> privileged, etc etc)?  The current documentation set loosely defines this
>> only because they are current split between multiple documents.  However, I
>> wonder if there is value in being much more explicit about it, including in
>> a parameter's registration.
>> 
> 
> If we fold JPSK in to JWA (which we should do), then ISTM that we should
> also note which parameters are private, in the sense of "have a column in
> the registry that marks this as a "private" parameter".  Note that
> designation as private would not necessarily imply that you MUST do any
> particular thing.  One can envision, for example, cases where it might be
> safe to pass private keys in plaintext (e.g., over TLS).
> 

Completely agree; it's an indicator to applications and implementations that this parameter might warrant additional considerations when present.

> One other question:
> 
> 3) Should we remove "policy" attributes from JWK?  The current JWK spec
> includes a variety of attributes that are not directly specifying parts of
> the key, namely "use" and "alg".  These are application-related fields, and
> run the risk of conflicting with existing applications' attributes.  For
> example, the WebCrypto API has a notion of key usages and algorithm
> restriction, but the values they use do not map to the "use" and "alg"
> values.  Should we align with WebCrypto (and risk conflicting with other
> apps), or remove the policy bits altogether (and require apps to align
> themselves)?  FWIW, I am fine with "kid" staying there, because (1) it's
> opaque, and (2) it's actually used in JOSE processing.


I wouldn't consider "kid" a policy attribute anyway; it's pretty clear to me this is critical in properly referencing.  Otherwise, I don't have an opinion on the others.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.