Subject: [jose] How would x5u really be used with JWE?

From: Brian Campbell <[email-masked]>
Date: Tue, 22 Jan 2013 11:10:28 -0700

Is there a concrete use case for this that someone could explain to me?

How does an encrypting party know what URL to use to get the key to
encrypt? I assume some out-of-band exchange. How would key rolling work
then? An an encrypting party would need to a priori know all potential
x5u's of the decrypting party? Which seems dubious. And how would the
decrypting party signal a desired change of keys?

Am I missing something obvious here?

---

From: Richard Barnes <[email-masked]>
Date: Fri, 25 Jan 2013 11:36:13 -0500

AFAICT, the X.509 fields in JWE are pretty useless.

If you're using key transport (i.e., wrapping the symmetric key in a public key), then you would use the "jwk" or "jku" fields to reference the key pair you used to do the wrapping.  The only function of the public key crypto fields in a JWE is to let the recipient know which private key to use for decryption.  The recipient already needs to have the private key, since it obviously won't be in the message.

The question of how the encrypting party figures out which public key to use for a given recipient (and in particular, roll-over), is an application-layer question, not something that JWE would address.  See the XMPP end-to-end security doc for an example; they use a separate exchange to associate a JWK with an XMPP ID.
<http://tools.ietf.org/html/draft-miller-xmpp-e2e>

--Richard

On Jan 22, 2013, at 1:10 PM, Brian Campbell <[email-masked]> wrote:

> How does an encrypting party know what URL to use to get the key to encrypt? I assume some out-of-band exchange. How would key rolling work then? An an encrypting party would need to a priori know all potential x5u's of the decrypting party? Which seems dubious. And how would the decrypting party signal a desired change of keys?  
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Fri, 25 Jan 2013 17:43:48 +0000

They're there exactly to let the recipient known which private key to use for decryption.  Hardly useless...

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, January 25, 2013 8:36 AM
To: Brian Campbell
Cc: [email-masked]
Subject: Re: [jose] How would x5u really be used with JWE?

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Fri, 25 Jan 2013 13:02:54 -0500

Ok, that sort of makes sense.  

Note that in that case, there's no point to sending a cert chain ('x5c'), since it's the recipient's cert you're talking about.  Even 'x5u' is kind of overkill; all you really need is 'x5t'.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 25 Jan 2013 13:37:40 -0700

Yes of course signaling to the recipient which private key to use for
decryption is useful. Though it is unclear to me why one would use x5u or
x5c in the context of encryption rather than x5t or jku and/or kid. It
seems the later ones provide the same functionality in simpler and or more
concise ways.

The intent of my original post to the list wasn't to question the inclusion
of x5u or x5c in JWE (although I do think it's a fair question) but rather
to try and better understand what folks had envisioned doing with x5u and
encryption.  As Richard said, the key identification and roll-over are
typically application-layer questions. And I'm trying to work though those
very questions for OpenID Connect[1] right now. JWE dose provide some lower
level constructs to facilitate it at the app layer though (like jku, jwk,
x5u, x5t, x5c and kid) and, frankly, I didn't fully understand how some of
them were intended to be used so wanted to ask this group where they had
originated.

I haven't yet but will take a look at xmpp-e2e and see if there are any
concepts that can be borrowed.

Thanks,
Brian

[1] Two issues submitted against Connect on the general topic and the WG
home page
http://hg.openid.net/connect/issue/703/key-publication-needs-to-be-reworked
http://hg.openid.net/connect/issue/704/provide-key-rollover-guidance
http://openid.net/wg/connect/

On Fri, Jan 25, 2013 at 11:02 AM, Richard Barnes <[email-masked]> wrote:

> Note that in that case, there's no point to sending a cert chain ('x5c'),
> since it's the recipient's cert you're talking about.  Even 'x5u' is kind
> of overkill; all you really need is 'x5t'.
>
>
>
>
> > If you're using key transport (i.e., wrapping the symmetric key in a
> public key), then you would use the "jwk" or "jku" fields to reference the
> key pair you used to do the wrapping.  The only function of the public key
> crypto fields in a JWE is to let the recipient know which private key to
> use for decryption.  The recipient already needs to have the private key,
> since it obviously won't be in the message.
> >
> > The question of how the encrypting party figures out which public key to
> use for a given recipient (and in particular, roll-over), is an
> application-layer question, not something that JWE would address.  See the
> XMPP end-to-end security doc for an example; they use a separate exchange
> to associate a JWK with an XMPP ID.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 25 Jan 2013 23:21:57 +0000

I personally am struggling to find a JWE use-case where x5u is useful.

As far as the XMPP-e2e proposal goes, it basically provides a key exchange protocol, where the recipients provide the sender with their public key information in order to receive the session CMK.  While it's oriented toward "user to user", there might be things to borrow from there.

- m&m

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