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

Mike Jones <> Mon, 26 August 2019 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CE52120D4C; Mon, 26 Aug 2019 12:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 0ZXEJ33h0Gm4; Mon, 26 Aug 2019 12:32:54 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe55::70c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 877C2120CAA; Mon, 26 Aug 2019 12:32:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=jjKVnPdwuGmJY1/d1Y3525moeaQ37NkNP2jr/8DXtWkrirmA/Qx/OwIGy0sfckaX6o8/qY+fY7bgLIRZgZtQAkquh3rTU98edDZqTwwngoJj0N9IKwy52Q28qE5cfkR1o1UiG1T0qpsLBEKG7tEIleHXu19i5r99XFGY2HZG3WwfT0tbmHWUkW5Aj9xZtQO9/1fPzFNcJhsByMc1fFexiiGGXwZ9GgubW4AftkkH1DPsV7nggT7UwuCk8FCZ/6KdiJHKtU5eoFhctexrIc0j0jIApi5f33FyaNngxAHMOLh6MpYZHbhf3IUpFAdPqVxJCKE0YLEWqwhjcNsUy3Hldw==
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=9gQZZ08CKvo2wPion08khP7gH73D3geIvApfotkzEak=; b=hrzjdVnsZffW4wanV2cBkgObXPxZnHRira2q2Uykozxj+aYVkF/IBi5fndGCz49UQODhXjDX1DYvZ9X7UfUylRtNisOsHKwD3C9kws1DBgmuVNSHo3ccu92RVCcdgQUnZtajWmeRv5ma4ocp7UUqaWhG5xPo8uwtfvliIbg4FFg+TkscI/Q378Fdrvaa+6AD1qZU/67Dnx6Ip0yglqhn7iMg9lnn9inMqf/+mNxg+5x3e5we1gqJ3SK92hLTqU4M2VZBaPBS9/tIcoznLSUvYRS3D5heU17D2uKTA8F3G7Yh4vkes4go5vftfTL0ivb2iXK4CARpVuS/30ZqAh+Jew==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9gQZZ08CKvo2wPion08khP7gH73D3geIvApfotkzEak=; b=Vh92hiDTo/Z1K1DAiqKEbnfLRZ2GVlFhsToIZ2xDJIeS5iCJmRFdnMhhBaKFFQI/zBKav8HpFnxvDMzh2TfvVKoFoZ01memvZlNIFYP1r4TdEa56mGiBcb60Fe21tvGKh7kMbrhaPngZcdq9bs0mHbosam7GW2CyKHqU5V8Slas=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2247.0; Mon, 26 Aug 2019 19:32:51 +0000
Received: from ([fe80::a528:2b96:5985:afa5]) by ([fe80::a528:2b96:5985:afa5%2]) with mapi id 15.20.2252.000; Mon, 26 Aug 2019 19:32:51 +0000
From: Mike Jones <>
To: Ludwig Seitz <>, Benjamin Kaduk <>
CC: "" <>, "" <>
Thread-Topic: AD review of draft-ietf-ace-cwt-proof-of-possession-06
Thread-Index: AQHVW9kaB1+XuR4ZckeQMuWF4nKDoKcN0lBw
Date: Mon, 26 Aug 2019 19:32:50 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=90250857-2a8b-4684-bddf-0000d6de693b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-08-26T19:32:33Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 507c3b4c-3544-4fc8-919e-08d72a5c2f0c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MN2PR00MB0591;
x-ms-traffictypediagnostic: MN2PR00MB0591:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(136003)(396003)(39860400002)(346002)(13464003)(199004)(189003)(22452003)(8936002)(66066001)(71200400001)(71190400001)(316002)(256004)(81156014)(8676002)(14444005)(81166006)(8990500004)(486006)(11346002)(446003)(33656002)(7696005)(76176011)(99286004)(86362001)(186003)(6506007)(476003)(102836004)(26005)(53546011)(66574012)(2906002)(9686003)(6306002)(55016002)(229853002)(6436002)(74316002)(10290500003)(5660300002)(966005)(478600001)(14454004)(52536014)(66946007)(4326008)(66446008)(305945005)(66476007)(66556008)(64756008)(6116002)(3846002)(7736002)(76116006)(25786009)(2171002)(10090500001)(6246003)(54906003)(110136005)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0591;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: UIYvqoafpXMBGvaAIzXxig2BvaYOZomEwVykyNOHiGHdXVy90Hu0PcLdtoljjsG4TrUzn6GZwx+VVJ2SAEnm/x9l7PAnABqmMP4MM/b6TIkNskYf9EBA4di6tAOR0K/t6p2tUpcJsDRMYO5j5PCbPQNzW03O+SmKu3BEQHYJaCBdIbVzo4pHibyxWLzcZzMUtKaRUs9o6180CxM2Vzq4K8QbF5ziFol5NKOgdFn6IJuw4Pe2haGo7C9Eq5jkROt+GFuECiM8EOBx0rG7lbhfcFK2gnphdXARz1GvhlFa6/GnBldRb8JICas/7Ljs2+K4jai1CVz/Y22LzbN1tsddPeGXJzTMG0B0wqyd5zP4cvgUvk2U/ETixi9PyWEp8KBI4fgZKOHL3BRU499xEN0h8jmZPlvOazt4VcP+I3Q4Sk0=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 507c3b4c-3544-4fc8-919e-08d72a5c2f0c
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 19:32:50.8546 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EI6sUYaYnChiF5sShHp6dWJjYhuxYeOsPwDClM1qg/3j9DiMuaWLmgev116XaChjj4ZSI2tBLO7ogp9PZtW0Ng==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0591
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: Mon, 26 Aug 2019 19:32:58 -0000

Please see my review of the PR, Ludwig.

