Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

Ludwig Seitz <> Tue, 27 August 2019 06:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5901B120DB8; Mon, 26 Aug 2019 23:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WOTwSyaxqJuV; Mon, 26 Aug 2019 23:52:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A24E120D6A; Mon, 26 Aug 2019 23:52:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=kXKO7mTMiB3pjpUE3/zy/GPneFyVYHwwdyOxgAfSXAQMdePPNs3njXBwe8wYvxPiaQCTGKge6DgCDGkS8kgq5nQj2ce7rMTINgzF28D2skTT1ayiHac4SbY11+8gfwc+X5XZ7CJAzPtS0tSMvbws8J47su8WQ3hESJTMWvOSPwEKLSVt5LOSWwtRldtoAJvUISJSkZ3za0ltysiSdmJr7s78D6ds+cpVOSOL9QVtKy2gIF+X9IRpVQusqPf2ztDWponBQP9DbqQ0X7ziHQ+oPsA4UQz/4DBJ45NR7mK9GWmyiNnUrNFC93vjNH9lWzoNpCuQD/tyVK1ugu6Nv1yUpg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBg1GI8FCLpMscdW2J9HqNEUHrSn9/GG3bQ9x6CfDS8=; b=KLXVOOXoc1IBYreslZ6eOqaiLoEFF/xUs/A9xPA9geI8EvXzc1SSgSnIflbJtAyGG2ftxddX6E+CgH3BwmRmhi83ShJ56/9vbT91zeNMKqmtAaF0MWP+uLkfMCn6ByqXVL1aRt3ma1FBBL0JT6c3y3dvauLhI3RfGhEO15/cczhSyMd9w8mvm6b4jO0dUmZpoc3p+ERvyZbFKfx3cZsukah6asZiyCwBjYWBLJuTd2yd2poIS17ywJXdI/WcsIyPt59V7O8bWLQeAaTDFmDeXrXWoYDZSdQibzle/5NWhnV5CVg6xMkFsz46HujC4nxbPnPKRe3O22vCeaNiPBUGNQ==
ARC-Authentication-Results: i=1; 1; spf=pass (sender ip is; dmarc=pass (p=none sp=none pct=100) action=none; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBg1GI8FCLpMscdW2J9HqNEUHrSn9/GG3bQ9x6CfDS8=; b=XeeLc5mLHXkpRQeLa/zB/3dAMQo669gz6jVYVL8oC36kMWWphq14ax4KKfoVKSNUmy7GeUWVVVbQ0uiUMewNBrkfjKhpSgRSzaM60+OPYijOsYf5RPwg52RUSa4sAG8carfWbimyJlISXYrxcDfFNoNGCW8mEKCi1hYtTznwbI4=
Received: from VI1P18901CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:801::20) by AM7P189MB0757.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:114::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Tue, 27 Aug 2019 06:52:25 +0000
Received: from (2a01:111:f400:7e05::208) by (2603:10a6:801::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.15 via Frontend Transport; Tue, 27 Aug 2019 06:52:25 +0000
Authentication-Results: spf=pass (sender IP is;; dkim=none (message not signed) header.d=none;; dmarc=pass action=none;
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2199.13 via Frontend Transport; Tue, 27 Aug 2019 06:52:24 +0000
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 27 Aug 2019 08:52:23 +0200
To: Jim Schaad <>, 'Benjamin Kaduk' <>
CC: <>, <>
References: <> <> <> <> <00dc01d55c28$5860e510$0922af30$>
From: Ludwig Seitz <>
Message-ID: <>
Date: Tue, 27 Aug 2019 08:52:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <00dc01d55c28$5860e510$0922af30$>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040102000403000107040704"
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(396003)(346002)(2980300002)(199004)(189003)(14444005)(86362001)(7736002)(5660300002)(305945005)(186003)(16526019)(31686004)(2171002)(2906002)(5024004)(4326008)(356004)(36756003)(16586007)(235185007)(106002)(336012)(476003)(81156014)(8676002)(44832011)(76176011)(229853002)(22746008)(6246003)(126002)(8936002)(40036005)(486006)(2616005)(568964002)(22756006)(446003)(11346002)(478600001)(26005)(53936002)(3846002)(316002)(6116002)(58126008)(81166006)(31696002)(70586007)(110136005)(53546011)(70206006)(386003)(54906003)(16576012)(65806001)(6306002)(66574012)(65956001)(33964004)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P189MB0757;; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d02596ce-967e-486b-2e2d-08d72abb1e40
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(4709080)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM7P189MB0757;
X-MS-TrafficTypeDiagnostic: AM7P189MB0757:
X-Microsoft-Antispam-PRVS: <AM7P189MB0757C09D2D88648F205BFF8082A00@AM7P189MB0757.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0142F22657
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: cRdpDbQNABGITcO6KZcigvY1BRaHXOrIId3HDqRievLgqweUeVILuDAL6EO+h5di+Qle9dmp/rmuejGqx26hxkv9uhT7FfwKHnmw4hhBwIpGsxo9BO8SHWhPvd6c5gBk9t0/oIm3f2Go2e24ecljp8FHCZ/8c/8ayjRpLuR/p/GpOeobkPsw/Egz7JZCSYiADa0wBd8DKF4v7ppcifwyCtNj4xjjyzmF9jVn8JJEz5d5zzZQzXBXFyPwgaIO4QlTui5B80WjKTUuJQt67UVn89b5nfnmIYh0s7XQGHAPQ2VUVCqQVQD/ANr5XiZrsrGmPvf+/NQtHY2AY6MaF95bV2pMVobuWBP5Nueto9KLQ0cu6qf8JpZ1If041rWSfXmJenT0OapjktmuNyoMKRMjaHHanixQL0uJ1eHmOZQBDPs=
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2019 06:52:24.9006 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d02596ce-967e-486b-2e2d-08d72abb1e40
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[]; Helo=[]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P189MB0757
Archived-At: <>
Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2019 06:52:33 -0000

On 26/08/2019 18:07, Jim Schaad wrote:

> On 13/08/2019 01:15, Benjamin Kaduk wrote:
>>>> The "COSE_Key" member MAY also be used for a COSE_Key
>>>> representing a symmetric key, provided that the CWT is
>>>> encrypted so that the key is not revealed to unintended
>>>> parties.  The means of encrypting a CWT is explained in
>>>> [RFC8392].  If the CWT is not encrypted, the symmetric key MUST
>>>> be encrypted as described in Section 3.3.
>>>> It's hard for me to escape the conclusion that this paragraph
>>>> needs to be a dedicated section with a bit more discussion
>>>> about how exactly this usage is performed and encoded.
>>> This mirrors the corresponding procedure in RFC 7800. Would it be
>>> OK to just refer to that document 
>>> ( or actually 3.3)?
>> (Section 3.2, it seems -- JWT and CWT cover aysmmetric and
>> symmetric in the opposite order.) Well, I still wouldn't like it.
>> But I don't think I have grounds to block the document from
>> advancing if you just refer back to JWT.
> Göran and I have discussed this, and we agree that it is indeed 
> underspecified (e.g. which key is used to encrypt this "inner" 
> COSE_Encrypt0 contained in the cnf element?). Additionally I can 
> personally confirm that this is a headache to implement (and I
> haven't even touched a constrained implementation).
> [JLS]  I am not sure that I understand why you believe that this is
> underspecified. 

Because the AD said so ;-)

Seriously: I believe that this warrants more text, since it must be at 
least clarified that this construct assumes two pre-configured keys 
shared between AS and RS: one for encrypting the inner cnf element and 
one for integrity protecting the whole CWT.

> Despite the fact that I have not implemented this, I
> do not believe that it would be all that problematic to implement in
> general, and would be even easier to implement in a constrained
> system as only one format of CWT should ever be expected by a single
> small device so that the structure can be hard coded.

Perhaps 'headache' was a hyperbole on my part, but there is definitely a 
code-complexity difference between "parsing CBOR" and "parsing CBOR, 
interrupt the parsing to decrypt stuff, continue parsing CBOR".

> [JLS] There is a potential case for the first of those options,
> having different authority servers that are passing things back and
> forth and a desire to do validation that the correct permissions
> exist.  That is the client AS sends a request to the Resource AS
> which creates a token for the RS and the client AS wants to double
> check the permissions granted to the client.  But I have not heard
> that anybody is planning to do such an implementation yet.  So far
> everybody is combining the two AS roles into a single system.  If you
> are ever in the second case, I would argue that you are better off
> using asymmetric keys all the way around.

I can see this use case. That rules out my option 1. of removing this 


Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51