Re: [jose] Concat KDF

["Manger, James H" <[e-mail]>]

> PartyUInfo seems compliant with the letter of the SP800-56A.  SP800-56A
> doesn't place any constraints on the form or duration of the identifier
> ID_U, so the 512-bit value provided seems sufficient if you regard that
> as ID_U.

One aspect that has been confusing me is whether the recipient is expected to recognize ID_U as a known identifier for the originator, and ID_V as its own name?

Alternatively, do requirements on these items only apply to the originator? Is it completely safe for a recipient to treat ID_U and ID_V as opaque bytes to be hashed as part of the KDF, but with no other processing? Is it, in fact, safe for a recipient to treat OtherInfo (AlgorithmID + PartyUInfo +...) as an opaque blob, or even OtherInput (keydatalen + OtherInfo) as an opaque blob? In which case, we could simply include B64(OtherInput) in a JOSE message, perhaps with a suggested way an originator could construct OtherInput (eg from alg, enc, kid/jku, nonce).


> The better option would be to use the same KDF that CMS uses
> [RFC3278][SEC1].  It's simpler, and also complies with USG mandates
> (Suite B [RFC5008]).  If we use the RFC 5008 variant, it also takes as
> input exactly what the current JWS spec provides:
> 
> KM = Hash ( Z || Counter || ECC-CMS-SharedInfo )
> 
> ECC-CMS-SharedInfo = {
>     keyInfo, // The algorithm with which the key will be used,
> currently in AlgorithmID
>     entityUInfo, // The entropy source we're currently putting in
> PartyUInfo
>     suppPubInfo // The derived key length, currently in SuppPubInfo
> }
> 
> In other words, CMS does exactly what JWS wants to do now.  Let's just
> do it for real.  Proposed text for Section 4.7.1 of JWA:

Your proposal is "logically" the same as CMS (so same security properties), but the precise calculation is incompatible as you don't use a DER-encoding of ECC-CMS-SharedInfo. Just wanted to clarify this intention.

> """
> The key derivation process derives the agreed upon key from the shared
> secret Z established through the ECDH algorithm using the single-pass
> KDF defined in [SEC1].  The inputs to the key derivation process are as
> follows:
> 
> Z This is set to the representation of the shared secret Z as an octet
> sequence.
> 
> SharedInfo This is set to the concatenation of the following octet
> strings, in order:
>    1. The algorithm with which the derived key is to be used.  If the
> "alg" value is "ECDH", then this field contains the value of the "alg"
> parameter.  Otherwise, it contains the value of the "enc" parameter.

Wrong way around. If "alg" is "ECDH" use "enc" value, otherwise use "alg" value.

You also need to separate this field from the next: with a length prefix, or separator char/byte.
With 2 variable-sized fields (algorithm and apu) you only theoretically need 1 length field to be unambiguous, but it needs to be at the start or end, not in between the 2 fields.

>    2. The length of the value of the "apu" parameter, as a 32-bit big
> endian integer.  If the "apu" parameter is not present, then this field
> is set to all zeros (0x00000000).
>    3. The value of the "apu" parameter, if present.  If provided, this
> value MUST contain at least 512 bits and a unique value SHOULD be used
> for each recipient.  The "apu" parameter MAY be omitted only if a
> different ephemeral key is used for each key agreement transaction.
>    4. The length of the derived key, as a 32-bit big endian integer.
>  For "ECDH-ES", this is length of the key used by the "enc" algorithm.
>  For "ECDH-ES+A128KW" or "ECDH-ES+A256KW", it is 128 (0x00000080) or
> 256 (0x00000100), respectively.

Symmetric key lengths are hardwired into "alg" and "enc" values in JOSE (eg "A256KW", "A128CGM") so we don't actually need a separate field.

> """
> 
> Two side notes:
> 1. We need hash agility here (as in RFC 5008) to be able to meet higher
> levels of security for which SHA-256 is unacceptable.  Suggest adding
> hash algorithms to the ECDH algorithm identifiers, e.g., "ECDH256",
> "ECDH284+KW".

"ECDH256", "ECDH256+A128KW", "ECDH384", "ECH384+A192KW"?	

> 2. The "-ES" is unnecessary, since the entropy added in entityUInfo is
> sufficient to address both ES and SS cases.


--
James Manger