A few more observations on ConcatKDF…
Revision 2 of NIST 800-56A has just been published. JOSE should probably
reference this update. The text about identifiers for parties is slightly
better (section 4.1 “Key establishment Preparations”), but it still isn’t
explicit about whether senders and/or receivers are responsible for validating
AlgorithmID/PartyUInfo/PartyVInfo/SuppPubInfo/SuppPrivInfo.
Including a key owner’s name in a KDF calculation is going to be awkward for
JOSE given it really leaves those details to higher layers, but it is necessary
for interoperability if we use ConcatKDF.
Jim’s scheme might work. The recipient’s static ECDH key is assumed to come
from a JWK that has an “ID” field.
Example: {"kty":"EC","crv":"P-521","kid":"537352","ID":"alice","x":"…","y":"…"}
If the “ID” field is absent but a “x5c” field is present, it might be easier to
use the whole certificate (instead of the DER-encoded subject name) as
PartyVInfo. It means the code doing the ConcatKDF calculation doesn’t need to
decode DER. It does mean that a recipient’s key MUST be associated with an “ID”
or “x5c” field to use ConcatKDF.
“ID” might not be such a good name as it is too easy to confuse with “kid”.
Perhaps “owner”?
The originator of a JOSE ECDH message contributes an ephemeral key and is not
authenticated so giving them a name feels unnecessary (or actively misleading).
How about fixing PartyUInfo to be “anonymous” for the ECDH Ephemeral-Static
algorithms?
[It’s a pity we don’t have a canonical form of JSON so we could describe the
ConcatKDF OtherInput field as a JSON object — instead of needing to make up an
ad hoc binary format.]
ConcatKDF in the XML encryption standard
[http://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF] has separate XML attributes
for AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo.
Unfortunately the fields are concatenated together without preserving their
boundaries. Hence it looks broken to me. There were some recent interop test
cases from Microsoft and IBM for ConcatKDF in XML encryption. The KDF parts
work, but the associated CBC encryption looks wrong as it is missing some
padding. It doesn’t give much confidence that ConcatKDF is used much.
[http://lists.w3.org/Archives/Public/public-xmlsec/2013Jun/0005.html]
--
James Manger
From: [email protected] [mailto:[email protected]] On Behalf Of Jim
Schaad
Sent: Monday, 24 June 2013 9:11 AM
To: 'Mike Jones'; 'Russ Housley'
Cc: [email protected]
Subject: Re: [jose] Concat KDF
I have been thinking about this and I am going to make a different proposal.
The proposal is as follows:
1. We eliminate the two partyX fields from the specification
2. We define a new “ID” field which MUST be present for ECDH keys.
3. We say that you take the ID field from the sender/recipient
respectively and use them in the PartyX fields when doing the KDC.
The only down side of this, is that if one has a certificate then we should use
the DER encoded subject name of the certificate but I am not sure how this
would be encoded in the case you have a JWK which contains an x5c member. It
might be that we will need to defined an ID and an IDb64 field to allow for a
binary ID to be used.
There would still need to be a requirement that the ID field be length prefixed
in the discussion.
Jim
From: [email protected] [mailto:[email protected]] On Behalf Of Mike
Jones
Sent: Sunday, June 23, 2013 2:57 PM
To: Russ Housley
Cc: [email protected]
Subject: Re: [jose] Concat KDF
Good idea, Russ. How about this?
“In the general case, the specific identifiers used to tie the key derivation
to the sender (Party U) and the receiver (Party V) are application specific and
beyond the scope of this specification. As an illustration of one possible
usage, when the JWE is a JSON Web Token (JWT) [JWT], applications might specify
that the “iss” (issuer) value be used as the “apu” value and the primary “aud”
(audience) value be used as the “apv’ value.”
-- Mike
From: Russ Housley [mailto:[email protected]]
Sent: Sunday, June 23, 2013 7:43 AM
To: Mike Jones
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [jose] Concat KDF
Mike:
I can add a sentence along the lines of the following to make Jim’s points
below clearer to non-expert readers:
“The specific identifiers used to tie the key derivation to the sender (Party
U) and the receiver (Party V) are application specific and beyond the scope of
this specification.”
I see the attraction of this approach, but I wonder if it would be possible to
also include some advice to applications that make use of JOSE.
If the parties that are trying to form a pairwise key make different
assumptions, then we do not get interoperability. I am just trying to improve
the likelihood of interoperability.
Russ
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
