Subject: [jose] Rolling PKIX into JWK

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 14 Mar 2013 13:48:03 +0000

[hoping this topic is the least controversial...]

In some IRL discussions on moving forward on PKIX in JWK, I've been convinced the concerns are mostly the same regardless of how the PKIX is packaged.  Given that, I would suggest we make "x5c" an optional field of JWK, rather than defining a new JWK type.  I can propose various text additions after this meeting.

Thoughts?

- m&m

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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 14 Mar 2013 10:11:17 -0400

I've personally come to prefer the PKIX key type approach (maybe because
I've done some downstream work with it).  However, similar to what Matt
said yesterday, I'd just like to have the general functionality available
so I'm okay with either way of doing it (as long as it gets done).

BTW, I mentioned the related work on key publication and rotation in OpenID
Connect yesterday, which is in §4 at
http://openid.net/specs/openid-connect-messages-1_0.html#sigenc.key if
anyone is interested in taking a look at it (it's not very long!).

On Thu, Mar 14, 2013 at 9:48 AM, Matt Miller (mamille2)
<[email-masked]>wrote:

> In some IRL discussions on moving forward on PKIX in JWK, I've been
> convinced the concerns are mostly the same regardless of how the PKIX is
> packaged.  Given that, I would suggest we make "x5c" an optional field of
> JWK, rather than defining a new JWK type.  I can propose various text
> additions after this meeting.
>
>
> Thoughts?
>
> - m&m
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 15 Mar 2013 17:43:29 +1100

I agree, a certificate as an optional field of any JWK sounds like a decent approach.

Putting a whole cert chain in one JWK is not ideal.
Each cert is about 1 key so really should be in its own JWK.
Otherwise you will duplicate the chain of intermediate CA certs in each JWK in a set.

It might be useful to define a issuer key-id field ("isskid"). A JWK could include a cert for its own key and (with "isskid") a link to the next cert along the chain. That makes it quick-n-easy to build a chain from the JWKs in a set.

It would also help if JWKs in a set where held in a object/dictionary/associative-array with the kid as the name. That would be better than using an array of JWKs with no defined meaning for the order.

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matt Miller (mamille2)
> Sent: Friday, 15 March 2013 12:48 AM
> To: <[email-masked]>
> Subject: [jose] Rolling PKIX into JWK
> 
> convinced the concerns are mostly the same regardless of how the PKIX
> is packaged.  Given that, I would suggest we make "x5c" an optional
> field of JWK, rather than defining a new JWK type.  I can propose
> various text additions after this meeting.
> 
> 
> Thoughts?
> 
> - m&m
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 15 Mar 2013 17:52:31 +1100

I don't mind being able to put a whole cert chain in one JWK, but clients that get a set of JWKs (eg by dereferencing a "jku" URI) should also cope if the each cert of the chain is in its own JWK in the set.

--
James Manger

> Manger, James H
> Sent: Friday, 15 March 2013 5:43 PM
> To: Matt Miller (mamille2); <[email-masked]>
> Subject: Re: [jose] Rolling PKIX into JWK
> 
> It might be useful to define a issuer key-id field ("isskid"). A JWK
> could include a cert for its own key and (with "isskid") a link to the
> next cert along the chain. That makes it quick-n-easy to build a chain
> from the JWKs in a set.
> 
> It would also help if JWKs in a set where held in a
> object/dictionary/associative-array with the kid as the name. That
> would be better than using an array of JWKs with no defined meaning for
> the order.
> 
> --
> James Manger
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 15 Mar 2013 12:49:48 -0400

> I agree, a certificate as an optional field of any JWK sounds like a

+1, although it's not mutually exclusive with having a "PKIX" key type.

> It might be useful to define a issuer key-id field ("isskid"). A JWK could
> include a cert for its own key and (with "isskid") a link to the next cert
> along the chain. That makes it quick-n-easy to build a chain from the JWKs
> in a set.
>
> object/dictionary/associative-array with the kid as the name. That would be
> better than using an array of JWKs with no defined meaning for the order.
>

This proposal seems much, much worse than having a cert chain in one JWK.
 If you're going to have all the public keys as JWKs, you might as well
just re-invent X.509 in JWK, in which case you would probably use JWS over
JWK, which solves the "isskid" problem using the "kid" in the JWS.  The
benefit of having the cert chain is that you don't have to re-invent X.509,
you just pass the cert chain to your existing X.509 library.

In other words, let's have the trust chain be fully X.509 or fully JOSE,
even if it starts from a JWK.

--Richard

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Mar 2013 12:57:48 -0400

Agreed,  having the cert chain in the x5u is optional,  having it for validation if you want that trust chain is not a problem.   Trying to optimize that for size is going to be too complicated.

John B.

On 2013-03-15, at 12:49 PM, Richard Barnes <[email-masked]> wrote:

> On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H <[email-masked]> wrote:
> This proposal seems much, much worse than having a cert chain in one JWK.  If you're going to have all the public keys as JWKs, you might as well just re-invent X.509 in JWK, in which case you would probably use JWS over JWK, which solves the "isskid" problem using the "kid" in the JWS.  The benefit of having the cert chain is that you don't have to re-invent X.509, you just pass the cert chain to your existing X.509 library.  
> 
> In other words, let's have the trust chain be fully X.509 or fully JOSE, even if it starts from a JWK.  
> 
> --Richard
> 
> 
>  
> 
> --
> James Manger
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 15 Mar 2013 13:11:19 -0400

Just to clarify, what I'm suggesting is to have "x5c" as an attribute for
JWK, with the same syntax as in JWS.  As Brian suggested in his slides.

IF we want to go down the path of having "chained" JWKs, the syntax would
be something like the following:
"jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ]
Where jws(kx, ky) indicates a JWS with ky as the body and kx as the signing
key.  IF we build something like this, it would be used in the same manner
as "x5c", as an attribute of a JWK.  However, I think designing such a
thing would be a significant deviation from our charter, so we would need
to recharter or even form a new WG (PKIJ?)

--Richard

On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes <[email-masked]> wrote:

>> could include a cert for its own key and (with "isskid") a link to the next
>> cert along the chain. That makes it quick-n-easy to build a chain from the
>> JWKs in a set.
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Mar 2013 13:21:35 -0400

Chained JWK is a rathole I would prefer not to go down.

Yes to x5c & x5u as attributes of JWK.

John B.
On 2013-03-15, at 1:11 PM, Richard Barnes <[email-masked]> wrote:

> Just to clarify, what I'm suggesting is to have "x5c" as an attribute for JWK, with the same syntax as in JWS.  As Brian suggested in his slides.
> 
> IF we want to go down the path of having "chained" JWKs, the syntax would be something like the following:
> Where jws(kx, ky) indicates a JWS with ky as the body and kx as the signing key.  IF we build something like this, it would be used in the same manner as "x5c", as an attribute of a JWK.  However, I think designing such a thing would be a significant deviation from our charter, so we would need to recharter or even form a new WG (PKIJ?)
> 
> --Richard
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 15 Mar 2013 14:11:31 -0400

Another clarification:  I'm fine with either "x5c" as a JWK, or "PKIX" as a
"kty" value. In the former case, I would prefer that the "x5c" be attached
to individual keys and not key sets.

On Friday, March 15, 2013, Richard Barnes wrote:

> Where jws(kx, ky) indicates a JWS with ky as the body and kx as the
> signing key.  IF we build something like this, it would be used in the same
> manner as "x5c", as an attribute of a JWK.  However, I think designing such
> a thing would be a significant deviation from our charter, so we would need
> On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> [email-masked] <javascript:_e({}, 'cvml',
>> [email-masked]');>> wrote:
>>
>>> > From: [email-masked] <javascript:_e({}, 'cvml',
>>> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
>>> On Behalf Of
>>> > Matt Miller (mamille2)
>>> > To: <[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
>>> > Matt Miller < [email-masked] <javascript:_e({}, 'cvml',
>>> [email-masked]');> >
>>> > Cisco Systems, Inc.
>>>
>>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 15 Mar 2013 13:16:15 -0600

Agreed, if "x5c" goes directly as an attribute of JWK (or an attribute
common to EC and RSA key types), it attaches to an individual JWK and
definitely not to a whole JWK Set.

On Fri, Mar 15, 2013 at 12:11 PM, Richard Barnes <[email-masked]> wrote:

> Another clarification:  I'm fine with either "x5c" as a JWK, or "PKIX" as
> a "kty" value. In the former case, I would prefer that the "x5c" be
> attached to individual keys and not key sets.
>
>
>
>>> This proposal seems much, much worse than having a cert chain in one
>>> JWK.  If you're going to have all the public keys as JWKs, you might as
>>> well just re-invent X.509 in JWK, in which case you would probably use JWS
>>> over JWK, which solves the "isskid" problem using the "kid" in the JWS.
>>>  The benefit of having the cert chain is that you don't have to re-invent
>>> X.509, you just pass the cert chain to your existing X.509 library.
>>>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 15 Mar 2013 19:49:31 +0000

> to individual keys and not key sets.

+1; only in a JWK object, not the set.

- m&m

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Mar 2013 20:56:01 -0400

+1 yes attached to a key not a key set.