Subject: [jose] RFC7520 5.5 Clarification

From: Tommy Wang <[email-masked]>
Date: Thu, 3 Dec 2015 03:22:40 -0600

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.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 3 Dec 2015 06:08:30 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Tommy Wang <[email-masked]>
Date: Thu, 3 Dec 2015 12:04:57 -0600

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
<[email-masked]> 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.
>
>
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 3 Dec 2015 18:25:32 +0000

> On Dec 3, 2015, at 11:04, Tommy Wang <[email-masked]> wrote:
> 

The text says "in a manner similar to ... [RFC2631]" -- not that you use RFC2631.

> CEK?  If so, what were the supplied apu/apv values for the otherinfo

ConcatKDF is always used, as indicted in RFC 7518 § 4.6.

The apv and apu are not supplied, which therefore means the PartyUInfo and PartyVInfo should both be 0x0000, as indicated in RFC 7518 § 4.6.2.

You're getting some push back here because multiple implementations were involved in producing this document.  If these truly are wrong, then we've got at least a few implementation that are wrong.

--
- m&m

Matt Miller
Cisco Systems, Inc.