I have been thinking about this and I am going to make a different proposal.

 

 

The proposal is as follows:

 

1.        We eliminate the two partyX fields from the specification

2.       We define a new "ID" field which MUST be present for ECDH keys.

3.       We say that you take the ID field from the sender/recipient
respectively and use them in the PartyX fields when doing the KDC.

 

The only down side of this, is that if one has a certificate then we should
use the DER encoded subject name of the certificate but I am not sure how
this would be encoded in the case you have a JWK which contains an x5c
member.  It might be that we will need to defined an ID and an IDb64 field
to allow for a binary ID to be used.

 

There would still need to be a requirement that the ID field be length
prefixed in the discussion.

 

Jim

 

 

From: [email protected] [mailto:[email protected]] On Behalf Of Mike
Jones
Sent: Sunday, June 23, 2013 2:57 PM
To: Russ Housley
Cc: [email protected]
Subject: Re: [jose] Concat KDF

 

Good idea, Russ.  How about this?

 

"In the general case, the specific identifiers used to tie the key
derivation to the sender (Party U) and the receiver (Party V) are
application specific and beyond the scope of this specification.  As an
illustration of one possible usage, when the JWE is a JSON Web Token (JWT)
[JWT], applications might specify that the "iss" (issuer) value be used as
the "apu" value and the primary "aud" (audience) value be used as the "apv'
value."

 

                                                            -- Mike

 

From: Russ Housley [mailto:[email protected]] 
Sent: Sunday, June 23, 2013 7:43 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [jose] Concat KDF

 

Mike:

 

I can add a sentence along the lines of the following to make Jim's points
below clearer to non-expert readers:

 

"The specific identifiers used to tie the key derivation to the sender
(Party U) and the receiver (Party V) are application specific and beyond the
scope of this specification."

 

I see the attraction of this approach, but I wonder if it would be possible
to also include some advice to applications that make use of JOSE.

 

If the parties that are trying to form a pairwise key make different
assumptions, then we do not get interoperability.  I am just trying to
improve the likelihood of interoperability.

 

Russ

 

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

Reply via email to