Much improved, thanks. I'm still not crazy about the first sentence though. Really the sender specifies the "apu" and "apv" values simply by sending them or omitting them (James made a similar point last week). I think that as far as JOSE should go with it normatively. Applications may specify additional constraints on the use and values for "apu" and "apv", if appropriate for their context. Can it say something more like that? Or at least drop that first MUST?
On Thu, Sep 5, 2013 at 6: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
