Re: [jose] FW: FW: Issue #54, #55, #141

[Mike Jones <[e-mail]>]

#54:  Richard had agreed to close this as "wontfix" and this was confirmed on the last call.  Please close this one.

#55:  The working group text discussed on the list has been incorporated in the drafts.  Please close this one as "fixed".

#151:  Per our discussion during our last meeting in my office, our use of Concat is specific to ECDH key agreement - and not intended to general-purpose.  Concat is already described in a general-purpose way in NIST 800-56A so we don't need to repeat that description in JWA.  Given that the technical issue of giving the algorithm name a length prefix has been addressed, I believe that it's time to close this one as "fixed" (which I think you agreed to do in my office, after the length prefix was added).

There is also already text saying how to achieve the same effect as RFC 2631 in a note.  Thus, I believe that all these issues have already been addressed.

                                                                -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Saturday, October 26, 2013 4:43 PM
To: [e-mail]
Subject: [jose] FW: FW: Issue #54, #55, #141

I have not seen comments on this

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Monday, October 07, 2013 5:01 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [jose] FW: Issue #54, #55, #141



From: Jim Schaad [mailto:[e-mail]]
Sent: Tuesday, October 01, 2013 3:41 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Issue #54, #55, #141

There are four issues that need to be addressed with respect to the concat section of the JWA draft.  There is some agreement for these issues but I am not totally happy with what is being done here and would like to see some changes.  This message describes the changes that I would like to see.

The current set of open issues in the tracker are:

Issue #54 - epk/apu/apv need to be REQUIRED
Issue #55 - Mandatory entropy in ECC KDF inputs
Issue #151 - Section 4.7.2 Concat should have its own section
No Tracker Item - The concat usage should be consistent with that of the CMS DH document RFC 2631


I don't like the current text which says that the partyU name can be either a name or a nonce value.  While it is true that both are not needed for the ES version of the key derivation function, this will not be the case for a SS version of using concat.  I would like to make sure that this is a doable thing without having to do massive re-writes.  I therefore propose the following changes:

Add a new section

4.7.1.4 "nonce" Header Parameter

The "nonce" value for a key derivation algorithm.  This parameter is REQUIRED to be used when a static-static key agreement method is used and MAY be used for other key agreement methods.  The value MUST be generated freshly for each key derivation done.  The member value contains the base64 encoded nonce value.  The length of the nonce value needs to be sufficient that it will not be duplicated for the pair of keys being used.  If the uniqueness is generated pseudo-randomly, then it should be a minimum of 512 bits long.

Change the way that PartyUInfo is defined in section 4.7.2 as follows:

PartyUInfo  The PartyUInfo value consists of the partyU name and, when present, the nonce field.  Both fields are encoded as Datalen || Data, where Datalen is a 32 bit value containing the size of the field in bits as a big-endian integer and Data is the value of the field.

      PartyUInfo = I4(partyU name.length) || partyU name
      If nonce.length > 0 then PartyUInfo = PartyUInfo || I4(nonce.length) || nonce


Replace the last paragraph with



The "apu" and "apv" parameters MUST contain distinct values so that the same key would not be generated if the KDF is done for the opposite direction.  Applications can change the default values for these parameters in order to make the keys generated for that application different from other applications.



My reading of the NIST document which we are using for concat says that the partyU name and partyV names are required to be defined, however they can be defined by the protocol and not by the actual parties themselves.  This means that it is possible that the parameters can have values, without them being transmitted as part of the message.  In fact they should be removable by the application and not transmitted.  I don't know that we need to make that an explicit statement in the text or not.  (I have chosen not to do so in this change, but it can be discussed.) Based on this understanding I would like to modify the text in the following ways.


Change the way that PartyUInfo and partyVInfo are defined in section 4.7.2 as follows:

Old:

If an "apu" (agreement PartyUInfo) header
      parameter is present, Data is set to the result of base64url
      decoding the "apu" value and Datalen is set to the number of
      octets in Data.  Otherwise, the Datalen is set to 6 and Data is set to the UTF-8 encoded string "Sender".

For apv replace "Sender" with "Recipient"



In order that the concat description be available for other key agreement algorithms (i.e. ES-DH or SS-ECDH) I really would like to see it described as a separate algorithm that is then referred to from the ES-ECDH algorithm description.  This means that apu, apv and nonce would be defined as being CONCAT parameters and not be defined as ES-ECDH parameters.   This can be discussed and I can provide the alternate text if it makes sense to do so.

Jim