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 protected]> wrote: > 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'. > > > > > On Jan 25, 2013, at 12:43 PM, Mike Jones <[email protected]> > wrote: > > > They're there exactly to let the recipient known which private key to > use for decryption. Hardly useless... > > > > -- Mike > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > Richard Barnes > > Sent: Friday, January 25, 2013 8:36 AM > > To: Brian Campbell > > Cc: [email protected] > > Subject: Re: [jose] How would x5u really be used with JWE? > > > > 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 protected]> > wrote: > > > >> 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? > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