-----Original Message-----
From: Ludwig Seitz <>; 
Sent: Sunday, August 25, 2019 11:40 PM
To: Benjamin Kaduk <>;
Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06

Hi Ben,

fixed more of your comments here: 
(waiting for Mike to double-check and merge them).

As for those that are still open, comments are inline.


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).

We see two alternatives here:

1.) Remove the possibility to have a separate encrypted cnf element. 
Instead mandate that the whole CWT should be encrypted if it contains a 
secret key.

+ make spec easier (to implement) and doesn't requires a long 
specification on how to handle this case

- breaks direct equivalence with RFC 7800

2.) Add some dedicated section that explains how the key for this inner 
encrypted cnf element is selected and communicated to the RS.

+ The draft remains functionally equivalent to RFC 7800

- Increased draft complexity at questionable gain
- Possible implementer headaches, especially on constrained devices

There is an issue about this here:

>>>      The following example CWT Claims Set of a CWT (using CBOR diagnostic
>>>      notation, with linebreaks for readability) illustrates the use of an
>>>      encrypted symmetric key as the "Encrypted_COSE_Key" member value:
>>>     {
>>>      /iss/ 1 : "coaps://",
>>>      /sub/ 2 : "24400320",
>>>      /aud/ 3: "s6BhdRkqt3",
>>>      /exp/ 4 : 1311281970,
>>>      /iat/ 5 : 1311280970,
>>>      /cnf/ 8 : {
>>>      /COSE_Encrypt0/ 2 : [
>>> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
>>> [I did not validate the COSE_Encrypt0 output]
>> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
>> is not. We'd have to define it or write an explanatory comment.
> Maybe I'm confused about how the diagnostic notation works, but the
> top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches
> iss/sub/aud/etc. in the preceding notation.  If the rules are different for
> map keys whose corresponding values are themselves structured data types,
> then I should just unconfuse myself and we can move on with things...

Issue created here
Will fix.

>>>      o  A recipient can decide not to use a CWT based on a created Key ID
>>>         if it does not fit the recipient's requirements.
>>> I'm not sure I understand the semantics being described here.  Are we
>>> saying that the issuer might give a presenter a CWT, and by the time the
>>> presenter presents the CWT to the recipient, the recipient says "this is
>>> no good" and denies the transaction in question, forcing the presenter
>>> to go back to the issuer and try again?  (How do we know that the issuer
>>> would make any different choices the second time around?)
>> This risk always exists. In a constrained device world, the recipient
>> may already have cleared out the key referenced by the key ID, which
>> would force it to reject a CWT using this as proof-of-possession.
>> I'm not sure how to give good guidance in this case. The error message
>> delivered by the recipient rejecting the CWT might be helpful I suppose.
>> Do you think this merits some text?
> It's not entirely clear to me that we need to add more text here, but if we
> did, it would focus on what "decide not to use" means at a protocol level,
> and perhaps how the CWT might not "fit the recipient's requirements" (e.g.,
> the key id having fallen out of cache as you describe).

Issue created here:
Will fix.

>>>      from changing any elements conveyed within the CWT payload.  Special
>>>      care has to be applied when carrying symmetric keys inside the CWT
>>>      since those not only require integrity protection but also
>>>      confidentiality protection.
>>> Do we want to reiterate the common mechanisms for providing
>>> confidentiality protection here, or just leave the existing text earlier
>>> in the document to cover it?
>> Doesn't it say a few sentences before: "it is
>>      necessary to apply data origin authentication and integrity
>>      protection (via a keyed message digest or a digital signature)." ?
>> I would consider this to be enough.
> That doesn't cover the *confidentiality* protection, specifically.  (So it
> seems the answer to my original question is still unclear, at least to me.)

Issue created here:
Will fix.

>>> Section 6
>>>      ensure correct processing.  The recipient needs to be able to use
>>>      credentials to verify the authenticity, integrity, and potentially
>>>      the confidentiality of the CWT and its content.  This requires the
>>> Just from a rhetorical point of view, can you help me understand how
>>> credentials would be used to verify the confidentiality of a CWT?  It
>>> seems like this depends on either (or both of) how the CWT is
>>> transmitted or how it is prepared, and I am not sure how the recipient's
>>> credentials come into play.
>> This text is referring to the issuer's credentials (e.g. the
>> Authorization Server issuing the CWT), that the recipient needs to
>> verify the CWT. Do you want us to clarify this sentence?
> Note that I was specifically asking about "potentially the
> confidentiality"; I don't understand the intended workflow for verification
> of confidentiality (and thus which credentials are involved).  I don't
> really see how a credential held solely by the issuer could proide
> confidentiality protection when it needs to be understood by some other
> protocol participant.

Issue created here:
Will fix.

>>> Section 7
>>>      Criteria that should be applied by the Designated Experts include
>>>      determining whether the proposed registration duplicates existing
>>>      functionality, determining whether it is likely to be of general
>>>      applicability or whether it is useful only for a single application,
>>>      and evaluating the security properties of the item being registered
>>>      and whether the registration makes sense.
>>> I know we've been using (variations of) this text for a while, but it
>>> seems to me that it could be more clear than it currently is -- is
>>> duplication of functionality grounds for denial of registration?  What
>>> about general vs. specific applicability?  The latter seems more clearly
>>> applicable for determining which range from which to allocate, since
>>> that has impact on the encoding size.  Can the experts insist on updates
>>> to the security considerations text of a specification prior to granting
>>> approval, or are they limited to denying registration of values with
>>> poor security properties or insufficient documentation thereof?
>> I'm too unfamiliar with the designated expert system to provide a good
>> answer on this one. Can one of my co-authors chip in here?
Issue created here:
Will fix.

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