Re: [jose] Rolling PKIX into JWK

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 <rlb@ipv.sx> wrote:

> On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H <
> James.H.Manger@team.telstra.com> wrote:
>
>> I agree, a certificate as an optional field of any JWK sounds like a
>> decent approach.
>>
>
> +1, although it's not mutually exclusive with having a "PKIX" key type.
>
>
>> 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.
>>
>
> 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
>>
>> > -----Original Message-----
>> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>> > Matt Miller (mamille2)
>> > Sent: Friday, 15 March 2013 12:48 AM
>> > To: <jose@ietf.org>
>> > Subject: [jose] Rolling PKIX into JWK
>> >
>> > [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 < mamille2@cisco.com >
>> > Cisco Systems, Inc.
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
>