Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs

From: Richard Barnes <[email-masked]>
Date: Thu, 5 Sep 2013 11:22:35 -0400

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-masked]> 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-masked]   |      Owner:  draft-ietf-jose-json-web-
>      Type:  defect       |  [email-masked]
>  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/>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Sep 2013 19:28:18 +0000

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-masked]]
Sent: Thursday, September 05, 2013 8:23 AM
To: jose issue tracker
Cc: <[email-masked]>; [email-masked]
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:
"""

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-masked]<mailto:[email-masked]>> wrote:
#55: Mandatory entropy in ECC KDF inputs

--
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]<mailto:[email-masked]>   |      Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]<mailto:[email-masked]>
 Priority:  major        |     Status:  new
Component:  json-web-    |  Milestone:
  algorithms             |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

---

From: Brian Campbell <[email-masked]>
Date: Thu, 5 Sep 2013 14:19:46 -0700

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-masked]> 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
>
>
>
> "apv" parameters.  Applications wishing to conform to [NIST.800-56A] need to
> provide values that meet the requirements of that document, e.g., by
> On Sun, Aug 11, 2013 at 6:56 PM, jose issue tracker
> <[email-masked]> wrote:
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Sep 2013 21:25:08 +0000

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-masked]] 
Sent: Thursday, September 05, 2013 2:20 PM
To: Mike Jones
Cc: Richard Barnes; jose issue tracker; [email-masked]; <[email-masked]>
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-masked]> wrote:
> 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
>
>
>
> 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
> (analogous to PartyAInfo in [RFC2631]) and the "apv" field should be 
> left empty.
>
> """
>
>
>
>
>
> entropy in the "apu" field, in order to ensure sufficient entropy in 
> the  resulting key.  That requirement has been lost in a subsequent revision.
>
> --
> -------------------------+--------------------------------------------
> -------------------------+-----
> -------------------------+--------------------------------------------
> -------------------------+-----
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 5 Sep 2013 17:20:37 -0700

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.

---

From: Mike Jones <[email-masked]>
Date: Fri, 6 Sep 2013 00:31:28 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, September 05, 2013 5:21 PM
To: Mike Jones
Cc: Richard Barnes; jose issue tracker; <[email-masked]>; [email-masked]
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.

> Cc: Richard Barnes; jose issue tracker; [email-masked]<mailto:[email-masked]>;

> <[email-masked]<mailto:[email-masked]>>

> On Thu, Sep 5, 2013 at 12:28 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

>> Thanks for the new text, Richard.  Slight consistency edits proposed

>> below...

>> 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.

>> similar to [RFC2631]: In that case, the "apu" field SHOULD represent

>> a random 512-bit value (analogous to PartyAInfo in [RFC2631]) and the

>> Cc: <[email-masked]<mailto:[email-masked]>>;

>> [email-masked]<mailto:[email-masked]>

>> As promised on the call yesterday, here's some proposed revision to

>> Section

>>    parameters, it uses a single PartyAInfo parameter, which is a

>> random

>>    string provided by the sender, that contains 512 bits of

>> information,

>>    appropriate for the application, key agreement can be performed in

>> a

>>    (Agreement PartyUInfo) header parameter value, when provided, and

>> by

>> recipient.  Otherwise, it is RECOMMENDED that applications conduct

>> key derivation in a manner similar to

>> <[email-masked]<mailto:[email-masked]>> wrote:

>> -------------------------+-------------------------------------------

>> -------------------------+-

>> -------------------------+-------------------------------------------

>> -------------------------+-

>> [email-masked]<mailto:[email-masked]>

jose mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 6 Sep 2013 14:36:36 +1000

> 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.

What does this mean?
Isn't a JOSE sender "specifying what value should be used" by actually including an "apu" field in a message?
Is this supposed to mean a sender MUST tell recipients (out-of-band) what will be used so recipients can confirm the "apu" value is correct? MUST recipients do this (app-specific) confirmation?

Are "Applications" in this context something like OpenID Connect (OIDC)? If Concat KDF really is app-specific we shouldn't define "ECDH-ES" in JWA but leave it to, say, OIDC to define "ECDH-ES/OIDC" along with a definition of what actually goes into PartUInfo etc and any parameters needed to convey that.

A "MUST" followed by a "should" in the same sentence makes little sense.

