[jose] RFC7520 5.5 Clarification

[Tommy Wang <[e-mail]>]

I am referencing the last paragraph of 4.6.2 of RFC7518:

"Alternatively, applications MAY conduct key derivation in
a manner similar to "Diffie-Hellman Key Agreement Method" [RFC2631]:
in that case, the "apu" parameter MAY either be omitted or represent
a random 512-bit value (analogous to PartyAInfo in Ephemeral-Static
mode in RFC 2631) and the "apv" parameter SHOULD NOT be present."

Given that the example in RFC7520 section 5.5 does not provide an apu
or apv, I had guessed that the DH Key Agreement method was used to
generate the derived key, rather than ConcatKDF.

I was able to verify the example in Appendix C of RFC7518 using the
ConcatKDF key derivation where apv/apu were specified.

ECDH was used to arrive at a shared secret in both cases.

Do the examples in RFC7520 section 5.4/5.5 use ConcatKDF to derive the
CEK?  If so, what were the supplied apu/apv values for the otherinfo
generation?

On Thursday, December 3, 2015, Brian Campbell
<[e-mail]> wrote:
>
> Take a look again at http://tools.ietf.org/html/rfc7518#section-4.6, which defines JOSE's ECDH-ES key agreement. A couple things of note are that it references RFC6090 (not RFC2631) and ConcatKDF key derivation is always done on the shared secret established through the ECDH algorithm.
>
> The Example ECDH-ES Key Agreement Computation at http://tools.ietf.org/html/rfc7518#appendix-C might also be useful.
>
>
>
> On Thu, Dec 3, 2015 at 2:22 AM, Tommy Wang <[e-mail]> wrote:
>>
>> Looking for some guidance on how the ECDH-ES Key Agreement (5.5.2)
>> derived the CEK:
>>
>> hzHdlfQIAEehb8Hrd_mFRhKsKLEzPfshfXs9l6areCc
>>
>> No apv/apu values were provided leading me to believe that it was not
>> derived using ConcatKDF.
>>
>> I tried to implement via D-H Key Agreement (RFC2631) with no
>> partyAInfo but was not able to arrive at the same CEK.
>>
>> I used the following OIDS:
>>
>> OIDS = {
>>     'A128CBC-HS256': '2.16.840.1.101.3.4.1.2',
>>     'A192CBC-HS384': '2.16.840.1.101.3.4.1.22',
>>     'A256CBC-HS512': '2.16.840.1.101.3.4.1.42',
>>     'A128GCM': '2.16.840.1.101.3.4.1.6',
>>     'A192GCM': '2.16.840.1.101.3.4.1.26',
>>     'A256GCM': '2.16.840.1.101.3.4.1.46',
>> }
>>
>> And the following pyasn1:
>>
>> from pyasn1.type import univ, namedtype, tag, constraint
>> from pyasn1.codec.der import encoder
>> import hashlib
>>
>> class Counter(univ.OctetString):
>>     subtypeSpec = constraint.ValueSizeConstraint(4, 4)
>>
>> class KeySpecificInfo(univ.Sequence):
>>     componentType = namedtype.NamedTypes(
>>         namedtype.NamedType('algorithm', univ.ObjectIdentifier()),
>>         namedtype.NamedType('counter', Counter())
>>     )
>>
>> class OtherInfo(univ.Sequence):
>>     componentType = namedtype.NamedTypes(
>>         namedtype.NamedType('keyInfo', KeySpecificInfo()),
>>         namedtype.OptionalNamedType('partyAInfo', univ.OctetString().subtype(
>>             explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0)
>>         )),
>>         namedtype.NamedType('suppPubInfo', univ.OctetString().subtype(
>>             explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2)
>>         ))
>>     )
>>
>> def km(alg, zz, n):
>>     oid = OIDS[alg]
>>     ainfo = None
>>     pinfo = 128
>>     k = KeySpecificInfo()
>>     k.setComponentByName('algorithm', oid)
>>     k.setComponentByName('counter', struct.pack('>I', n))
>>     o = OtherInfo()
>>     o.setComponentByName('keyInfo', k)
>>     o.setComponentByName('suppPubInfo', struct.pack('>I', pinfo))
>>     o = encoder.encode(o)
>>     return hashlib.sha1(zz + o).digest()
>>
>> zz was derived using cryptography's EC key exchange.
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>
>