I'm fine removing the MUST (this doesn't really seem like a 2119 thing). How about this?
""" Each application should specify how senders populate the "apu" and "apv" parameters in the context of that application. 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. """ On Wed, Sep 11, 2013 at 2:55 PM, Brian Campbell <[email protected]>wrote: > 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 modein >> [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
