The goal is simple - meet the requirements of the NIST document.
No the text below does not meet the requirements stated above. The text does not contain sufficient information to fully document what is required to define the KDF function needed. However, I will be happy using the 2531 KDF function rather than a NIST one since, as I have previously stated, the reasons in the NIST document for having the party identifiers is not one that is required for the store and forward use cases. Jim From: Mike Jones [mailto:[email protected]] Sent: Sunday, June 23, 2013 6:18 PM To: Jim Schaad; 'Russ Housley' Cc: [email protected] Subject: RE: [jose] Concat KDF Jim - permit me to ask a pair of follow-up questions. First, what goal are you trying to accomplish in your suggestion below? I'm wondering if there's a way to meet the needs of the use case you have in mind with particular parameter choices with the Concat KDF. Second, does the proposed text below meet the needs of the use case you have in mind? The Diffie-Hellman Key Agreement Method [RFC 2631] uses a key derivation function similar to the Concat KDF, but with fewer parameters. Rather than having separate PartyUInfo and PartyVInfo parameters, it uses a single PartyAInfo parameter, which is a random string provided by the sender, that contains 512 bits of information, when provided. It has no suppPrivInfo parameter. Key agreement can be performed in a manner akin to RFC 2631 by using the PartyAInfo value as the "apu" (Agreement PartyUInfo) header parameter value, when provided, and by using no "apv" (Agreement PartyVInfo) header parameter. Thanks, -- Mike From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Sunday, June 23, 2013 5:25 PM To: Jim Schaad; 'Russ Housley' Cc: [email protected] Subject: Re: [jose] Concat KDF The problem with that is that we're inventing our own KDF at that point. The upsides of Concat are that it is known to work, is known to be implemented, and is known to meet NIST and other existing security criteria. At least as I see it, we shouldn't give up those advantages without a compelling reason to do so. -- Mike From: Jim Schaad [mailto:[email protected]] Sent: Sunday, June 23, 2013 4:11 PM To: Mike Jones; 'Russ Housley' Cc: [email protected] Subject: RE: [jose] Concat KDF 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
