Subject: [jose] JWK Parameter Registry Considerations

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Mar 2013 14:17:27 +0000

In thinking about the JWK parameter registry, I have a couple of questions/concerns.

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.

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.

Thoughts?

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Mar 2013 14:19:56 +0000

> 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 d…

And, yes, I do (now) remember there was a general call for merging JPSK into JWA (-:

- m&m

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Mar 2013 13:30:25 -0400

> 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.

> 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).

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.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Mar 2013 17:59:48 +0000

> the same for all key types.  I would also propose that we make "kty" a

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.

> 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.

> 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

---

From: Brian Campbell <[email-masked]>
Date: Tue, 19 Mar 2013 12:45:01 -0600

"use" is useful in the context of some entity providing its public keys in
a JWK Set somewhere for some other party to consume those keys and know
what to do with them.

On Tue, Mar 19, 2013 at 11:30 AM, Richard Barnes <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Mar 2013 00:26:43 -0400

Not denying it's useful (or "alg").  Just saying that the JWK core spec
might not be the place to define them.  Or, alternatively, that if we do
define them, we should align syntax/semantics with WebCrypto to avoid
conflicts.

On Tue, Mar 19, 2013 at 2:45 PM, Brian Campbell
<[email-masked]>wrote:

>> 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.
>>
>>
>>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 20 Mar 2013 15:38:44 +1100

> 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.

Yes, but not with a registry flag.
Putting the private values in a separate sub-object would be better (eg "pri":{"d":...}). It would  allow you to notice private values without needing to know every key type (or looking up a registry).

> 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.

If private components are in a "pri" field and public components (and common parameters such as a elliptic curve id) are in a "pub" field, then it is fairly obvious that these components depend on the type of key so there is no need to have a registry for them -- just register key types.

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Mar 2013 10:01:36 -0400

I think what Matt was asking was less about how the recipient of an object
knows which fields the sender considers private, and more about how a
sender knows which fields he should mark as private.  A naïve reader might
not realize that the "d" component needs to be in the private section, for
example.

I do think the idea of splitting private and public makes sense, but only
really in the context of key wrapping -- private things go inside the
wrapping, and public things outside ("wk" and "kat" in the terms of my
slides at IETF86).

--Richard

On Wed, Mar 20, 2013 at 12:38 AM, Manger, James H <
[email-masked]> wrote:

> Putting the private values in a separate sub-object would be better (eg
> "pri":{"d":...}). It would  allow you to notice private values without
> needing to know every key type (or looking up a registry).
>
>
> If private components are in a "pri" field and public components (and
> common parameters such as a elliptic curve id) are in a "pub" field, then
> it is fairly obvious that these components depend on the type of key so
> there is no need to have a registry for them -- just register key types.
>
> --
> James Manger
>

---

From: Daniel Holth <[email-masked]>
Date: Wed, 20 Mar 2013 10:07:41 -0400

> 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.

FWIW I think it is a little awkward having kid in the key itself,
especially thinking about using a hash or fingerprint of the key as
the kid. Depends on whether you think of a jwk should be more of a
table-like structure or a kid : value mapping. Totally fine with
leaving it in though.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 20 Mar 2013 14:58:34 +0000

> not realize that the "d" component needs to be in the private section, for

Basically this.

> wrapping, and public things outside ("wk" and "kat" in the terms of my

One way or another (-:

- m&m