On Mar 19, 2013, at 11:30 AM, Richard Barnes <[email protected]> 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 < [email protected] >
Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
