Re: [jose] RFC7520 5.5 Clarification
Brian Campbell <bcampbell@pingidentity.com> Thu, 03 December 2015 13:09 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E531A6FF9 for <jose@ietfa.amsl.com>; Thu, 3 Dec 2015 05:09:03 -0800 (PST)
X-Quarantine-ID: <WDpKD8y85KZr>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/html,.exe
X-Spam-Flag: NO
X-Spam-Score: -0.072
X-Spam-Level:
X-Spam-Status: No, score=-0.072 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDpKD8y85KZr for <jose@ietfa.amsl.com>; Thu, 3 Dec 2015 05:09:01 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D8E1A6FDB for <jose@ietf.org>; Thu, 3 Dec 2015 05:09:01 -0800 (PST)
Received: by iouu10 with SMTP id u10so81690688iou.0 for <jose@ietf.org>; Thu, 03 Dec 2015 05:09:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bYtaHhfXFuFn2eqJIVCMCCQ3q8xvkm9eabZgSDX5LWk=; b=M+IlWAPii/9SkdgBs/1ILCHSiHKbXNPrxiHkze2NLlVezfTggcPU/F4JN1RQ8aUvvx ncDxyglQavPHX2Yk/ZEFu0cshLKvceLg83amKkiAuoprIlqNqrv3zf0Ee2T3c/KL2VNH rpS/t3iIL5+vx22CwvgN1k6GzTe+iIqALfSrg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bYtaHhfXFuFn2eqJIVCMCCQ3q8xvkm9eabZgSDX5LWk=; b=PFH/kis8N0j/AeefwiObXyj2bN8WSeGVUdcuuZxRcYiZuPsuux+pyv5MreWiqu1dWX p+Eb2EL0ynMIeZtamAFoobdu8DpRuB+lQDH/+ZzJtouOtI7DZLKEqjTx2DeWgBE8+yIL ckKg6tQN+XGBeHF31OPiqvruY7Au9WjjcRsnSaB8S5/5YzMQaEfXrI9u/lhby+cNf2+M 4Uvdt5q8xAxGsO6a/zTHtEgnhPg95iS1pf+ndOxMbU4FZ+i8zJpPSne9D3qGRwiMhhFH mF7aegQ0FVwtDAf1gFFPVXRrOAdEpIYPAJcYV0D5vAkr2r9lo+QLFwCYR89GS7PNYmH6 SMag==
X-Gm-Message-State: ALoCoQmu6TgFNczKgWPMTIKF/DjhEGzSoLErWbOOR+7bRm2I8zeA7O2MIEcWinJcSyKSto1aEgJT
X-Received: by 10.107.158.213 with SMTP id h204mr10739520ioe.129.1449148140400; Thu, 03 Dec 2015 05:09:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.23.133 with HTTP; Thu, 3 Dec 2015 05:08:30 -0800 (PST)
In-Reply-To: <CAFeYy0O1+EBSAv5ueqOuHFe6=0A_g6_7W=t3ZjK8FWO5rzRFrA@mail.gmail.com>
References: <CAFeYy0O1+EBSAv5ueqOuHFe6=0A_g6_7W=t3ZjK8FWO5rzRFrA@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 03 Dec 2015 06:08:30 -0700
Message-ID: <CA+k3eCTdfb66R2Ph0wREM1w=TSs7V9ccxz5OhkPgnfcyLVtOzA@mail.gmail.com>
To: Tommy Wang <lists@august8.net>
Content-Type: multipart/alternative; boundary="001a114075c222cdc20525fe1836"
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/PkbX-93UAHZEkhYLZodo9xoOfL4>
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] RFC7520 5.5 Clarification
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2015 13:09:03 -0000
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 <lists@august8.net> 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 > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >
- [jose] RFC7520 5.5 Clarification Tommy Wang
- Re: [jose] RFC7520 5.5 Clarification Brian Campbell
- [jose] RFC7520 5.5 Clarification Tommy Wang
- Re: [jose] RFC7520 5.5 Clarification Matt Miller (mamille2)