Is there anyone who can explain where the 512 bits comes from and what value it adds for JOSE's use of ECDH-ES case?
My sense from the call yesterday was that I wasn't the only one that didn't grok what value these additional inputs into the KDF really provide. For the compact serialization, if possible/reasonable, I'd like to avoid the overhead of adding 512 more bits that will be base64url encoded twice. On Thu, Sep 5, 2013 at 12:28 PM, Mike Jones <[email protected]> wrote: > Thanks for the new text, Richard. Slight consistency edits proposed below… > > > > Applications MUST specify what values should be used in the "apu" and "apv" > parameters. Applications wishing to conform to [NIST.800-56A] need to > provide values that meet the requirements of that document, e.g., by > choosing values that identify the sender and recipient. Alternatively, > applications MAY conduct key derivation in a manner similar to [RFC2631]: In > that case, the "apu" field SHOULD represent a random 512-bit value > (analogous to PartyAInfo in [RFC2631]) and the "apv" field should not be > present. > > > > -- Mike > > > > From: Richard Barnes [mailto:[email protected]] > Sent: Thursday, September 05, 2013 8:23 AM > To: jose issue tracker > Cc: <[email protected]>; [email protected] > Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs > > > > As promised on the call yesterday, here's some proposed revision to Section > 4.7.2: > > > > OLD: > > """ > > Note: The Diffie-Hellman Key Agreement Method [RFC2631] 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. Should it be > > appropriate for the application, 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. > > """ > > > > NEW: > > """ > > Applications must specify what values should be populated in the "apu" and > "apv" parameters. Applications wishing to conform to [NIST.800-56A] need to > provide values that meet the requirements of that document, e.g., by > choosing values that identify the sender and recipient. Otherwise, it is > RECOMMENDED that applications conduct key derivation in a manner similar to > [RFC2631]: The "apu" field should be set to a random 512-bit value > (analogous to PartyAInfo in [RFC2631]) and the "apv" field should be left > empty. > > """ > > > > > > On Sun, Aug 11, 2013 at 6:56 PM, jose issue tracker > <[email protected]> wrote: > > #55: Mandatory entropy in ECC KDF inputs > > At the interim, there was agreement to require at least 512 bits of > entropy in the "apu" field, in order to ensure sufficient entropy in the > resulting key. That requirement has been lost in a subsequent revision. > > -- > -------------------------+------------------------------------------------- > Reporter: [email protected] | Owner: draft-ietf-jose-json-web- > Type: defect | [email protected] > Priority: major | Status: new > Component: json-web- | Milestone: > algorithms | Version: > Severity: - | Keywords: > -------------------------+------------------------------------------------- > > Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/55> > jose <http://tools.ietf.org/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
