WFM
On Fri, Oct 4, 2013 at 11:11 AM, Richard Barnes <[email protected]> wrote: > 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
