This is good, I think we're converging. As that text is written, it seems a little confusing as to whether an app should use blank or 512bits. I would propose that we set a nonce as default, and say you MAY omit "apu" if you're doing the right thing. There's no harm in the nonce (besides size), so it's a safe default for a developer that may not understand "ephemeral-static".
Proposed text, with my changes in [[brackets]]: """ 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 using 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. Applications MAY omit the "apu" and "apv" fields only if operating in Ephemeral-Static mode, with a separate ephemeral key generated for each recipient. ]] """ On Thu, Sep 5, 2013 at 8:31 PM, Mike Jones <[email protected]>wrote: > Thanks for doing this research, Brian. We only support ephemeral-static > mode, so your findings are quite pertinent. I therefore propose that we > further revise the text as follows:**** > > ** ** > > 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 > using 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 MAY either be omitted or represent a random > 512-bit value (analogous to PartyAInfo in Ephemeral-Static mode in > [RFC2631]) and the "apv" field should not be present.**** > > ** ** > > -- Mike*** > * > > ** ** > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Brian Campbell > Sent: Thursday, September 05, 2013 5:21 PM > To: Mike Jones > Cc: Richard Barnes; jose issue tracker; < > [email protected]>; [email protected] > Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs > > ** ** > > RFC 2631 requires the 512 bits of partyAInfo only for Static-Static mode > while using it for Ephemeral-Static is just a 'MAY'.**** > > ** ** > > I guess that's what the proposed JOSE text says too. But the MAY followed > by the conditional SHOULD reads kind of funny. And as someone who's asked > for some more clarity and guidance on the use of "apu" and "apv" that text > didn't leave me felling sure of what to do with them but made me feel like > I probably needed to put 512 bits of stuff in there.**** > > ** ** > > On Thu, Sep 5, 2013 at 2:25 PM, Mike Jones <[email protected]> > wrote:**** > > > I also stated on the call that the 512 additional bits of entropy don't > any value to the randomness already present in the ephemeral key.**** > > >** ** > > > I perceive the 512 bit text as being there to make people who are > enamored of RFC 2631 key agreement happy, by telling them how they could do > the same thing in this case. I personally believe we're better off if > applications just say what they expect to be in "apu" and "apv" (if > anything) and ignore the 2631 backup plan.**** > > >** ** > > > -- Mike**** > > >** ** > > > -----Original Message-----**** > > > From: Brian Campbell > > [mailto:[email protected]<[email protected]> > ]**** > > > Sent: Thursday, September 05, 2013 2:20 PM**** > > > To: Mike Jones**** > > > Cc: Richard Barnes; jose issue tracker; [email protected]; ** ** > > > <[email protected]>**** > > > Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs**** > > >** ** > > > 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] <[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**** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
