These changes have been applied in the -12 specs.
-- Mike
From: Mike Jones
Sent: Tuesday, June 18, 2013 11:10 AM
To: Manger, James H; Russ Housley; Jim Schaad;
[email protected]<mailto:[email protected]>
Subject: RE: Concat KDF
Thanks for the careful read, James. Replies inline marked "Mike>"...
-----Original Message-----
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Manger, James H
Sent: Sunday, June 16, 2013 6:20 PM
To: [email protected]<mailto:[email protected]>
Subject: [jose] Concat KDF
The use of the Concat KDF still does not look right.
JWA [draft-ietf-jose-json-web-algorithms-11] section 4.7 says "ECDH-ES" uses
Concat KDF from NIST 800-56A section 5.8.1. NIST defines 5 fields that go into
the key derivation: AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and
SuppPrivInfo.
NIST says AlgorithmID indicates the algorithm that will use the derived key.
JWA says to use the "alg" value (eg "ECDH-ES") as the AlgorithmID. AlgorithmID
should actually be the "enc" value when the derived key is used directly as a
CEK.
Mike> I can change the draft to use the "enc" value in the direct agreement
case, unless people object.
When the derived key unwraps the CEK, AlgorithmID should be the name of the key
wrap algorithm (eg "A128KW"). Perhaps the "alg" value can be used in this case
as it identifies the key wrap algorithm along with the key establishment
algorithm (eg "ECDH-ES+A128KW").
Mike> Agreed - so there is no change needed to the AlgorithmID for the
agreement with key wrapping case.
NIST says PartyUInfo includes an identifier for party U. The first problem is
that JWA does not indicate if the sender or receiver is party U (nor does JWE).
The second problem is that JWA says PartyUInfo is random -- which seems to
totally defeat the purpose of being an identifier for a party. JWA says
PartyUInfo should vary for each recipient, which suggests PartyUInfo cannot be
an id of the sender. Does that suggest the receiver is party U?
Mike> The sender is Party U. I'll say so in the draft. (This is parallel to
RFC 2631's partyAInfo, which is also supplied by the sender.)
NIST says PartyVInfo is required and includes an identifier for party V. JWA
says PartyVInfo is empty, which obviously cannot meet the NIST definition.
Mike> This was discussed at the in-person working group meeting in Denver and
Jim Schaad stated that I should modify the Key Agreement parameters to mirror
their use in RFC 2631, which I therefore did. Jim, Russ, and James, can the
three of you (and other interested working group members) please make a
decision among the three of you about text to include about PartyUInfo and
PartyVInfo? If you don't reach an agreement, one option is for me to add a
note to the spec that PartyUInfo is used in the same manner as PartyAInfo of
RFC 2631 and that since RFC 2631 doesn't have an equivalent of PartyVInfo, none
is used here either. The other option is to go back to the "apu" and "apv"
language of http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10 -
adding that the sender is Party U and the receiver is Party V. Comments?
The JWA values for SuppPubInfo (length of derived key in bits) and SuppPrivInfo
(empty) are in line with the NIST definitions.
It appears the Concat KDF text in JWA has been rewritten based on RFC2631
"Diffie-Hellman Key Agreement Method". RFC2631 is not referenced by JWA, but it
is mentioned in the "document history" section (which will eventually be
deleted). RFC2631 has items such as partyAInfo and suppPubInfo whose names are
similar to NIST items. However, RFC2631 was published 7 years before NIST
800-56A (and 13 years before the current version of NIST 800-56A) so RFC2631
cannot be used as a example of how to use Concat KDF.
As I stated above, if we keep the current PartyUInfo/PartyVInfo usage, I will
explicitly add text saying that the usage of these fields is taken from RFC
2631.
--
James Manger
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
-- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