>  Applications wishing to conform to [NIST.800-56A]

If we specify the use of Concat KDF (defined in NIST.800-56A) then surely this implies you have to conform to NIST.800-56A. We can't take a NIST KDF, keep the name, but not keep the other constraints. 

> need to provide values that meet the requirements of that document,
> e.g., by using values that identify the sender and recipient.
> 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.

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Sep 2013 13:12:53 -0400

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-masked]>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:****
>
> ** **
>
> 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***
> *
>
> ** **
>
> Cc: Richard Barnes; jose issue tracker; <
> [email-masked]>; [email-masked]
> ** **
> 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-masked]>
> 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-masked]<[email-masked]>
> ]****
>
> > Sent: Thursday, September 05, 2013 2:20 PM****
>
> > To: Mike Jones****
>
> > Cc: Richard Barnes; jose issue tracker; [email-masked]; ** **
>
> > <[email-masked]>****
>
> > Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs****
>
> >** **
>
> value it adds for JOSE's use of ECDH-ES case?****
>
> >** **
>
> 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-masked]>
> wrote:****
>
> >> Thanks for the new text, Richard.  Slight consistency edits proposed **
> **
>
> >> below...****
>
> >>** **
>
> >>** **
>
> >>** **
>
> "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-masked] <[email-masked]>]****
>
> >> Sent: Thursday, September 05, 2013 8:23 AM****
>
> >> To: jose issue tracker****
>
> >> Cc: <[email-masked]>;****
>
> >> [email-masked]****
>
> >> 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-masked]> 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-masked]   |      Owner:  draft-ietf-jose-json-web-****
>
> >>      Type:  defect       |  [email-masked]****
>
> >>  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-masked]****
>
> >> https://www.ietf.org/mailman/listinfo/jose****
>
> >>** **
>
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/jose****
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 9 Sep 2013 18:02:56 +0000

As discussed on the call, the 512 bit entropy is redundant with the entropy already provided by the ephemeral key, and so is unnecessary.  The RFC 2631 text making it optional confirms this.  (It's only there for the Static-Static case, which this isn't.)  Given that it's unnecessary and extra size, I can't support a "SHOULD" for it.  The last sentence in your proposed text is redundant, since this in in the context of the Ephemeral-Static case.

The whole thing about RFC 2631 is an aside, not really a recommendation in the first place.

Therefore, I believe we should stay with the text I proposed on Thursday.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Monday, September 09, 2013 10:13 AM
To: Mike Jones
Cc: Brian Campbell; [email-masked]
Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs

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-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Thursday, September 05, 2013 5:21 PM
To: Mike Jones
Cc: Richard Barnes; jose issue tracker; <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs

jose mailing list

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Sep 2013 15:32:23 -0400

I guess I could live with that.  Just so we're clear, the text we're
talking about is:

"""
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.
"""

On Mon, Sep 9, 2013 at 2:02 PM, Mike Jones <[email-masked]>wrote:

>  As discussed on the call, the 512 bit entropy is redundant with the
> entropy already provided by the ephemeral key, and so is unnecessary.  The
> RFC 2631 text making it optional confirms this.  (It’s only there for the
> Static-Static case, which this isn’t.)  Given that it’s unnecessary and
> extra size, I can’t support a “SHOULD” for it.  The last sentence in your
> proposed text is redundant, since this in in the context of the
> Ephemeral-Static case.****
>
> ** **
>
> The whole thing about RFC 2631 is an aside, not really a recommendation in
> the first place.****
>
> ** **
>
> Therefore, I believe we should stay with the text I proposed on Thursday.*
> ***
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Monday, September 09, 2013 10:13 AM
> *To:* Mike Jones
> *Cc:* Brian Campbell; [email-masked]
>
> *Subject:* Re: [jose] #55: Mandatory entropy in ECC KDF inputs****
>
> ** **
>
> "ephemeral-static". ****
> Proposed text, with my changes in [[brackets]]:****
>
> """****
>
> using values that identify the sender and recipient.  [[ Otherwise, it is
> recipient.  ]]****
> On Thu, Sep 5, 2013 at 8:31 PM, Mike Jones <[email-masked]>
> wrote:****
>
> * **
> * **
> >> On Sun, Aug 11, 2013 at 6:56 PM, jose issue tracker ****
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 11 Sep 2013 12:55:06 -0600

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?