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

["Jim Schaad" <[e-mail]>]

 

 

From: Jim Schaad [mailto:[e-mail]] 
Sent: Tuesday, October 01, 2013 3:41 PM
To: [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