#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: [email protected] [mailto:[email protected]] On Behalf Of Jim
Schaad
Sent: Saturday, October 26, 2013 4:43 PM
To: [email protected]
Subject: [jose] FW: FW: Issue #54, #55, #141
I have not seen comments on this
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Monday, October 07, 2013 5:01 PM
To: [email protected]<mailto:[email protected]>
Subject: [jose] FW: Issue #54, #55, #141
From: Jim Schaad [mailto:[email protected]]
Sent: Tuesday, October 01, 2013 3:41 PM
To: [email protected]<mailto:[email protected]>
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
