From nobody Sun Dec 1 12:01:40 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4D4120106 for ; Sun, 1 Dec 2019 12:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cwtL9XWJjrDl for ; Sun, 1 Dec 2019 12:01:36 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 ACAFB120103 for ; Sun, 1 Dec 2019 12:01:36 -0800 (PST) Received: from mail-qt1-f169.google.com ([209.85.160.169]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1ibVPS-0006Bw-6c; Sun, 01 Dec 2019 21:01:34 +0100 Received: by mail-qt1-f169.google.com with SMTP id d5so9827715qto.0 for ; Sun, 01 Dec 2019 12:01:34 -0800 (PST) X-Gm-Message-State: APjAAAUC8uHkUUHAWbUHIfF+3D56bpYzI+ontR2H9fG2Mx5yv71C6CeS fOTpY7fw2E+kdZscq1d2Dq/H6RJSDYPyGhJMy9Y= X-Google-Smtp-Source: APXvYqycUB8Ea2Pf8wgfbSxmycnU9iOHc98F2WsX7R6/IXrnAq+e+OCzhMDM4TDo/fGWZXpwXC/8IQ0Y/uA71Vd+19Y= X-Received: by 2002:ac8:19f8:: with SMTP id s53mr12018752qtk.29.1575230493054; Sun, 01 Dec 2019 12:01:33 -0800 (PST) MIME-Version: 1.0 References: <8C2EEF39-4C57-4BB6-8F26-9EBD392FD920@ericsson.com> In-Reply-To: <8C2EEF39-4C57-4BB6-8F26-9EBD392FD920@ericsson.com> From: Klaus Hartke Date: Sun, 1 Dec 2019 21:01:00 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Ace Wg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1575230496; 29c55239; X-HE-SMSGID: 1ibVPS-0006Bw-6c Archived-At: Subject: Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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: Sun, 01 Dec 2019 20:01:39 -0000 G=C3=B6ran Selander wrote: > I support adoption. > > For pub-sub, we need to specify how to do authorization of publishing to = a broker and authorization of access to published content. What is describe= d in this draft is a good way to do that with the ACE framework. +1 Klaus From nobody Sun Dec 1 21:37:15 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F901200B3; Sun, 1 Dec 2019 21:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.6 X-Spam-Level: X-Spam-Status: No, score=-12.6 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DIODU85x; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Cw7W7OjB 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 MpxOX6Pd8Cxn; Sun, 1 Dec 2019 21:37:11 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B1F12002F; Sun, 1 Dec 2019 21:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6692; q=dns/txt; s=iport; t=1575265031; x=1576474631; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8OrI4/o68e7BPNB0SZe+TBYj1xrdcrT53Bm+EOnZcGg=; b=DIODU85xPmwn6pcwEiExnrGyWDC5nq+aXRKWVP60tVqM7NdBn3WDmaiG WhcxDavyN5apmYrPeH/oBe04BZeynyc8tY1u4tHTqR/MmgykzmYXEiXpt pCtr3FaAkcukWP1Bzl3dC5MQkJf4obmGKFUYlhURj4x3QK0+6bqoAb/om Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Aegv+jhdX5z0ZaS+75ojij6Q7lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dy8zGdxLUlZN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAAAmouRd/4ENJK1lDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYFtAQEBAQEBCwGBSiknBWxYIAQLKod?= =?us-ascii?q?xA4pzgl+JW44pgUKBEANUCQEBAQwBARgNCAIBAYRAAoIKJDcGDgIDDQEBBAE?= =?us-ascii?q?BAQIBBQRthQsIJAyFUgEBAQEDAQEQKAYBASwLAQsEAgEIEQQBAQEeECEGCx0?= =?us-ascii?q?IAgQOBQgagjVMgkYDLgECDKQQAoE4iGCCJ4J+AQEFgTUBg0sNC4IXAwaBNgG?= =?us-ascii?q?MFRqBQT+BEUeCHi4+ghtJAQGBHRMBEgEJGINAgiytUi5CCoIuhx6KIIQ2gkG?= =?us-ascii?q?HbY4RgWSXBoIUj0cCBAIEBQIOAQEFgWgjRCNxcBU7gmxQERSGQoYkDBeDUIU?= =?us-ascii?q?UhQQ7dAqBHosiDRcBghoBAQ?= X-IronPort-AV: E=Sophos;i="5.69,268,1571702400"; d="scan'208";a="374824912" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Dec 2019 05:37:09 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xB25b90Q022638 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Dec 2019 05:37:09 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 1 Dec 2019 23:37:09 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 1 Dec 2019 23:37:08 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 1 Dec 2019 23:37:08 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fGKH3S1CEAwKnQRHbV587nESAqF3Esbe3+w5t31z7Rpvpba2Ojtp99UcHRxJuninWEH0DXk2KCoOroCas+rUCihJl/JqGPtXBbpo0+JH2fzu9YJF3sutdzpSNGqzl7SszmeSaZqQgZaxsI+SIBhfd3P1mnCbEAPNtU9XnQ0vxOBTOXQ+AtA0nCF5vnz0ahWNRCDuZiRc/mNL6+ZQ75y0cAprogP9ujmyb4EkXTxaH4rY1qTiD6+B5PQ4Rkf6lVhrvcOanhnwK+IFwqa8/KGC9rxd0dZdwxBfqMenPhVtQebzVtZ7CTeEjUejRZShXLR83jl25A80cnFhYqAjSuieDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mSCuRdeiJ0rgVvQzKcXGLToNcoibR1vNylxYzlgA8m0=; b=G9D4rVPpQ85oH4YW/JC4kngylRgx9CusFu2O7s9fhREa5vBfQT7hLfnsd6ttIvpcChn/nXYHDBQidr4mcpsMpXn2eSfeGXrLNGT9gE8hKcr2UqJUPsqezFdfRPPRePJrT/NtCBcaUjWfEUQLZOm+iqACYhyJPTxLDQtc2RK38SOW0elHEAm3Dnih6uXiXtYrme6u2y17l515SrIarNUB5jGMBean/2HXfAoG6ZRuVi28eQMpqbqAlUkgSr3RYEneyMEX6+v53jGzABTyF7vnp9gypcIVxFnRD/bj0oRO+G7ZsS+4PZz+0qmP2UsMWmlgMDR1zcgDhX5Z+IrGzhdXJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mSCuRdeiJ0rgVvQzKcXGLToNcoibR1vNylxYzlgA8m0=; b=Cw7W7OjBVPenfs0ndWUX1U2NJy8KVPoh0r7r8u+UqlgUn5ga5eI8cR2AEx1L2WsDlSUbRwV+HXEnzrLgXnb1CUhBTaJFnLO7ENsuOjwe3u4wrIMme70Rs3Q3kp1HTaMz9dy0Iab5T8TDVgATgJAnpi4gkONLsaLgNteVsh9Wt+8= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2676.namprd11.prod.outlook.com (52.135.254.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.22; Mon, 2 Dec 2019 05:37:07 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 05:37:07 +0000 From: "Panos Kampanakis (pkampana)" To: Benjamin Kaduk CC: Yaron Sheffer , "draft-ietf-ace-coap-est.all@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Thread-Index: AQHVgcaC5NivFu6vxkuLEqSa/tiqS6ddYSVAgCr2zQCACSCUsIAVKBPA Date: Mon, 2 Dec 2019 05:37:07 +0000 Message-ID: References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> <20191112230600.GJ32847@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::10c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a47d7af3-8a45-470a-1cfe-08d776e9ab9c x-ms-traffictypediagnostic: BN7PR11MB2676: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(4636009)(366004)(39860400002)(396003)(136003)(346002)(376002)(51444003)(199004)(189003)(13464003)(2906002)(2171002)(229853002)(9686003)(6246003)(66574012)(6306002)(478600001)(102836004)(14454004)(7736002)(86362001)(6916009)(66476007)(66556008)(64756008)(66446008)(4326008)(14444005)(76176011)(7696005)(6506007)(53546011)(966005)(25786009)(74316002)(71200400001)(71190400001)(256004)(186003)(52536014)(6436002)(54906003)(55016002)(6116002)(46003)(305945005)(446003)(8936002)(11346002)(76116006)(8676002)(5660300002)(81166006)(81156014)(33656002)(316002)(66946007)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2676; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Kv2EPC7uB+kdzHYacHcKwgdudFwzQ99TmJGdUIEN5vppkMxStSvd4GoOm6857FudC+jaOaj4B54EVHlnwaOusdgB8pNlcuCqgn3cPc3cgLHqwJDcXRyFvL1OkfnXBDbJLvU7xOmkmxNdo4HJCGzD5Gf7cSiSTFqXcxPcSNh7uBTixSSvwvtXnUmn61EcfmQaXR04kStw9+VLrYlwNhTW/pTPNNG8IQv5XR5R/Ko5VTlMJ9lT3oIfmh7w5Q2iv4GRj2DTkG/+ii4X8DYhI4u8rodiqydr7x55Jg8pPRLerCLzDezKDUI4rM3vWwocWT9VFIX4l350tNTexRy/sDXSI1tniobG3ZO/cb3TPitrjmJ4XDK2eJWfw/xhFZHEwpUh4PQciLctV8YOVjW1n0Vx8EuUfdMnFM5UEUHkxNiT9RNVwzG8rkVWXu+bwWqzHWUUjII8O7zQlVhG9esjySYHlZKOO7sxVvdu4n8DXV/byJKjwDx+wzY6imnxoyZqhmUCVemjFG2dUOGCxHRskiRB8ztolM8xvqSngCXmbw5f9amfCkpteoYFjFHrO80kH7fX x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a47d7af3-8a45-470a-1cfe-08d776e9ab9c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 05:37:07.2098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KAPUys3nCbe1o1ed00sTy14O3JCFiArGjuOn8V18aitZ1In/FByo4KWYacxvBVu/pFaEJXmiCeGjzhcGuLSJIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2676 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 X-BeenThere: ace@ietf.org 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, 02 Dec 2019 05:37:14 -0000 Hi Ben, Can you confirm if the diff https://github.com/SanKumar2015/EST-coaps/commi= t/53933bb9f93657955555f2302baef2e39709ae05 addresses your feedback? I will = then re-upload it. =20 Thanks, Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Monday, November 18, 2019 2:07 PM To: Benjamin Kaduk Cc: Yaron Sheffer ; draft-ietf-ace-coap-est.all@ietf= .org; ace@ietf.org Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Hi Ben, All addressed, except for the last one. The diff is here https://github.com= /SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05=20 My responses below in Pk>=20 I will wait for your confirmation before I upload version 17. Panos -----Original Message----- From: Benjamin Kaduk Sent: Tuesday, November 12, 2019 6:06 PM To: Panos Kampanakis (pkampana) Cc: Yaron Sheffer ; draft-ietf-ace-coap-est.all@ietf= .org; ace@ietf.org Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 Hi Panos, On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampanakis (pkampana) wrote= : > Hi Yaron, >=20 > Thank you for the thorough review and feedback.=20 >=20 > To make sure I don't miss any of your comments over an email thread, I tr= ack all your feedback in git issue 152 https://github.com/SanKumar2015/EST-= coaps/issues/152 There I tried to address all your comments and question an= d clarify some points.=20 >=20 > I also pushed minor changes to fix a few of the issues you brought up.=20 > The diff of the changes pushed is here=20 > https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f > e8e403d30467c98abfb >=20 > Please review the git issue and let us know if there are pending concerns= . Otherwise I am planning to reupload a new iteration next week.=20 Thanks for uploading the -16, and thanks again to Yaron for the very though= tful review. Sadly, I seem to have not looked at the github diff closely enough/in a tim= ely fashion, so I think we'll need to publish a -17 before I can move this = into IESG evaluation. Here's my remaining notes: Section 4 Private keys can be transported as responses to a server-side key generation request as described in Section 4.4 of [RFC7030] and discussed in Section 5.8 of this document. I think that, since Yaron brought it up, we should say "Section 4.4 of [RFC= 7030] (and subsections)". PK> Fixed.=20 curve. After the standardization of [RFC7748], support for Curve25519 will likely be required in the future by (D)TLS Profiles for the Internet of Things [RFC7925]. Sorry I missed this before -- "standardization" is a bit of a bugbear (7748= is Informational, not even Standards-Track, let alone full Internet Standa= rd). Pk> Replaced "standardization" with "publication".=20 In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction. Authenticating and negotiating DTLS keys requires resources on low- end endpoints and consumes valuable bandwidth. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions. For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. However, when a cacerts request is I think we can also clarify that this "MAY remain open" is changing expecta= tions from RFC 7030, where the expectation was that the TLS connection did = not remain open. Pk> I added " which was not the case in [RFC7030]" Section 10.1 the first DTLS exchange. Alternatively, in a case where a /sen request immediately follows a /crts, a client MAY choose to keep the connection authenticated by the Implicit TA open for efficiency reasons (Section 4). A client that interleaves EST-coaps /crts request with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests. If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. I think Yaron was saying that "even if the optimization of keeping the DTLS= connection open is useful in the general case, it is very risky and prone = to misimplementation when combined with /crts". So, if I can rephrase the = propsal to be that we say something more like "even though in general the D= TLS connection can remain open for efficiency (Section 4), after a /crts re= sponse, the client MUST close the DTLS connection and establish a new DTLS = connection for subsequent EST exchanges", are there reasons that we shouldn= 't use that behavior? Pk> I am not sure it is worth to add more complexity specific to /crts.=20 Pk> We would be adding more complexity for the client to track if this=20 Pk> TLS connection is a cacerts connection then I need to close it, if=20 Pk> it is any other connection then I can interleave requests. I am not=20 Pk> convinced that the risk is that big either. A malicious user that=20 Pk> was authenticated by the Implicit DB could easily craft a cacerts=20 Pk> response that allows him to be authenticated by the Explict DB. In=20 Pk> other words an active attacker would have no problems of fooling the=20 Pk> Explicit DB if he was allowed in by the Implicit DB. I think the=20 Pk> whole issue here is conceptual. The moment we get a new Trust DB we=20 Pk> need to trust it and not use the old one, but I don't think that=20 Pk> keeping the connection open for one or two more requests is that=20 Pk> risky. Even RFC7030 allows for it in the event that the client does=20 Pk> not have an Implicit DB when it is starting " The client MAY provisionally continue the TLS handshake to completion for the purposes of accessing the /cacerts or /fullcmc method. " I think the language as it is now is pretty clear on what we are trying to = do. And the Security Considerations spells out clearly. Of course, as alway= s, some implementer could make a mistake, but that could happen with RFC703= 0 and any other RFC as well. =20 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Dec 2 06:54:40 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D21201EA for ; Mon, 2 Dec 2019 06:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 hCxczDRG79FZ for ; Mon, 2 Dec 2019 06:54:37 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60071.outbound.protection.outlook.com [40.107.6.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371CB120045 for ; Mon, 2 Dec 2019 06:54:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jrks1kl1FZbkSrW1hi1u1rwWxSNqBiljeQz7Uo9VYY7BY1HdsU+Ruy+Ma+OCLsLEeJQi5yn2cxDvWxPEt7DEtUQytrg85jEX9fBggWKyMsDTqHLVetDwraAK9I5aGdqqA2mVe7UgEhmuYJ18pqh0ljKS/sTHvfax4SG3dqp1gMAMAPHaqd9QHp37aAHbuUccLTDC2luKJkKPtz1zbb5OXHW3vYU7kTUnPjBRIL2yQo1LbeObL35UZqQnsN77YO1bV2ciRMcJNdVvK/86HcGDz8q2PRocyAfjCULCBlOpMnoNTrHbehTer2iSKEZe1uOzcst4pFfybNfi2gT9WGAsEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+cPjdAlCw+DZq41lGTdWJ1wQXlVy0hWrek7kKqwhLGg=; b=OFTUY1sPVWalKzi5gMD4QB+NYSrzFnbJF04An/gaxoDlV2Eq9O7nB5Rme5ajKnDUp/ycBT30ZqRtPb2hgqukmeYp/XNfcoce4PATsslln1mUmmrjdiVU9ZdH9LBLIASDT1py1HxOpUCA3rtgKItw6nYYGV4Fy+9vUn6pJYJs3AVaiyzzgdIOyp6NsaX8MCwoAKDv4aHwNMfQXOSBTvIkiIXR2pL3B/Ic4oixmPQd85eSv1iUUUwtRg/SsBGud8R6HK2S/yTF4ORCJQzekTt7veFDTJCu/rc4UTxbDl5SgrYgY+3Z0VGLP1cZPuHwhSDHOVxj3rkVd6nJbfiVlijWWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+cPjdAlCw+DZq41lGTdWJ1wQXlVy0hWrek7kKqwhLGg=; b=FSl4hQYgB8tZAglqvS8oLTaO/up0GQY5LyXYMqx22QAJAp1twsX0pQTLB8nUfVnKCm/JT6+NPcfLFvkl4A9h23T44q81VUzMx/OYPtq+PMQSjK9h3aiCcAx+P2zTmnVtBN0cdNlhWKxha4CZDXbPCyUX34/JKnUPgY2sGW9pdUo= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.5; Mon, 2 Dec 2019 14:54:34 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::dc2b:f9d6:17f5:58dc]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::dc2b:f9d6:17f5:58dc%5]) with mapi id 15.20.2516.003; Mon, 2 Dec 2019 14:54:34 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Ace Wg Thread-Topic: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile Thread-Index: AQHVqSBl369e3fEdOECJBetALv7aeg== Date: Mon, 2 Dec 2019 14:54:34 +0000 Message-ID: <7955542E-AC7D-43D1-97BE-982A4C66D0D2@ericsson.com> References: <8C2EEF39-4C57-4BB6-8F26-9EBD392FD920@ericsson.com> In-Reply-To: <8C2EEF39-4C57-4BB6-8F26-9EBD392FD920@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [2001:14bb:170:993:bc02:526:cee6:8a28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b104d05d-9827-49fc-d10a-08d777378b9b x-ms-traffictypediagnostic: HE1PR07MB4236: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(396003)(376002)(366004)(199004)(189003)(558084003)(2616005)(6436002)(99286004)(6512007)(6486002)(14444005)(305945005)(6116002)(71190400001)(66946007)(64756008)(7736002)(58126008)(76116006)(256004)(66556008)(478600001)(6916009)(86362001)(66446008)(25786009)(6246003)(14454004)(8936002)(46003)(2906002)(33656002)(66476007)(71200400001)(36756003)(446003)(186003)(76176011)(66574012)(5660300002)(8676002)(11346002)(6506007)(81156014)(229853002)(102836004)(316002)(85182001)(85202003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4236; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: boJ2IYdhCrqDQDG2k6t+J7eUqdO1NVoHIDJ0vTikVfGrg6vLqZejXP973qms7hVKX3Upo3VOCGltUhmnq40q3gF0NSYRcpegtFz4KbpPikFQFVR3YgVptziTTEgGMjqUH5CfEh60p+Na4wTFk8B78a9exRjpFzPE+UJoCvm1owmNlCP2uEVfvMrXkYgqx6Tss1F+m2Y3TB7bxWd3e0MH8RTZvK+Yo+dQETTtgXfaKkReKFGtM9F1eothBRj0yZFIq9Smy7idfE0q5TWwfYY9SI2EiPCSq+2j1hdvlaDf6zH/MC/NtwNgOOhtcS7PeqRrvbntE6iO0wrPf4DJEzwo4HCdHMCNlB6kenbJziC9hlZQ20hJnrWIhQivT6tem4gp4WmRXQRuBFLdvw2B1K0dvAVtHi/6c04UBPS5iBAzKKOG9e5nF5nnBS+lLfto2/Vs x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <632CF993492C7B4C94691FBCBC05BB9C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b104d05d-9827-49fc-d10a-08d777378b9b X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 14:54:34.4366 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0JpheuTLkg/kI2h40qtuRSZl6dHqOppIcdsA3/Gg+4f4P4ZJ5zEostnPQf5i/sw2ixAX0yh9z2l8fPLpz0ymOqqgqPm9ihDpk+CmFDQKEY4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4236 Archived-At: Subject: Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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, 02 Dec 2019 14:54:39 -0000 T24gMjcvMTEvMjAxOSAxMC4xMSwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPiBGb3IgcHViLXN1 Yiwgd2UgbmVlZCB0byBzcGVjaWZ5IGhvdyB0byBkbyBhdXRob3JpemF0aW9uIG9mIHB1Ymxpc2hp bmcgdG8gYSBicm9rZXIgYW5kIGF1dGhvcml6YXRpb24gb2YgYWNjZXNzIHRvIHB1Ymxpc2hlZCBj b250ZW50LiBXaGF0IGlzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IGlzIGEgZ29vZCB3YXkgdG8g ZG8gdGhhdCB3aXRoIHRoZSBBQ0UgZnJhbWV3b3JrLg0KPg0KDQorMSBmb3IgYWRvcHRpb24uIA0K DQoNCkNoZWVycywNCkFyaQ0KDQo= From nobody Wed Dec 4 22:19:45 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014521200B6; Wed, 4 Dec 2019 22:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Pr174i1Mz8on; Wed, 4 Dec 2019 22:19:42 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFB612008F; Wed, 4 Dec 2019 22:19:42 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 4 Dec 2019 22:19:36 -0800 From: Jim Schaad To: CC: Date: Wed, 4 Dec 2019 22:19:35 -0800 Message-ID: <02c101d5ab33$f89d5540$e9d7ffc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdWrLjW/BDRtZ50KQX+CFvJ7EA7/IA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Certificate processing for MQTT X-BeenThere: ace@ietf.org 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: Thu, 05 Dec 2019 06:19:44 -0000 I got to the point of needing to start producing and validating certificates for MQTT and started running into some questions as well as starting to pickup some odd information that this document does not point to. 1. Should probably reference the mqtt(s) URI scheme, I am however somewhat irritated that it is not a registered scheme with IANA. 2. Has OASIS done anything sort of document for certificate validation. As an example is there an OID defined for extended key usage? 3. What should be said about matching data in the response from the AS and the certificate. What should be said about matching for raw public keys. I think that later is easy as it should just match the rs_cnf returned from the AS, but I don't know what should be said for certificates. 4. With the definition of some guidance in COSE, should there be a field for doing certificates in the rs_cnf - returning a fingerprint not the entire certificate. Jim From nobody Thu Dec 5 02:42:06 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B56E1200FF; Thu, 5 Dec 2019 02:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dh74B-yUmd8V; Thu, 5 Dec 2019 02:42:03 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 54A14120026; Thu, 5 Dec 2019 02:42:03 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id p5so3030698qtq.12; Thu, 05 Dec 2019 02:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n12xqTVWTj/TIX7MS7XSOSO/M/arrZLn02pajxjXcz4=; b=qss+5EQCnvoyY1eYuHMTMmdD00bkTmYIxLSCoTs3Dw4eyBFDn2OkSoB5NPtfaQibTY wNUzovc84S7HIEXi9qyvVkb2YGJVap3XoddV9Mv/7pHN8uyXOjZjgJ8BconKzvJz9157 wmjRYJjzOTS4ASn32dklw06E+qwzT8JXlzSxftnOBiTZ3xM2uAUumv6xTrP3SmwiEV+2 UD5R3oSjhjmW0HnUCDQJSfsSSYDCuOendBLirwvZdpqi6Yu4H9d/EeFN4C6oWCvC4bY5 TiZL0rzAtr1LtlLLNFGsjsYk9xxltRf80k9/LC5fC0y8vLENfoED4Hh5DKf1S4ni7Xgo y1pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n12xqTVWTj/TIX7MS7XSOSO/M/arrZLn02pajxjXcz4=; b=pu6LUsAMBF4vG69XCbo2ffFsXX5ClJ0WWM7qwK9C0RApFmeK9YVWwHTLIIrYmnohhU ojuj3EwsFX2fjVleAvFB29HvUZb1lPbpw8XeFwX5Oet2eGrlLEyMWRE6EILrLZkVoyZs XKd8OJ3U+2O0+pvqF5uVf0EiPDMUjijPXjbLr9OrzqCXAGwZso0ex1uQwEXUH+SLxYdu 8wdsC9G2MecNG9o3rcT2CP+Q2VY7E8TBcEnOKTAsKCareJyeEImhdbDz4A3B6F/3/ZEL 3/Oky6duZC56aKYVu6PJCn0NRNJr7gHgUe6cCSB4ugABLITN29E6OBcpoYabt5i5K6y6 NTyA== X-Gm-Message-State: APjAAAUPJXfwnT5fCAm8lqEvGfVqs/L9at66Bp2GVf/VYlfrP8lGla1k mMoh0LdjtczckpAv1D83D96TmbTPRW3kZTnWXBWAmOalqD0= X-Google-Smtp-Source: APXvYqz/mS9JfP1i3HxtX6puwVE0pTOqJ2xQ6XFjG3G9STPaDMl24pn00xGITkun7bRvZLf6eTFd8TwcyoZTCyq0Uf4= X-Received: by 2002:aed:2047:: with SMTP id 65mr6973338qta.78.1575542522365; Thu, 05 Dec 2019 02:42:02 -0800 (PST) MIME-Version: 1.0 References: <02c101d5ab33$f89d5540$e9d7ffc0$@augustcellars.com> In-Reply-To: <02c101d5ab33$f89d5540$e9d7ffc0$@augustcellars.com> From: Cigdem Sengul Date: Thu, 5 Dec 2019 10:41:51 +0000 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="0000000000005fcad20598f294b1" Archived-At: Subject: Re: [Ace] Certificate processing for MQTT X-BeenThere: ace@ietf.org 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: Thu, 05 Dec 2019 10:42:05 -0000 --0000000000005fcad20598f294b1 Content-Type: text/plain; charset="UTF-8" Hello Jim, Thank you for your email. I am in the process of revising the document for the December update agreed in Singapore, so these comments are extremely helpful. Comments are inline. On Thu, Dec 5, 2019 at 6:19 AM Jim Schaad wrote: > I got to the point of needing to start producing and validating > certificates > for MQTT and started running into some questions as well as starting to > pickup some odd information that this document does not point to. > > 1. Should probably reference the mqtt(s) URI scheme, I am however somewhat > irritated that it is not a registered scheme with IANA. > Indeed, we used MQTT over TLS to mean MQTTS, though it is not mentioned explicitly in the MQTT v5 OASIS spec, but here: https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme Do you suggest we reference this? The latest I know: "The URI scheme has been discussed by the technical committee a few times. The proposal was to produce a committee note rather than make it a formal part of the spec." based on this - https://github.com/mqtt/mqtt.github.io/issues/41 I will see if I can find more information from OASIS. 2. Has OASIS done anything sort of document for certificate validation. As > an example is there an OID defined for extended key usage? > This is what is mentioned in the MQTT v5 for authenticating the AS with a certificate: "Implementations providing MQTT service for multiple hostnames from a single IP address should be aware of the Server Name Indication extension to TLS defined in section 3 of [RFC6066] . This allows a Client to tell the Server the hostname of the server it is trying to connect to." I also found the following information when first writing the draft: https://www.oasis-open.org/committees/download.php/50161/X-MQTT-Security.txt that goes into some detail but did not cite it because it did not look official. However, it at least mentions things like TLS versions and certificate types. > > 3. What should be said about matching data in the response from the AS and > the certificate. What should be said about matching for raw public keys. > I > think that later is easy as it should just match the rs_cnf returned from > the AS, but I don't know what should be said for certificates. > At the moment I have the following text: The Broker MUST be authenticated during TLS handshake. If the Client authentication included TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. For the other Client Authentication cases, to authenticate the Broker, the client MAY either have the ability to receive and validate a server-side certificate or an RPK from the Broker checked against the 'rs_cnf' parameter in the token. The reason why I did not go into more detail for TLS/certificate use on the server-side, was because MQTT OASIS standard recommends it but does not go into detail (as discussed in the previous points). And my experience with mqtt brokers that they define how to set it up in their config pages: e.g., HiveMQ with BoringSSL https://www.hivemq.com/docs/4.2/hivemq/security.html (HiveMQ is what Edinburgh colleagues are implementing ACE mqtt-tls profile with now). or Mosquitto with OpenSSL https://mosquitto.org/man/mosquitto-conf-5.html https://mosquitto.org/man/mosquitto-tls-7.html My assumption was that for MQTT developers who have opted for a certain MQTT implementation and want to use server-side certificates, they would continue configuring the server-side TLS as they always do, and then use the ACE plugin to do the client authentication/authorisation. > > 4. With the definition of some guidance in COSE, should there be a field > for doing certificates in the rs_cnf - returning a fingerprint not the > entire certificate. > This is interesting - do you mean working with this draft: https://tools.ietf.org/html/draft-ietf-cose-x509-04 Thanks, --Cigdem > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000005fcad20598f294b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,

Thank you f= or your email. I am in the process of revising the document for the Decembe= r update agreed in Singapore, so these comments are extremely helpful.=C2= =A0
Comments are inline.=C2=A0

On Thu, Dec 5, 2019 at 6:19 A= M Jim Schaad <ietf@augustcella= rs.com> wrote:
I got to the point of needing to start producing and validating certi= ficates
for MQTT and started running into some questions as well as starting to
pickup some odd information that this document does not point to.

1.=C2=A0 Should probably reference the mqtt(s) URI scheme, I am however som= ewhat
irritated that it is not a registered scheme with IANA.

Indeed, we used MQTT over TLS to mean MQTTS, though it is = not mentioned explicitly in the MQTT v5 OASIS spec,
Do you sugg= est we reference this?
The latest I know: "The URI scheme has been discussed by the technical= committee a few times. The proposal was to produce a committee note rather= than make it a formal part of the spec."
I will see if I can find more information = from OASIS.=C2=A0


2.=C2=A0 Has OASIS done anything sort of document for certificate validatio= n.=C2=A0 As
an example is there an OID defined for extended key usage?
=

This is what is mentioned in the MQTT v5 for authentica= ting the AS with a certificate:
"Implementations prov= iding MQTT service for multiple hostnames from a single IP address should b= e aware of the Server Name Indication extension to TLS defined in section 3= of=C2=A0[RFC6066]. This allows a Client to tell th= e Server the hostname of the server it is trying to connect to."

I also found the follow= ing information when first writing the draft:=C2=A0htt= ps://www.oasis-open.org/committees/download.php/50161/X-MQTT-Security.txt

3.=C2=A0 What should be said about matching data in the response from the A= S and
the certificate.=C2=A0 What should be said about matching for raw public ke= ys.=C2=A0 I
think that later is easy as it should just match the rs_cnf returned from the AS, but I don't know what should be said for certificates.

At the moment I have the following text:
<= div>
The Broker MUST be =
authenticated during TLS handshake.  If the Client
   authentication included TLS:Known(RPK/PSK), then the Broker is
   authenticated using the respective method.  For the other Client
   Authentication cases, to authenticate the Broker, the client MAY
   either have the ability to receive and validate a server-side
   certificate or an RPK from the Broker checked against the 'rs_cnf=
9; parameter
   in the token.
<=
br>
The reason why I did not go into more detail for TLS/cer=
tificate use on the server-side, 
was because MQTT OA=
SIS standard recommends it but does not go into detail (as discussed in the=
 previous points).
And my experience with mqtt broker=
s that they define how to set it up in their config pages:
e.g., HiveMQ with BoringSSL https://www.hivemq.com/do= cs/4.2/hivemq/security.html (HiveMQ is what Edinburgh colleagues are im= plementing ACE mqtt-tls profile with now). 
or Mosquitto with OpenSSL https://mosquitto.org/man/mosquitto-co=
nf-5.html 
 https://mosquitto.org/man/mosquitto-tls-7.html

My ass=
umption was that for MQTT developers who have opted for a certain MQTT impl=
ementation and want to use server-side certificates, 
they would continue configuring the server-side TLS as they always do, 
and then use the ACE  plugin to do the client authentic=
ation/authorisation.
=C2=A0

4.=C2=A0 With the definition of some guidance in COSE, should there be a fi= eld
for doing certificates in the rs_cnf - returning a fingerprint not the
entire certificate.

This is interesting= - do you mean working with this draft:=C2=A0https://tools.ietf.org/html/draft-ietf-co= se-x509-04

=C2=A0Thanks,
--Cigdem=C2= =A0

Jim


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000005fcad20598f294b1-- From nobody Thu Dec 5 13:35:24 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F060C12008D; Thu, 5 Dec 2019 13:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XQogWFO1WPlz; Thu, 5 Dec 2019 13:35:19 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036CB120073; Thu, 5 Dec 2019 13:35:18 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 5 Dec 2019 13:35:12 -0800 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <02c101d5ab33$f89d5540$e9d7ffc0$@augustcellars.com> In-Reply-To: Date: Thu, 5 Dec 2019 13:35:10 -0800 Message-ID: <02f901d5abb3$e0fd4cd0$a2f7e670$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FA_01D5AB70.D2DCF300" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKEoWZaqnsZbBlppqAT0mHocmEkSwF53hktpkJCtbA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Certificate processing for MQTT X-BeenThere: ace@ietf.org 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: Thu, 05 Dec 2019 21:35:23 -0000 ------=_NextPart_000_02FA_01D5AB70.D2DCF300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Thursday, December 5, 2019 2:42 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] Certificate processing for MQTT =20 Hello Jim, =20 Thank you for your email. I am in the process of revising the document = for the December update agreed in Singapore, so these comments are = extremely helpful.=20 Comments are inline.=20 =20 On Thu, Dec 5, 2019 at 6:19 AM Jim Schaad > wrote: I got to the point of needing to start producing and validating = certificates for MQTT and started running into some questions as well as starting to pickup some odd information that this document does not point to. 1. Should probably reference the mqtt(s) URI scheme, I am however = somewhat irritated that it is not a registered scheme with IANA. =20 Indeed, we used MQTT over TLS to mean MQTTS, though it is not mentioned = explicitly in the MQTT v5 OASIS spec, but here: https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme Do you suggest we reference this? The latest I know: "The URI scheme has been discussed by the technical = committee a few times. The proposal was to produce a committee note = rather than make it a formal part of the spec." based on this - https://github.com/mqtt/mqtt.github.io/issues/41 I will see if I can find more information from OASIS.=20 =20 [JLS] I would rather not make the reference to a WIKI page, a reference = to a note would be just fine as that document could request the IANA = registrations. If they are really not interested in doing this we could = always run a fast draft through the Independent Submission Editor. The = question would be which of the variants need to be documented. =20 =20 2. Has OASIS done anything sort of document for certificate validation. = As an example is there an OID defined for extended key usage? =20 This is what is mentioned in the MQTT v5 for authenticating the AS with = a certificate: "Implementations providing MQTT service for multiple hostnames from a = single IP address should be aware of the Server Name Indication = extension to TLS defined in section 3 of = = [RFC6066]. This allows a Client to tell the Server the hostname of the = server it is trying to connect to." =20 I also found the following information when first writing the draft: = https://www.oasis-open.org/committees/download.php/50161/X-MQTT-Security.= txt that goes into some detail but did not cite it because it did not look = official. However, it at least mentions things like TLS versions and = certificate types. =20 [JLS] That looks to be recommendations on how to use TLS not = recommendations about the certificates to be used in TLS. I would agree = that it does not look to be very official and subject to change so not = referencing it makes sense. Some of the info might be copied into this = document. =20 =20 3. What should be said about matching data in the response from the AS = and the certificate. What should be said about matching for raw public = keys. I think that later is easy as it should just match the rs_cnf returned = from the AS, but I don't know what should be said for certificates. =20 At the moment I have the following text: The Broker MUST be authenticated during TLS handshake. If the Client authentication included TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. For the other Client Authentication cases, to authenticate the Broker, the client MAY either have the ability to receive and validate a server-side certificate or an RPK from the Broker checked against the 'rs_cnf' = parameter in the token. =20 The reason why I did not go into more detail for TLS/certificate use on = the server-side,=20 was because MQTT OASIS standard recommends it but does not go into = detail (as discussed in the previous points). And my experience with mqtt brokers that they define how to set it up in = their config pages: e.g., HiveMQ with BoringSSL = = https://www.hivemq.com/docs/4.2/hivemq/security.html (HiveMQ is what = Edinburgh colleagues are implementing ACE mqtt-tls profile with now).=20 or Mosquitto with OpenSSL = https://mosquitto.org/man/mosquitto-conf-5.html=20 = https://mosquitto.org/man/mosquitto-tls-7.html =20 My assumption was that for MQTT developers who have opted for a certain = MQTT implementation and want to use server-side certificates,=20 they would continue configuring the server-side TLS as they always do,=20 and then use the ACE plugin to do the client = authentication/authorisation. =20 [JLS] So none of these documents are addressing the biggest issue that = I was worried about. * How should the identity check be done against the certificate? = Options would be the URI field in the alt name, but that requires that = an agreed on URI exist. The DNS name field in the alt name, which is = fine as long as only the default ports are used but has problems = otherwise. Some field in the subject name, but that is highly = discouraged by a number of people such as myself. That is not to say = that it is not done however. * A lesser issue would have been the use of an extended key = usage =E2=80=93 which is obviously not done because nobody ever defined = one. However, some might decide that id-kp-serverAuth would be needed = because this is a TLS server, even it if it is not a WWW server.=20 * Are there any other required extensions that are to be in the = certificate? =20 Issue that I would not worry about are: * What algorithms are permitted =E2=80=93 this gets over taken = by events so saying be smart is mostly fine with me. =20 * If there is a standardized way of dealing with revocation = checking such as OCSP stapling or caching of certificates and CRLs. * The use of resumption of one type or another. =20 Those types of issues are of interest, but these are the types of things = that can be negotiated. =20 In terms of doing the check against the rs_cnf value returned, one could = check the public key even for a certificate. This allows for the MQTT = server to have a self-signed certificate and still have it being = trusted. =20 4. With the definition of some guidance in COSE, should there be a = field for doing certificates in the rs_cnf - returning a fingerprint not the entire certificate. =20 This is interesting - do you mean working with this draft: = https://tools.ietf.org/html/draft-ietf-cose-x509-04 =20 [JLS] Yes that is the document that I was referring to. =20 Jim =20 =20 Thanks, --Cigdem=20 Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_02FA_01D5AB70.D2DCF300 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Thursday, = December 5, 2019 2:42 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] Certificate processing = for MQTT

 

Hello Jim,

 

Thank you for your email. I am in the process of = revising the document for the December update agreed in Singapore, so = these comments are extremely helpful. 

Comments are = inline. 

 

On = Thu, Dec 5, 2019 at 6:19 AM Jim Schaad <ietf@augustcellars.com> = wrote:

I got to = the point of needing to start producing and validating = certificates
for MQTT and started running into some questions as well = as starting to
pickup some odd information that this document does = not point to.

1.  Should probably reference the mqtt(s) URI = scheme, I am however somewhat
irritated that it is not a registered = scheme with IANA.

 

Indeed, we used MQTT over TLS to mean MQTTS, though it = is not mentioned explicitly in the MQTT v5 OASIS = spec,

Do you suggest we reference = this?

The latest I know: = "The URI scheme has been discussed by the = technical committee a few times. The proposal was to produce a committee = note rather than make it a formal part of the = spec."

I will see if I can find more information from = OASIS. 

 

[JLS] I would rather not make the reference to a WIKI = page, a reference to a note would be just fine as that document could = request the IANA registrations.=C2=A0 If they are really not interested = in doing this we could always run a fast draft through the Independent = Submission Editor.=C2=A0 The question would be which of the variants = need to be documented.

 

 

2.  = Has OASIS done anything sort of document for certificate = validation.  As
an example is there an OID defined for extended = key usage?

 

This is what is mentioned in the MQTT v5 for = authenticating the AS with a certificate:

&qu= ot;Implementations providing MQTT service for multiple hostnames from a = single IP address should be aware of the Server Name Indication = extension to TLS defined in section 3 of [R= FC6066]. = This allows a Client to tell the Server the hostname of the server it is = trying to connect to."

 

I = also found the following information when first writing the = draft: https://www.oasis-open.org/committees/download.php/50161/X-M= QTT-Security.txt

that = goes into some detail but did not cite it because it did not look = official. However, it at least mentions things like TLS versions and = certificate types.

 

[JLS] That = looks to be recommendations on how to use TLS not recommendations about = the certificates to be used in TLS.=C2=A0 I would agree that it does not = look to be very official and subject to change so not referencing it = makes sense.=C2=A0 Some of the info might be copied into this = document.

 

 


3.  What should be said about matching data = in the response from the AS and
the certificate.  What should be = said about matching for raw public keys.  I
think that later is = easy as it should just match the rs_cnf returned from
the AS, but I = don't know what should be said for = certificates.

 

At the moment I have the following = text:

The Broker MUST be authenticated during TLS =
handshake.=C2=A0 If the Client
=C2=A0=C2=A0 authentication included =
TLS:Known(RPK/PSK), then the Broker is
=C2=A0=C2=A0 authenticated using the respective =
method.=C2=A0 For the other Client
=C2=A0=C2=A0 Authentication cases, to authenticate =
the Broker, the client MAY
=C2=A0=C2=A0 either have the ability to receive =
and validate a server-side
=C2=A0=C2=A0 certificate or an RPK from the Broker =
checked against the 'rs_cnf' parameter
=C2=A0=C2=A0 in the =
token.
 
The reason why I =
did not go into more detail for TLS/certificate use on the server-side, =

was because MQTT =
OASIS standard recommends it but does not go into detail (as discussed =
in the previous points).
And my experience =
with mqtt brokers that they define how to set it up in their config =
pages:
e.g., HiveMQ with =
BoringSSL https://www.hivemq.com/docs/4.2/hivemq/securit=
y.html (HiveMQ is what Edinburgh colleagues are implementing =
ACE mqtt-tls profile with now). 
or Mosquitto with =
OpenSSL https://mosquitt=
o.org/man/mosquitto-conf-5.html 
=C2=A0https://mosquitto.org/man/mosquitto-tls-7.html=

 
My assumption was =
that for MQTT developers who have opted for a certain MQTT =
implementation and want to use server-side certificates, 
they would continue =
configuring the server-side TLS as they always do, 
and then use the =
ACE=C2=A0 plugin to do the client =
authentication/authorisation.
 
[JLS]=C2=A0 =
So none of these documents are addressing the biggest issue that I was =
worried about.
=C2=B7         =
How should =
the identity check be done against the certificate?=C2=A0 Options would =
be the URI field in the alt name, but that requires that an agreed on =
URI exist.=C2=A0 The DNS name field in the alt name, which is fine as =
long as only the default ports are used but has problems =
otherwise.=C2=A0 Some field in the subject name, but that is highly =
discouraged by a number of people such as myself.=C2=A0 That is not to =
say that it is not done however.
=C2=B7         =
A lesser =
issue would have been the use of an extended key usage =E2=80=93 which =
is obviously not done because nobody ever defined one.=C2=A0 =
=C2=A0However, some might decide that id-kp-serverAuth would be needed =
because this is a TLS server, even it if it is not a WWW server. =

=C2=B7         =
Are there =
any other required extensions that are to be in the =
certificate?
 
Issue that I =
would not worry about are:
=C2=B7         =
What =
algorithms are permitted =E2=80=93 this gets over taken by events so =
saying be smart is mostly fine with me.=C2=A0 =

=C2=B7         =
If there is =
a standardized way of dealing with revocation checking such as OCSP =
stapling or caching of certificates and =
CRLs.
=C2=B7         =
The use of =
resumption of one type or another.
 
Those types =
of issues are of interest, but these are the types of things that can be =
negotiated.
 
In terms of =
doing the check against the rs_cnf value returned, one could check the =
public key even for a certificate.=C2=A0 This allows for the MQTT server =
to have a self-signed certificate and still have it being =
trusted.

 


4.  With the definition of some guidance in = COSE, should there be a field
for doing certificates in the rs_cnf - = returning a fingerprint not the
entire = certificate.

 

This is interesting - do you mean working with this = draft: https://tool= s.ietf.org/html/draft-ietf-cose-x509-04

 

[JLS] Yes = that is the document that I was referring to.

 

Jim

 

 

 Thanks,

--Cigdem 


Jim


____________________________________= ___________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

------=_NextPart_000_02FA_01D5AB70.D2DCF300-- From nobody Thu Dec 5 15:58:49 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B4D120046; Thu, 5 Dec 2019 15:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9VhlNaPdx1aw; Thu, 5 Dec 2019 15:58:44 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1744120033; Thu, 5 Dec 2019 15:58:43 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB5NwbJc025322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Dec 2019 18:58:39 -0500 Date: Thu, 5 Dec 2019 15:58:36 -0800 From: Benjamin Kaduk To: "Panos Kampanakis (pkampana)" Cc: Yaron Sheffer , "draft-ietf-ace-coap-est.all@ietf.org" , "ace@ietf.org" Message-ID: <20191205235836.GM13890@kduck.mit.edu> References: <157097172245.20767.1326966836276837764@ietfa.amsl.com> <20191112230600.GJ32847@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 X-BeenThere: ace@ietf.org 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: Thu, 05 Dec 2019 23:58:46 -0000 Hi Panos, Sorry for the slow reply -- it was a busy telechat week for the IESG. These changes look good; please go ahead and re-upload. Thanks, Ben On Mon, Dec 02, 2019 at 05:37:07AM +0000, Panos Kampanakis (pkampana) wrote: > Hi Ben, > > Can you confirm if the diff https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05 addresses your feedback? I will then re-upload it. > > Thanks, > Panos > > -----Original Message----- > From: Ace On Behalf Of Panos Kampanakis (pkampana) > Sent: Monday, November 18, 2019 2:07 PM > To: Benjamin Kaduk > Cc: Yaron Sheffer ; draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org > Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 > > Hi Ben, > > All addressed, except for the last one. The diff is here https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05 > > My responses below in Pk> > > I will wait for your confirmation before I upload version 17. > > Panos > > > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, November 12, 2019 6:06 PM > To: Panos Kampanakis (pkampana) > Cc: Yaron Sheffer ; draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org > Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 > > Hi Panos, > > On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampanakis (pkampana) wrote: > > Hi Yaron, > > > > Thank you for the thorough review and feedback. > > > > To make sure I don't miss any of your comments over an email thread, I track all your feedback in git issue 152 https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to address all your comments and question and clarify some points. > > > > I also pushed minor changes to fix a few of the issues you brought up. > > The diff of the changes pushed is here > > https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f > > e8e403d30467c98abfb > > > > Please review the git issue and let us know if there are pending concerns. Otherwise I am planning to reupload a new iteration next week. > > Thanks for uploading the -16, and thanks again to Yaron for the very thoughtful review. > > Sadly, I seem to have not looked at the github diff closely enough/in a timely fashion, so I think we'll need to publish a -17 before I can move this into IESG evaluation. Here's my remaining notes: > > Section 4 > > Private keys can be transported as responses to a server-side key > generation request as described in Section 4.4 of [RFC7030] and > discussed in Section 5.8 of this document. > > I think that, since Yaron brought it up, we should say "Section 4.4 of [RFC7030] (and subsections)". > > PK> Fixed. > > curve. After the standardization of [RFC7748], support for > Curve25519 will likely be required in the future by (D)TLS Profiles > for the Internet of Things [RFC7925]. > > Sorry I missed this before -- "standardization" is a bit of a bugbear (7748 is Informational, not even Standards-Track, let alone full Internet Standard). > > Pk> Replaced "standardization" with "publication". > > In a constrained CoAP environment, endpoints can't always afford to > establish a DTLS connection for every EST transaction. > Authenticating and negotiating DTLS keys requires resources on low- > end endpoints and consumes valuable bandwidth. To alleviate this > situation, an EST-coaps DTLS connection MAY remain open for > sequential EST transactions. For example, an EST csrattrs request > that is followed by a simpleenroll request can use the same > authenticated DTLS connection. However, when a cacerts request is > > I think we can also clarify that this "MAY remain open" is changing expectations from RFC 7030, where the expectation was that the TLS connection did not remain open. > > Pk> I added " which was not the case in [RFC7030]" > > Section 10.1 > > the first DTLS exchange. Alternatively, in a case where a /sen > request immediately follows a /crts, a client MAY choose to keep the > connection authenticated by the Implicit TA open for efficiency > reasons (Section 4). A client that interleaves EST-coaps /crts > request with other requests in the same DTLS connection SHOULD > revalidate the server certificate chain against the updated Explicit > TA from the /crts response before proceeding with the subsequent > requests. If the server certificate chain does not authenticate > against the database, the client SHOULD close the connection without > completing the rest of the requests. The updated Explicit TA MUST > continue to be used in new DTLS connections. > > I think Yaron was saying that "even if the optimization of keeping the DTLS connection open is useful in the general case, it is very risky and prone to misimplementation when combined with /crts". So, if I can rephrase the propsal to be that we say something more like "even though in general the DTLS connection can remain open for efficiency (Section 4), after a /crts response, the client MUST close the DTLS connection and establish a new DTLS connection for subsequent EST exchanges", are there reasons that we shouldn't use that behavior? > > Pk> I am not sure it is worth to add more complexity specific to /crts. > Pk> We would be adding more complexity for the client to track if this > Pk> TLS connection is a cacerts connection then I need to close it, if > Pk> it is any other connection then I can interleave requests. I am not > Pk> convinced that the risk is that big either. A malicious user that > Pk> was authenticated by the Implicit DB could easily craft a cacerts > Pk> response that allows him to be authenticated by the Explict DB. In > Pk> other words an active attacker would have no problems of fooling the > Pk> Explicit DB if he was allowed in by the Implicit DB. I think the > Pk> whole issue here is conceptual. The moment we get a new Trust DB we > Pk> need to trust it and not use the old one, but I don't think that > Pk> keeping the connection open for one or two more requests is that > Pk> risky. Even RFC7030 allows for it in the event that the client does > Pk> not have an Implicit DB when it is starting > " The client MAY > provisionally continue the TLS handshake to completion for the > purposes of accessing the /cacerts or /fullcmc method. " > I think the language as it is now is pretty clear on what we are trying to do. And the Security Considerations spells out clearly. Of course, as always, some implementer could make a mistake, but that could happen with RFC7030 and any other RFC as well. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Dec 5 18:43:21 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B1C12006F; Thu, 5 Dec 2019 18:43:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157560019579.16524.14506053382442048535@ietfa.amsl.com> Date: Thu, 05 Dec 2019 18:43:15 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-17.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 02:43:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-17.txt Pages : 52 Date : 2019-12-05 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-17 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 5 18:49:17 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4D12003F; Thu, 5 Dec 2019 18:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Vy0I8/eK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UycoN8kO 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 Pjb15CO9hCbG; Thu, 5 Dec 2019 18:49:13 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AEF12000F; Thu, 5 Dec 2019 18:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2141; q=dns/txt; s=iport; t=1575600553; x=1576810153; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UaNu2teoF3EKrY/KbI5/9gsVWfVtKcni5IbIu7nG4Ig=; b=Vy0I8/eKTYPEf2XYRi8uTkA95ORHBs+e3WgLneSPaGs9H5vEEsB1dv8U 4p08goKYfclKyIz106q6TfqTnfjB8wCpxKhUt3LndeAKlBKrUIMlE1yna L9F131AzabloyAB3R6uKCoycTaADpOAmJGe7GeEThwhjxJO0aqQ0S+n0v k=; IronPort-PHdr: =?us-ascii?q?9a23=3ApyhSfx/pL1L9Vf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaGAEjjJfjjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/DwA1weld/5ldJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BS1AFbFggBAsqh3EDinxOghGYBIJSA1QJAQEBDAEBGAsKAgE?= =?us-ascii?q?BhEACghMkOBMCAw0BAQQBAQECAQUEbYU3DIVSAQEBAQMBARAoBgEBLAwLBAI?= =?us-ascii?q?BCBEEAQEeARAnCx0IAgQBEggagwGCRgMuAQIMozwCgTiIYIIngn4BAQWBOQI?= =?us-ascii?q?OQYJ9GIIXCYE2jBcagUE/gRFHgkw+gmQBAQIBARiBSYNAgiyuTgqCLocfjla?= =?us-ascii?q?CQXOGe493jkqIQZFiAgQCBAUCDgEBBYFpIoFBDwhwFRohgmwJRxEUjGaDc4U?= =?us-ascii?q?UhT90gSiQQAEB?= X-IronPort-AV: E=Sophos;i="5.69,282,1571702400"; d="scan'208";a="378119898" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 02:49:11 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xB62nBVF008988 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 02:49:11 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Dec 2019 20:49:11 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Dec 2019 20:49:10 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 5 Dec 2019 21:49:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mQFumjBxKDON+vTBfknh6t+z7y02fcISslNBaWK4+a+oSP1fEt6A8lw8AtrtJPgvQnuvHejzZMeu3SZpwglKyhOsn51dzi+IE2iBhGIVXh++VAozCOny2bQkc6yd8IE4N/YppcMv3Al6YnWpFNOtoPQiaGLBaJ43OQLje6z1xvnYgARTHQf7VrcFGc7ibBgmDD2SXH/uilvpeOqTl4Sry/A6mjA1D7/GV7vfs7oid5YTrSHqNF+/E51CQYx7apOov3aK4WEVIBKIINdccIbAkKK8WwNhczWTGZjLxqVsxeghkbGtFDOpIZk0EZYf5XuuaRtFpNcEOBpEB/0SYa2C5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2/CQYx2w2keXbbWHexBdMv253QFjS/fAzgWw4g+46+Q=; b=jUcEBisOmR/S1g2BtzgSZrP1FZhyiXTxySxs1U0o9Z1CsbnQi24S47JjRa5RxTQUa04EcflgdZ7YP1YoavTt9dakJ3lPxybbW3tFLrrkWccRiX1h2+dHOk/vc76AjYvZXEPzZVubLY9wgVbCB91RPFfd0FZ9kaG1cJg006Tj3zIOZGqnv5EfzXGQ2Jj3uySoH582XA9Winw3x/e7DsDYcM6j3ANXQeB3bHuXRORgRWfRWT3f3o8QOtxCQnH3jgKaaehPTViThWiDSwiRf5BiiKRzeK/rAod9qf4Be6vi75fXcZT3AEWH/6QSxWrSEEsWM7aOsVTHyhFvAq6dXnc4xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2/CQYx2w2keXbbWHexBdMv253QFjS/fAzgWw4g+46+Q=; b=UycoN8kOdI8ibXXxJdO3ZdN8AnWWC0Ay64zOYNpfCxDNW822AbFUYs/HdhDAdWnOCQhnuODPywiEl58fQDPMdqNbPziXG6v+ZVRgSgbdFq/RiEiODVXYFRgk69nUIWuzkUYFI0BOiKSMswcp/Sl+u/fDXYHmk19NxQsQnwH9Q00= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2529.namprd11.prod.outlook.com (52.135.245.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Fri, 6 Dec 2019 02:49:09 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2516.015; Fri, 6 Dec 2019 02:49:09 +0000 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-17.txt Thread-Index: AQHVq976QCgaZ5IxMEuQHLJ7IcRppqesZzfA Date: Fri, 6 Dec 2019 02:49:08 +0000 Message-ID: References: <157560019579.16524.14506053382442048535@ietfa.amsl.com> In-Reply-To: <157560019579.16524.14506053382442048535@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22e5d568-2fd0-4c11-c092-08d779f6de10 x-ms-traffictypediagnostic: BN7PR11MB2529: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(366004)(396003)(39860400002)(199004)(189003)(13464003)(71190400001)(76116006)(74316002)(71200400001)(305945005)(186003)(14454004)(11346002)(33656002)(53546011)(102836004)(966005)(478600001)(6506007)(66556008)(8676002)(66574012)(55016002)(86362001)(229853002)(81166006)(99286004)(25786009)(8936002)(81156014)(66946007)(5660300002)(66476007)(52536014)(2906002)(9686003)(64756008)(450100002)(7696005)(76176011)(110136005)(316002)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2529; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9rZ4RX6g+9FkjKBa+zI8230ORqhJVjKrYgY7bKyEwceQSi+IZ1DbSYO/0c8YzYurloWBHK178rigAbmsDP+jKMLsBunNt1THmZ35RZI9YNgswHan6zL4B5jVCweC0uEHtbAAgGKAvg88s/iOLRiDRpxRtvJ3tJWiiaKQapE0WBnhrHaDvsS+crfrBqr6oJvxTWvnhIYrjZ0amJ1Z3E9c4h03iDvWEWgnsn+OQDJ+7Lh7M/vaNEvg+IQpp2lYQJTRjH4zH3gKB91JjOB66ST5mCdL7W1g69A4Y9yy/30N1vl7ugkwHY7DYSc1ZSWnzQaCbdgBeoHvMVX1kK3t4TKZDnMiRTerUNS7blORJ8zFUJpksmRVbzPNeETJ9NRmPOkvG6rEMn0sZe/7rbYfb05iufC7CeRYY15MCt452ZMzySVpeRbJMbJCjekoNgWqqnWLq9B3SZy92S716EaejEhESduPArOvuInmQGO+GUa9B+CG+OJPMl4sRzjaqGTioPBFmQHYI+bUJVb9p5RBTyH1VeKzluTNTul6zSXx+fiJYUU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 22e5d568-2fd0-4c11-c092-08d779f6de10 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 02:49:08.8991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XiUJ3Z8iSgOVTlfrbTcekuWd1Si+h3ODFMEtuE/GFxhw9rfZ5ffOX4+Kagh/kvryfIHR2tJWWyTXzYKxX31Gfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2529 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-17.txt X-BeenThere: ace@ietf.org 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: Fri, 06 Dec 2019 02:49:16 -0000 This version addresses Ben's recent feedback before it can go to IESG evalu= ation.=20 Thanks Ben for keeping us honest.=20 Panos -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: Thursday, December 05, 2019 9:43 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-17.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Authentication and Authorization for Const= rained Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-17.txt Pages : 52 Date : 2019-12-05 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-17 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-coap-est-17 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Sun Dec 8 10:18:55 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1871E12002E; Sun, 8 Dec 2019 10:18:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Stephen Kent via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Kent Message-ID: <157582913296.4934.15140560361782598959@ietfa.amsl.com> Date: Sun, 08 Dec 2019 10:18:53 -0800 Archived-At: Subject: [Ace] Secdir last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2019 18:18:53 -0000 Reviewer: Stephen Kent Review result: Has Issues SECDIR review of draft-ietf-ace-oauth-authz-27 The summary of the review is almost ready, but needs some revisions. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This is a long document- 86 pages! It is a proposal for how to use OAuth 2.0 and CoAP to provide authorization security for Internet of Things (IoT) devices. IoT devices are often criticized as not being very secure, so this seems like a useful initiative. RFC 7228 (Technology for Constrained-Node Networks, and Informational document) is cited as inspiration and reference for this work. CoAP (RFC 7252) is expressly designed for the sort of environment that characterizes many IoT devices, hence is seems a natural choice for this authorization-focused framework. OAuth is not as obvious a candidate building block in this context, e.g., it is expressly designed for the HTTP context, yet CoAP is cited as the replacement for HTTP. This document adapts OAuth for the CoAp context. This document has an extensive, 6-page Security Considerations section, appropriate for a document specifying an authorization framework. It begins by citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819), and OAuth 2.0 Token Introspection (RFC 7662). All three of these documents are relevant, and they contain substantial Security Consideration sections. Section 6.1 deals with security for the tokens that are transmitted to convey authorization information. In general the requirements and advice provided here are good; I would prefer to see the admonition against use of a shared secret key for a group of serves to be a MUST NOT, as opposed to just NOT RECOMMENDED. I am not convinced that the suggestion for short lifetime tokens is necessary; we have seen how short duration certificate lifetimes and frequent CRL issuance in PKI contexts often is neither required nor advisable. This section ends by noting that only client-initiated revocation of tokens is addressed by RFC 7009. The authors note that revocation of long lifetime token remains an open issue. If this is likely to be a common case for IoT devices, leaving this as a TBD is not great. Section 6.2 addresses communication security issues. The section opens by requiring an authorization server to offer confidentiality for client interactions, but the wording implies that a client need not make use of such protection. The reader is reminded that security requirements expressed in Section 5 of this document (a 25-page long section) MUST be addressed by a profile. I’d prefer to see references to specific parts of Section 5 that expressly addresses confidentiality, so that a reader can better understand when it is safe to reject the offer of confidentiality by a server. Encryption of CWTs is used as an example, which is appropriate because CBOR CWT is the default token format. The final paragraph of this section says that “developers MUST ensure that … ephemeral credentials … are not leaked to third parties.” This is good advice, but since adversaries are assumed to have physical access to IoT devices, the scope of this mandate is not clear. For example, is this text arguing for use of tamper-resistant hardware for storing private or session keys in IoT devices? Section 6.3 focuses on long-term credentials. The sections begins by noting the challenges associated with providing protection for such credentials in devices in publicly-accessible locations, explicitly referring to specialized hardware. This a good, clear statement, not like the ambiguous MUST at the end of 6.2. The text requires that compromise of a credential at one device MUST NOT lead to compromise of other credentials not linked to the device in question. However, the next sentence says that sharing of secret (and, presumably, private) keys is NOT RECOMMENDED. This is a somewhat inconsistent pair of statements; if secret keys are shared, then the MUST NOT will be violated, right? Why not just say that secret keys MUST NIOT be shared across devices? The section states that operators should have procedures to replace credentials that have been (or are suspected to have been) compromised. Why is this admonition not a SHOULD? The mildly-worded (“… also need to …) advice about decommissioning devices seems minimally helpful. If this is important than make it a SHOULD, if it’s not, then RECOMMEND it. Section 6.4 discusses the challenges associated with securing initial communication between a client and a resource server (RS). This communication makes use of the (appropriately-named) Creation Hints message defined in 5.1.2. The basis mechanism suggested here is use of a (possibly hard coded) list of trusted authorization servers (AS’s) and associated credentials, e.g., certificate fingerprints. The discussion here notes the potential for a DoS attack against an AS by a compromised RS, by having clients sends requests to the targeted AS. This is a useful comment, after noting that compromise of an RS would not cause an AS to grant requests to clients that it is not serving. Section 6.5 summarizes the “minimal” communication security requirements for the elements of the system described in this document (clients, AS’s and RS’s). I think it’s useful to collect these requirements in one place, although they have been described in various parts of Section 5. Unfortunately, the first sub-section seems to contradict Section 6.2! Specifically the text here says that all communication between a client and an AS MUST be encrypted, where as 6.2 requires only that an AS offer confidentiality. This inconsistency needs to be reconciled. The next subsection seems to be consistent. The final subsection (C-RS) notes the challenges of initial C/RS communication, and offers some suggested approaches. Some of the wording here is awkward. For example, the text notes that DTLS with server-side authentication “can be possible and are RECOMMENDED if supported by both parties.” It would be better to state that “DTLS with server-side authentication is a RECOMMENDED mechanism for use in this context, and SHOULD be employed if supported by both the C and the RS.” Section 6.6 deals with token lifetimes. The section begins by suggesting use of nonces (as described in 5.1.2) to counter replay attacks in the event of “clock drift” between an RS and an AS. I appreciate the analysis of mechanisms that can be used to address the clock drift issue, including the discussion of potential problems associated with using nonces in the face of a reboot. However, the text provides no indication of how much “drift” is tolerable, vs. when use of nonces is needed, and 5.1.2 does not even mention clock drift. Perhaps the text can be revised to provide additional advice re clock drift. Section 6.7 very briefly discussed the issue of combining profiles. The bottom line is that the security of a profile MUST NOT depend on the assumption that the profile is used exclusively throughout a given deployment. That’s a nice, straightforward warning! Section 6.8 discusses circumstances in which data is transmitted and may not encrypted, e.g., error messages. The discussion here is fairly clear, and includes a RECOMMENTATION and a MUST, as well as an analysis of potential risks associated with transmitting different types of information w/o confidentiality protection. The section title says “unprotected” but this discussion focuses only on confidentiality, so a more descriptive title might help. Section 6.9 provides guidance on how to deal with the ambiguity of how to match an “audience” value to a specific resource server. The authors admit that the Section 5 discussion about the (optional) audience parameter in the OAuth token is vague. They note that this is intentional, to accommodate a wide range of deployment scenarios. Thus the discussion in this section provides guidance for several scenarios. This is a reasonable way to deal with the ambiguity from Section 5. Section 6.10 examines denial of service attacks in the context of “introspection,” an optional aspect of OAuth which may be employed in this framework. The text examines two DoS attacks, one against resource servers and one against authorization servers, and suggests mitigations for both. Section 7 discusses privacy implications of the proposed framework. The discussion here is useful, addressing a set of concerns that arise due to client interactions with the AS and RS elements of the framework. From nobody Tue Dec 10 22:39:22 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868D12022D; Tue, 10 Dec 2019 22:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9Dh0pKGAeYhh; Tue, 10 Dec 2019 22:39:11 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C41112006E; Tue, 10 Dec 2019 22:39:11 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBB6d5v5001034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 01:39:07 -0500 Date: Tue, 10 Dec 2019 22:39:04 -0800 From: Benjamin Kaduk To: Stephen Kent Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, ace@ietf.org Message-ID: <20191211063904.GK13890@kduck.mit.edu> References: <157582913296.4934.15140560361782598959@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <157582913296.4934.15140560361782598959@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: ace@ietf.org 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: Wed, 11 Dec 2019 06:39:15 -0000 Hi Steve, Thanks for the thoughtful and in-depth commentary; I look forward to seeing the authors' response. I'll make a few notes inline in the interim... On Sun, Dec 08, 2019 at 10:18:53AM -0800, Stephen Kent via Datatracker wrote: > Reviewer: Stephen Kent > Review result: Has Issues > > SECDIR review of draft-ietf-ace-oauth-authz-27 > > The summary of the review is almost ready, but needs some revisions. > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements and > considerations in IETF drafts. Comments not addressed in last call may be > included in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. > > This is a long document- 86 pages! It is a proposal for how to use OAuth 2.0 > and CoAP to provide authorization security for Internet of Things (IoT) > devices. IoT devices are often criticized as not being very secure, so this > seems like a useful initiative. RFC 7228 (Technology for Constrained-Node > Networks, and Informational document) is cited as inspiration and reference for > this work. CoAP (RFC 7252) is expressly designed for the sort of environment > that characterizes many IoT devices, hence is seems a natural choice for this > authorization-focused framework. OAuth is not as obvious a candidate building > block in this context, e.g., it is expressly designed for the HTTP context, yet > CoAP is cited as the replacement for HTTP. This document adapts OAuth for the > CoAp context. The WG did consider a variety of options before settling on the OAuth architecture, so we can probably say that "the other extant options were worse". > This document has an extensive, 6-page Security Considerations section, > appropriate for a document specifying an authorization framework. It begins by > citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819), and > OAuth 2.0 Token Introspection (RFC 7662). All three of these documents are > relevant, and they contain substantial Security Consideration sections. > > Section 6.1 deals with security for the tokens that are transmitted to convey > authorization information. In general the requirements and advice provided here > are good; I would prefer to see the admonition against use of a shared secret > key for a group of serves to be a MUST NOT, as opposed to just NOT RECOMMENDED. > I am not convinced that the suggestion for short lifetime tokens is necessary; > we have seen how short duration certificate lifetimes and frequent CRL issuance > in PKI contexts often is neither required nor advisable. This section ends by > noting that only client-initiated revocation of tokens is addressed by RFC > 7009. The authors note that revocation of long lifetime token remains an open > issue. If this is likely to be a common case for IoT devices, leaving this as a > TBD is not great. I think that there's a significant difference between the PKIX and OAuth workflows as deployed here, that's relevant -- in PKIX the CA has the "one-time" certification decision with some follow-on revocation status information that many things don't make use of or don't put in the critical path; in the OAuth world most deployments have the AS regularly involved in authentication decisions, whether that's the RS querying "is this token still valid?" or having a refresh token periodically refreshed into a new access token on a timescale of hours. There's more of an expectation that the AS can actively break these ongoing/recurring authorization flows when something goes wrong, whereas when the CA issues a CRL it sometimes feels more like "toss it over the wall and hope that the relying party bothers to check". That's not to say that the OAuth way is perfect, of course, but hopefully gives some sense of why it feels more natural to the authors/WG. > Section 6.2 addresses communication security issues. The section opens by > requiring an authorization server to offer confidentiality for client > interactions, but the wording implies that a client need not make use of such > protection. The reader is reminded that security requirements expressed in > Section 5 of this document (a 25-page long section) MUST be addressed by a > profile. I’d prefer to see references to specific parts of Section 5 that > expressly addresses confidentiality, so that a reader can better understand > when it is safe to reject the offer of confidentiality by a server. Encryption > of CWTs is used as an example, which is appropriate because CBOR CWT is the > default token format. The final paragraph of this section says that “developers (I'll reiterate for everyone that CWTs are not necessarily encrypted, though they can be. In the Web/OAuth world, encrypted JWTs are hardly the norm.) > MUST ensure that … ephemeral credentials … are not leaked to third parties.” > This is good advice, but since adversaries are assumed to have physical access > to IoT devices, the scope of this mandate is not clear. For example, is this > text arguing for use of tamper-resistant hardware for storing private or > session keys in IoT devices? > > Section 6.3 focuses on long-term credentials. The sections begins by noting the > challenges associated with providing protection for such credentials in devices > in publicly-accessible locations, explicitly referring to specialized hardware. > This a good, clear statement, not like the ambiguous MUST at the end of 6.2. > The text requires that compromise of a credential at one device MUST NOT lead > to compromise of other credentials not linked to the device in question. > However, the next sentence says that sharing of secret (and, presumably, > private) keys is NOT RECOMMENDED. This is a somewhat inconsistent pair of > statements; if secret keys are shared, then the MUST NOT will be violated, > right? Why not just say that secret keys MUST NIOT be shared across devices? > The section states that operators should have procedures to replace credentials > that have been (or are suspected to have been) compromised. Why is this > admonition not a SHOULD? The mildly-worded (“… also need to …) advice about > decommissioning devices seems minimally helpful. If this is important than make > it a SHOULD, if it’s not, then RECOMMEND it. Doesn't RFC 2119 say that SHOULD and RECOMMENDED are synonymous? > Section 6.4 discusses the challenges associated with securing initial > communication between a client and a resource server (RS). This communication > makes use of the (appropriately-named) Creation Hints message defined in 5.1.2. > The basis mechanism suggested here is use of a (possibly hard coded) list of > trusted authorization servers (AS’s) and associated credentials, e.g., > certificate fingerprints. The discussion here notes the potential for a DoS > attack against an AS by a compromised RS, by having clients sends requests to > the targeted AS. This is a useful comment, after noting that compromise of an > RS would not cause an AS to grant requests to clients that it is not serving. > > Section 6.5 summarizes the “minimal” communication security requirements for > the elements of the system described in this document (clients, AS’s and RS’s). > I think it’s useful to collect these requirements in one place, although they > have been described in various parts of Section 5. Unfortunately, the first > sub-section seems to contradict Section 6.2! Specifically the text here says > that all communication between a client and an AS MUST be encrypted, where as > 6.2 requires only that an AS offer confidentiality. This inconsistency needs to > be reconciled. The next subsection seems to be consistent. The final subsection > (C-RS) notes the challenges of initial C/RS communication, and offers some > suggested approaches. Some of the wording here is awkward. For example, the > text notes that DTLS with server-side authentication “can be possible and are > RECOMMENDED if supported by both parties.” It would be better to state that > “DTLS with server-side authentication is a RECOMMENDED mechanism for use in > this context, and SHOULD be employed if supported by both the C and the RS.” (I'm told that there are devices for which DTLS is too heavyweight to be implementable, and I suspect that's related to this wording.) > Section 6.6 deals with token lifetimes. The section begins by suggesting use of > nonces (as described in 5.1.2) to counter replay attacks in the event of “clock > drift” between an RS and an AS. I appreciate the analysis of mechanisms that > can be used to address the clock drift issue, including the discussion of > potential problems associated with using nonces in the face of a reboot. > However, the text provides no indication of how much “drift” is tolerable, vs. > when use of nonces is needed, and 5.1.2 does not even mention clock drift. > Perhaps the text can be revised to provide additional advice re clock drift. It's always hard to give concrete advice about clock drift, but worth a re-think, as you note. Kerberos went with 5 minutes of slop back in '93, and that ends up being way more than you need if things are working decently well, but still not enough for some broken systems. Thanks again, Ben > Section 6.7 very briefly discussed the issue of combining profiles. The bottom > line is that the security of a profile MUST NOT depend on the assumption that > the profile is used exclusively throughout a given deployment. That’s a nice, > straightforward warning! > > Section 6.8 discusses circumstances in which data is transmitted and may not > encrypted, e.g., error messages. The discussion here is fairly clear, and > includes a RECOMMENTATION and a MUST, as well as an analysis of potential risks > associated with transmitting different types of information w/o confidentiality > protection. The section title says “unprotected” but this discussion focuses > only on confidentiality, so a more descriptive title might help. > > Section 6.9 provides guidance on how to deal with the ambiguity of how to match > an “audience” value to a specific resource server. The authors admit that the > Section 5 discussion about the (optional) audience parameter in the OAuth token > is vague. They note that this is intentional, to accommodate a wide range of > deployment scenarios. Thus the discussion in this section provides guidance > for several scenarios. This is a reasonable way to deal with the ambiguity from > Section 5. > > Section 6.10 examines denial of service attacks in the context of > “introspection,” an optional aspect of OAuth which may be employed in this > framework. The text examines two DoS attacks, one against resource servers and > one against authorization servers, and suggests mitigations for both. > > Section 7 discusses privacy implications of the proposed framework. The > discussion here is useful, addressing a set of concerns that arise due to > client interactions with the AS and RS elements of the framework. > > From nobody Thu Dec 12 12:44:42 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FC81200BA; Thu, 12 Dec 2019 12:44:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stewart Bryant Message-ID: <157618348089.20903.16122189372846633578@ietfa.amsl.com> Date: Thu, 12 Dec 2019 12:44:40 -0800 Archived-At: Subject: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2019 20:44:41 -0000 Reviewer: Stewart Bryant Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ace-oauth-authz-27 Reviewer: Stewart Bryant Review Date: 2019-12-12 IETF LC End Date: 2019-12-13 IESG Telechat date: Not scheduled for a telechat Summary: Reviewed from the point of view of a generalist, this is a well written document with just a few nits that ought be be addressed. Major issues: None Minor issues: None Nits/editorial comments: Abstract This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 SB> OAuth 2.0 needs a RFC or other reference ===== and CoAP, SB> CoAP is not in the list of well-known abreviations and needs expanding ==== thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. While prior work on authorization solutions for the Web and for the mobile environment also applies to the Internet of Things (IoT) environment, many IoT devices are constrained, for example, in terms of processing capabilities, available memory, etc. For web applications on constrained nodes, this specification RECOMMENDS the use of CoAP [RFC7252] as replacement for HTTP. SB> Please expand CoAP === A detailed treatment of constraints can be found in [RFC7228], and SB> I think you should provide a short context on "constraints" the different IoT deployments present a continuous range of device and network capabilities. Taking energy consumption as an example: At one end there are energy-harvesting or battery powered devices which have a tight power budget, on the other end there are mains- powered devices, and all levels in between. === More detailed, interoperable specifications can be found in profiles. SB> What do you mean by "profiles" as a word on its own? ==== A third building block is CBOR [RFC7049], SB> CBOR needs to be expanded on first use. ==== HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also viable candidates. SB> These really need references SB> Except for HTTP the abreviations need expanding on first use. ===== In this example, the attribute AS points the receiver of this message to the URI "coaps://as.example.com/token" to request access permissions. The originator of the AS Request Creation Hints payload (i.e., RS) uses a local clock that is loosely synchronized with a time scale common between RS and AS (e.g., wall clock time). Therefore, it has included a parameter "nonce" (see Section 5.1.2.1). SB> I think the above text could usefully be re-worded for clarity. SB> The "therefore" does not seem to follow the preceeding text. ==== o A RS sending a "cnonce" parameter in an an AS Request Creation SB> An RS... ===== From nobody Fri Dec 13 07:10:26 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF87120219 for ; Fri, 13 Dec 2019 07:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 XmyiHWZ05uw8 for ; Fri, 13 Dec 2019 07:10:20 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150073.outbound.protection.outlook.com [40.107.15.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1919D120180 for ; Fri, 13 Dec 2019 07:10:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E9ExbBfAI+qJVP4AF3fGOl+HOjTI6sEgVObiQYn7se+N9KNFoo9nDuZRK1O5we+IEFFKew/UVINZAXuuVx99iGsiDDRx8fKBo2faXMkOa1by+PdKH6+t9zg6C+Vq0K3jnk/g8UiyHDoBzicZtNFR1Cz6b1e43qrT96CHaleKXmtcf5p8sEnmjH4h9iRwj7Te2H+RGCCk3YR3DCcLxrENmazh2J8cBITjart/WUePba9Im40qCU7OMdTqpPTtcCBokGHg9wzyKGnmgB2inC6rReRK0XgT8TunpcGAaYil/2E4edZoXRmL3p7jaZLjk5MfscnRvZZtzKK6g8Y6EETEng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5mTO3BDbm3hrWto1CCq/QzCq4sYux9d9j+adOx82hdY=; b=MNmWq4nPrGQDGE1HkUw04VYpxcMp+JKmcZJBlBi55yjKs5UH5UuTJf/sovD3HwR1VrG03uvdwZW8nTdHzXsX1alawz40D9YdFh57WJ5LJRUFr60CBNAYT15+RxMi/Z+4rkZW1xm2CV4UTY+1N71KDoXQoRVpwAlq17eN6y976S1vTxuuqGElQs7uSyuQSWEHT9PcEaG6YAWraWcK+esWkT/TMvlhBgsMjs55EKkm/oWTKA/UJmbZHVH0CaMGFO4HlA4YeXiyEgQyf7a1V4K2VTIP8qoQXCc0I0saO0DBms6hK9bYW+0eEA+OIzbQQYxK6YqkqMPlh47AgvySBX78hw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5mTO3BDbm3hrWto1CCq/QzCq4sYux9d9j+adOx82hdY=; b=XaGWz5rz0IMfuNqwsn6W/ItR8skp+ojLyWAYpqYsATspp56kjw01SQMXbeOaq2OQumh0HU2WBWgK/D+ehsc/u/ughTtsgYvYL/UM4+K2pHymYYNAkMAH0VhKKhbfiNWLW/+FMS8i1aBAfPwYpXxnvokHa2kMgTHGLTBZwzFKQHs= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB6055.eurprd07.prod.outlook.com (20.178.93.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.4; Fri, 13 Dec 2019 15:10:17 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277%6]) with mapi id 15.20.2538.017; Fri, 13 Dec 2019 15:10:17 +0000 From: Francesca Palombini To: Cigdem Sengul , Ace Wg Thread-Topic: [Ace] Review for draft-palombini-ace-coap-pubsub-profile Thread-Index: AQHVps/FUW0hoZUPcUeZ6nwhguB0oae4Uf0A Date: Fri, 13 Dec 2019 15:10:16 +0000 Message-ID: <75220EAA-9455-4691-9E99-3E16401D1309@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6262f95f-8bc9-4458-3dda-08d77fde901f x-ms-traffictypediagnostic: AM6PR07MB6055: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0250B840C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(189003)(199004)(52314003)(86362001)(6486002)(53546011)(186003)(33656002)(26005)(44832011)(6506007)(36756003)(2616005)(5660300002)(6512007)(110136005)(2906002)(316002)(8676002)(81156014)(76116006)(91956017)(66556008)(66946007)(66476007)(30864003)(478600001)(9326002)(8936002)(64756008)(66446008)(71200400001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB6055; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hI+wTtXmLpt8/VLMPOde6jyh1YDuNhGAxiZJ49JktEVBDz2qvvNrPos3Cc1xW7fcqrNWyIGpeo6JlhDyWLaa8p44LpUIawH16vcPnc42qPooCa0gNAe0e5ZRnQR4HW64TkAyoYdKtBsS1nYGB3gRpyhwyKNqmKegBcRFUsA/VNzN8Mb0ml9EI6J/OGZeFSQ5lfb4qKEz4ADn/Hmj2pWIgDls5l8sNI7a1JZsMERH4+lcsHP0wC/EqzrAo8bjQyKfmLlJqJpijxHoDO6/TiYZbNSWrDw1JKxVKRAAuA0BTj0IQ0Udt/vik0x+QfGwDqvV3i5bSYfuQc6YuovNh3OP5u/vw20Fk4vk3EaTTOY2t+p/+rfysN4MD1YQStmBz4KO4oqsbzthL/+XQ1qk0DV2dk2TJREr8xhM2tA2iNOY3s0J3aprOcjGa6xr+v3W5taX+gW/nVpvMXquzLVZAxs+lwef0zbvl03ZMnE605Y0OJM0XpzBLgF/Vf8pNO7TM0ob x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_75220EAA945546919E993E16401D1309ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6262f95f-8bc9-4458-3dda-08d77fde901f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 15:10:17.2928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6NphDqGHGv3e5vCqxcMBlM/XJIhHkPkDtXJmkEgQ+5G6U4XQZi5CUI3MSNBOA6XLTteujdi6ETbkTMDuDS5MQbnbuGizBXIgZk5yz548t5cZII2+srRdXUAjV2aRXKB5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6055 Archived-At: Subject: Re: [Ace] Review for draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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: Fri, 13 Dec 2019 15:10:23 -0000 --_000_75220EAA945546919E993E16401D1309ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2lnZGVtLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgcmV2aWV3IGFuZCB5b3VyIHN1cHBv cnQgb2YgdGhpcyBkb2N1bWVudCEgWW91ciBwb2ludHMgYXJlIHZlcnkgdmFsaWQsIGFuZCBvZiBj b3Vyc2UgeW91IGFyZSByaWdodCB3aXRoIG5vdGljaW5nIHRoYXQgYSByZXZpc2lvbiBpcyBuZWVk ZWQgdG8gYWRhcHQgdGhlIHRleHQgdG8gbWFrZSBpdCB3b3JrIGZvciBNUVRULiBJIGFwcHJlY2lh dGUgeW91ciBjb21tZW50cyBhYm91dCB0b3BpY3MgaGllcmFyY2h5IGFzIHdlbGwsIHRoYXQgaXMg c29tZXRoaW5nIHdlIGRpZCBub3QgdGhpbmsgYWJvdXQgYmVmb3JlIGFuZCBkZWZpbml0ZWx5IG5l ZWQgc29tZSBkaXNjdXNzaW9uLg0KDQpEZXRhaWxlZCBhbnN3ZXJzIGlubGluZS4NCg0KRnJhbmNl c2NhDQoNCkZyb206IEFjZSA8YWNlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaWdk ZW0gU2VuZ3VsIDxjaWdkZW0uc2VuZ3VsQGdtYWlsLmNvbT4NCkRhdGU6IEZyaWRheSwgMjkgTm92 ZW1iZXIgMjAxOSBhdCAxNzoxMg0KVG86IEFjZSBXZyA8YWNlQGlldGYub3JnPg0KU3ViamVjdDog W0FjZV0gUmV2aWV3IGZvciBkcmFmdC1wYWxvbWJpbmktYWNlLWNvYXAtcHVic3ViLXByb2ZpbGUN Cg0KSGVsbG8sDQoNCkFzIEkgcmVtb3RlbHkgcHJvbWlzZWQgaW4gdGhlIFdHIG1lZXRpbmcgaW4g U2luZ2Fwb3JlLCBoZXJlIGlzIG15IHJldmlldyBvZiB0aGUgcHVic3ViLWNvYXAgZG9jdW1lbnQu DQoNCldoZW4gcmV2aWV3aW5nIHRoZSBkb2N1bWVudCwgSSBoYXZlIGtlcHQgdHdvIHRoaW5ncyBp biBtaW5kOiBob3cgdGhlIGRvY3VtZW50IHJlYWRzIG5vdywgYW5kIHdoZXRoZXIgaXQgY2FuIGVh c2lseSBiZSBleHRlbmRlZCB0byBpbmNsdWRlIE1RVFQgYXMgd2VsbC4gIEnigJl2ZSB1bmRlcnN0 b29kIGluY2x1ZGluZyBNUVRUIGlzIGluIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50IGluIHRoZSB3 b3JrZ3JvdXAgbWVldGluZyBpbiBTaW5nYXBvcmUuIEkgd291bGQgYmUgaGFwcHkgdG8gaGVscCwg aWYgeW91IG5lZWQgbWUgdG8sIGZvciBNUVRULXNwZWNpZmljIGNvbnRyaWJ1dGlvbnMgdG8gdGhp cyBkcmFmdC4gIERvaW5nIHRoaXMgd291bGQgYWxsb3cgdGhlIG1xdHRfdGxzIHByb2ZpbGUgdG8g cHJvZ3Jlc3MgaW5kZXBlbmRlbnRseSBvZiB0aGlzIGRvY3VtZW50IGJ5IHN0YXRpbmcgdGhhdCBj b250ZW50IHByb3RlY3Rpb24gaXMgb3V0IG9mIHNjb3BlIGZvciBtcXR0X3RscyBwcm9maWxlIGFu ZCByZWZlcnJpbmcgdG8gdGhpcyBkb2N1bWVudCBmb3IgYSBzb2x1dGlvbi4NCg0KSSB3YW50IHRv IHJlcGVhdCBteSBzdXBwb3J0IGZvciB0aGUgYWRvcHRpb24gb2YgdGhpcyBwcm9maWxlLCBhcyBp dCBhZGRyZXNzZXMgYSBzaWduaWZpY2FudCBwcm9ibGVtIGZvciBwdWJsaXNoZXJzIHRvIGNvbnN0 cmFpbiB0aGUgY29udGVudCBvZiB0aGVpciBwdWJsaWNhdGlvbnMgdG8gb25seSB0aGVpciBzdWJz Y3JpYmVycy4gSXQgZG9lcyBoYW5kbGUgdGhlIG11bHRpcGxlIHB1Ymxpc2hlcnMgdG8gYSBzaW5n bGUgdG9waWMgY2FzZSB3ZWxsIChhbGxvd2luZyBzdWJzY3JpYmVycyB0byBsZWFybiBhYm91dCBh bGwgdGhlIHB1Ymxpc2hlcnMgdG8gYSBzcGVjaWZpYyB0b3BpYykuDQoNCkluIHRoZSBmb2xsb3dp bmcsIEkgbGlzdCBhIGZldyB0aGluZ3MgcmVhZGluZyB0aGUgZHJhZnQgbWFkZSBtZSB0aGluaywg ZXNwZWNpYWxseSBpbiBpdHMgYXBwbGljYWJpbGl0eSB0byBNUVRUOg0KKDEpIFdoYXQgaXMgcGxh bm5lZCB0byBtYWtlIHRoaXMgZG9jdW1lbnQgYSBnZW5lcmljIHB1YnN1YiBzb2x1dGlvbj8gV2ls bCB0aGVyZSBhIGdlbmVyaWMgYXJjaGl0ZWN0dXJlIHNlY3Rpb24sIGFuZCBzcGVjaWZpYyBkZXNj cmlwdGlvbnMgZm9yIGVhY2ggb2YgdGhlIHByb3RvY29scz8NCg0KRlA6IFllcywgSSBhbSBwbGFu bmluZyB0byBtYWtlIHNvbWUgdXBkYXRlcyB0byB0aGUgdGV4dCB0byBtYWtlIHRoaXMgZ2VuZXJp Yy4gSW4gZ2VuZXJhbCwgSSB0aGluayB0aGUgc3RydWN0dXJlIG9mIHRoZSBkcmFmdCB3aWxsIGJl IHRoZSBzYW1lLCBidXQgZWFjaCBzZWN0aW9uIHdvdWxkIGVpdGhlciBoYXZlIGEgc2VudGVuY2Ug b3IgKGlmIGxvbmdlciB0ZXh0IGlzIG5lZWRlZCkgYSBzdWJzZWN0aW9uIHRhbGtpbmcgYWJvdXQg dGhlIGRpZmZlcmVudCBhbHRlcm5hdGl2ZXMuIEZvciBleGFtcGxlLCBTZWN0aW9uIDIgd291bGQg cmVtb3ZlIGN1cnJlbnQgc3BlY2lmaWMgdGV4dCBhYm91dCBDb0FQIHB1YnN1YiAob25seSB0YWxr IGFib3V0IGdlbmVyYWwgcHVic3ViKSBhbmQgd291bGQgcmVwbGFjZSB0aGF0IHRleHQgd2l0aCBh biBhZGRpdGlvbmFsIHBhcmFncmFwaCBtZW50aW9uaW5nIHRoYXQgdGhlIHB1YnN1YiBwcm90b2Nv bCBjYW4gYmUgQ29BUCBvciBNUVRULiBTZWN0aW9uIDMgd291bGQgaGF2ZSAyIHN1YnNlY3Rpb25z LCBjb2FwX3B1YnN1Yl9hcHAgYW5kIG1xdHRfcHVic3ViX2FwcCwgZXRjLg0KDQpGb3IgaW5zdGFu Y2UsIGlmIGFuIE1RVFQgY2xpZW50IGltcGxlbWVudHMgdGhpcywgIHRoZSBjbGllbnQgd291bGQg dGFsayB0byBBUzEgdG8gZ2V0IGEgdG9rZW4gYmFzZWQgb24gdGhlIHdheSB3ZSBkZXNjcmliZSBp biB0aGUgbXF0dC10bHMgcHJvZmlsZSwgYW5kIHRoZW4gZ2V0IGtleWluZyBtYXRlcmlhbCBmb3Ig dG9waWNzIGZyb20gQVMyLg0KSSBleHBlY3QgdGhlIE1RVFQgY2xpZW50IHdvdWxkIHVzZSBhIGRp ZmZlcmVudCBwcm9maWxlIG5hbWUgbGlrZSBtcXR0X3Rsc19hcHAgdG8gc2lnbmFsIHRvIEFTMSB0 aGF0IGl0IGlzIHN1cHBvcnRpbmcgdGhlIGFwcGxpY2F0aW9uIGxheWVyIHNlY3VyaXR5LiBUaGlz IGlzIGJlY2F1c2UgdGhlIGRyYWZ0IGhpbnRzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGEgcG9saWN5 IGFncmVlbWVudCBiZXR3ZWVuIEFTMSBhbmQgQVMyOiDigJxOb3RlIHRoYXQgQVMxIGFuZCBBUzIg bWlnaHQgZWl0aGVyIGJlIGNvLXJlc2lkZW50IG9yIGJlIDIgc2VwYXJhdGUgcGh5c2ljYWwgZW50 aXRpZXMsIGluIHdoaWNoIGNhc2UgYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMgbXVzdCBiZSBleGNo YW5nZWQgYmV0d2VlbiBBUzEgYW5kIEFTMiwgc28gdGhhdCB0aGV5IGFncmVlIG9uIHJpZ2h0cyBm byAgam9pbmluZyBub2RlcyBhYm91dCBzcGVjaWZpYyB0b3BpY3Mu4oCdDQoNCkZQOiBUaGF0IGlz IGFsbCBjb3JyZWN0LiBNb3Jlb3Zlciwgd2UgY2FuIGFsc28gZGlzY3VzcyBkZXRhaWxzIHN1Y2gg YXMgd2hhdCBjb21tdW5pY2F0aW9uIHByb3RvY29sIHRoZSBDbGllbnQgdXNlcyB0byB0YWxrIHRv IEFTMi4gUmlnaHQgbm93IGFjZS1rZXktZ3JvdXBjb21tIGlzIG9ubHkgZGVmaW5lZCBmb3IgQ29B UCwgYnV0IGlmIE1RVFQgcHJlZmVycyB0byB1c2UgSFRUUCwgdGhhdCBpcyB2ZXJ5IGVhc3kgdG8g ZGVmaW5lLg0KDQoNCigyKSBJZiB3ZSBrZWVwIEFTMSBhcyB0aGUgbXF0dC10bHMgcHJvZmlsZSBB UywgdGhlbiBmb3IgY29uc2lzdGVuY3kgc2FrZSwgdGhlIE1RVFQgY2xpZW50IHdvdWxkIGV4cGVj dCB0byB0YWxrIHRvIEhUVFBTIHRvIEFTMiwgYnV0IHRoZSBjb2FwLXB1YnN1YiBkcmFmdCBkZXNj cmliZXMgdGhlc2UsIGV4cGVjdGVkbHksIGluIENvQVAuIFdpbGwgdGhlcmUgYmUgc3VwcG9ydCBm b3IgSFRUUFM/DQoNCkZQOiBJIHByb21pc2UgSSBkaWQgbm90IHJlYWQgdGhpcyBxdWVzdGlvbiBi ZWZvcmUgYW5zd2VyaW5nIHRoZSB0ZXh0IGFib3ZlIDopIFllcy4gVGhpcyBpcyByZWFsbHkgZWFz eSB0byBzcGVjaWZ5LCB3ZSBhbHJlYWR5IGRvIHRoaXMgd2l0aCBDQk9SL0pTT04sIGluIGFjZS1r ZXktZ3JvdXBjb21tOg0KDQpUaGUgQUNFIGZyYW1ld29yayBpcyBiYXNlZA0KICAgb24gQ0JPUiBb UkZDNzA0OV0sIHNvIENCT1IgaXMgdGhlIGZvcm1hdCB1c2VkIGluIHRoaXMgc3BlY2lmaWNhdGlv bi4NCiAgIEhvd2V2ZXIsIHVzaW5nIEpTT04gW1JGQzgyNTldIGluc3RlYWQgb2YgQ0JPUiBpcyBw b3NzaWJsZSwgdXNpbmcgdGhlDQogICBjb252ZXJzaW9uIG1ldGhvZCBzcGVjaWZpZWQgaW4gU2Vj dGlvbnMgNC4xIGFuZCA0LjIgb2YgW1JGQzcwNDldLg0KDQpXZSB3b3VsZCBhZGQgQ29BUC9IVFRQ IGluIHRoZSBzYW1lIHdheSAoIkNvQVAgaXMgZGVmYXVsdCwgYnV0IEhUVFAgd29ya3MgdGhlIHNh bWUgd2F5IikuIFRoZW4gdGhlIHB1YnN1Yi1wcm9maWxlIGNvdWxkIHNwZWNpZnkgd2hpY2ggcHJv dG9jb2wgaXMgdXNlZCBpbiB0aGUgZGlmZmVyZW50IHByb2ZpbGVzLg0KDQooMykgSW4gdGhlIG1x dHRfdGxzIHByb2ZpbGUsIHRoZSBBUyBncmFudHMgdG9rZW5zIHRoYXQgaWRlbnRpZnkgYm90aCDi gJxwdWJsaXNo4oCdIGFuZCDigJxzdWJzY3JpYmXigJ0gcmlnaHRzIGFuZCB0aGUgdG9waWNzIGJ5 IGFkZGluZyBzY29wZXMgaW4gdGhlIGZvcm1hdCwgZS5nLiDigJxwdWJsaXNoX3RvcGljMeKAnSDi gJxzdWJzY3JpYmVfdG9waWMyLyPigJ0uLiAgVGhpcyBmb3JtYXQgYWxsb3dzIHJlcHJlc2VudGlu ZyBhbGwgcHVibGlzaC9zdWJzY3JpYmUgcGVybWlzc2lvbnMgY29uY2lzZWx5IGZvciB0aGUgY2xp ZW50IHdoaWNoIG1heSBiZSBhY3RpbmcgYm90aCBhcyBhIHB1Ymxpc2hlciBhbmQgYSBzdWJzY3Jp YmVyLg0KSW4gdGhlIGNvYXAtcHVic3ViLCB0aGlzIGlzIHNlcGFyYXRlZCBiZXR3ZWVuIEFTMSBh bmQgQVMyLiDigJxBUzEgaG9zdHMgdGhlIHBvbGljaWVzIGFib3V0IHRoZSBCcm9rZXI6IHdoYXQg ZW5kcG9pbnRzIGFyZSBhbGxvd2VkIHRvIFB1Ymxpc2ggb24gdGhlIEJyb2tlci7igJ0g4oCcVGhl IEFTMiBob3N0cyB0aGUgcG9saWNpZXMgYWJvdXQgdGhlIHRvcGljOiB3aGF0IGVuZHBvaW50cyBh cmUgYWxsb3dlZCB0byBhY2Nlc3Mgd2hhdCB0b3BpYy4g4oCcDQpUaGUgY29hcC1wdWJzdWIgYWxz byBwZXJtaXRzIHRoYXQgQVMxIGNhbiBob3N0IHBvbGljaWVzIGFib3V0IHdoYXQgZW5kcG9pbnRz IGFyZSBhbGxvd2VkIHRvIFN1YnNjcmliZSB0byB0aGUgQnJva2VyLg0KDQpIb3dldmVyLCB3b3Vs ZG7igJl0IHRoaXMgc2VwYXJhdGlvbiBiZXR3ZWVuIEFTMSBhbmQgQVMyIGhhdmUgdGhlIGZvbGxv d2luZyBpc3N1ZTogUHVibGlzaGVyIFAsIGhhdmluZyB0aGUgcGVybWlzc2lvbiB0byBwdWJsaXNo IHRvIHRvcGljMSBhbmQgaGVuY2UsIHN1Y2Nlc3NmdWxseSBnZXR0aW5nIGFuIGFjY2VzcyB0b2tl biBmcm9tIEFTMSwgdGhlbiBnb2VzIGFoZWFkIGFuZCBzZW5kcyBhIFBVQkxJU0ggb24gdG9waWMg Miwgd2hpY2ggaXQgZG9lc27igJl0IGhhdmUgYSByaWdodCB0byBwdWJsaXNoLg0KV291bGRuJ3Qg dGhlIGJyb2tlciB3b3VsZCBwYXNzIHRoaXMgbWVzc2FnZSB0byBzdWJzY3JpYmVycywgYW5kIHRo ZSBzdWJzY3JpYmVycyB3b3VsZCBkaXNjYXJkIHRoZSBtZXNzYWdlIGJlY2F1c2UgdGhlIHB1Ymxp c2hlciBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlaXIg4oCccHVibGlzaGVycyBsaXN04oCdIChzdWJz Y3JpYmVycyBoYXZlIGFsbCB0aGUgcHVibGljIGtleXMgb2YgYWxsIHB1Ymxpc2hlcnMpLiBIYXZl IEkgbWlzc2VkIHNvbWV0aGluZywgZG9lcyB0aGUgZHJhZnQgcHJvdGVjdCBhZ2FpbnN0IHRoaXMg YXQgdGhlIGJyb2tlcj8NCg0KRlA6IE5vLCB0aGUgYnJva2VyIHdvdWxkIG5vdCBhY2NlcHQgdGhp cyBtZXNzYWdlLiBJbiBmYWN0LCBkdXJpbmcgdGhlIEFDRSBleGNoYW5nZSBiZXR3ZWVuIFB1Ymxp c2hlciwgQVMxLCBhbmQgQnJva2VyLCB0aGUgUHVibGlzaGVyIHdvdWxkIHBvc3QgYSB0b2tlbiB0 byB0aGUgQnJva2VyIHRoYXQgY29udGFpbnMgdGhlIHJlc291cmNlIGl0IGlzIGFsbG93ZWQgdG8g cHVibGlzaCB0bywgbmFtZWx5IGluIHRoaXMgY2FzZSB0b3BpYyAxLiBJZiBpdCBkb2VzIGhhdmUg cmlnaHRzIHRvIHB1Ymxpc2ggdG8gdG9waWMgMiBhcyB3ZWxsLCB0aGF0IHdvdWxkIGJlIGluY2x1 ZGVkIGluIHRoZSB0b2tlbi4gVGhhdCBpcyBjb3ZlcmVkIGJ5IHRoZSB0cmFuc3BvcnQgcHJvZmls ZSB1c2VkLCBhcyB5b3UgbWVudGlvbmVkIChNUVRUTC1UTFMvQ29BUCBPU0NPUkUpLiBPcnRob2dv bmFsbHkgdG8gdGhpcywgd2hlbiBnZXR0aW5nIHRoZSBrZXlzIGZyb20gQVMyIHRvIHByb3RlY3Qg dGhlIHB1YmxpY2F0aW9uLCBpZiB0aGUgUHVibGlzaGVyIGhhcyB0cmllZCB0byBwdWJsaXNoIHRv IHRvcGljIDIgd2l0aG91dCBoYXZpbmcgdGhlIGNvcnJlY3QgY29udGVudCBlbmNyeXB0aW9uIGtl eWluZyBtYXRlcmlhbCwgdGhlIGRlY3J5cHRpb24gb2YgdGhlIHB1YmxpY2F0aW9uIGF0IHRoZSBz dWJzY3JpYmVyIHdvdWxkIGZhaWwgZXZlbiBiZWZvcmUgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbi4g QnV0IHRoZSBTdWJzY3JpYmVyIHdvdWxkIG5vdCBnZXQgdGhlIHB1YmxpY2F0aW9uIGlmIHRoZSBQ dWJsaXNoZXIgaXMgbm90IGF1dGhvcml6ZWQgdG8gcHVibGlzaCBvbiB0aGF0IHRvcGljLiBOb3Rl IHRoYXQgaWYgdGhlIG93bmVyIHdhbnRzIHRvIHByb3RlY3QgdG9waWMgMSBhbmQgdG9waWMgMiB3 aXRoIHRoZSBzYW1lIGtleWluZyBtYXRlcmlhbCwgdGhhdCBpcyBwb3NzaWJsZSwgYnV0IHRoZW4g dGhlIGNhc2UgYWJvdmUgd291bGQgbm90IGJlIGFuIGF0dGFjayBidXQgYW4gYWNjZXB0YWJsZSBz Y2VuYXJpbyAoUHVibGlzaGVyIGFsbG93ZWQgdG8gcG9zdCB0byBib3RoIHRvcGljcywgcHVibGlj YXRpb24gcHJvdGVjdGVkIHdpdGggdGhlIHNhbWUga2V5KS4NCg0KRGlmZmVyZW50bHksIHdpdGgg dGhlIGN1cnJlbnQgd2F5IG1xdHRfdGxzIHNjb3BlcyBhcmUgZGVzY3JpYmVkLCBBUzEgd291bGQg bmVlZCB0byBrbm93IG5vdCBvbmx5IHdobyBjYW4gcHVibGlzaCBvciBzdWJzY3JpYmUsIGJ1dCBh bHNvIHRoZSBwb2xpY2llcyBvbiB0b3BpY3MuDQoNCkZQOiBCeSBwb2xpY2llcyBvbiBBUzEgSSBt ZWFuIGV4YWN0bHkgdGhhdDogIndoYXQgZW5kcG9pbnRzIGFyZSBhbGxvd2VkIHRvIHB1Ymxpc2gg b24gd2hhdCB0b3BpY3MiLiBJZiBvbmUgd2FudHMgdG8gY29udHJvbCB3aG8gY2FuIHN1YnNjcmli ZSwgdGhhdCB3b3VsZCBhbHNvIGJlIHBhcnQgb2YgdGhlIHNvLWNhbGxlZCBwb2xpY2llcy4NCg0K KDQpIFRoYXQgYnJpbmdzIG1lIHRvIGFub3RoZXIgcG9pbnQgcmVnYXJkaW5nIHRoaXMgbm90ZSBp biBjb2FwLXB1YnN1YiBwcm9maWxlLiBUaGUgcHJvZmlsZSBzYXlzOiDigJxIb3cgdGhlIHBvbGlj aWVzIGFyZSBleGNoYW5nZWQgW2JldHdlZW4gQVMxIGFuZCBBUzJdIGlzIG91dCBvZiBzY29wZSBm b3IgdGhpcyBzcGVjaWZpY2F0aW9uLuKAnSBJIHdvbmRlciB3aGV0aGVyIHRoZSB0b2tlbiB0aGUg Y2xpZW50IGdldHMgZnJvbSBBUzEgc2hvdWxkIGFsc28gYmUgdXNhYmxlIHRvd2FyZHMgQVMyLCBh bmQgQVMyIGlzIHJlcGxhY2VkIHdpdGggYW4gUlMgZm9yIHJldHJpZXZpbmcgdGhlIGtleWluZyBt YXRlcmlhbCBmb3IgdG9waWNzIChtb3JlIG9uIHRoaXMgbGF0ZXIpLCBpLmUuLCBBUzIgZG9lcyBu b3QgbmVlZCB0byBob3N0L21hbmFnZS9jb29yZGluYXRlIHBvbGljaWVzIHdpdGggQVMxLg0KDQpG UDogVGhhdCBpcyBhIHBvc3NpYmlsaXR5LiBSaWdodCBub3cgdGhpcyBpcyBub3QgdGhlIGNhc2Ug YmVjYXVzZSBJIHRob3VnaHQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGtlZXAgdGhlIHR3byAoImF1 dGhvcml6YXRpb24gdG8gcHVibGlzaCBvbiBvbmUgb3IgbW9yZSB0b3BpY3Mgb24gQnJva2VyIiBh bmQgImF1dGhvcml6YXRpb24gdG8gZ2V0IGVuY3J5cHRpb24ga2V5cyBmb3Igb25lIG9yIG1vcmUg dG9waWNzIikgaW5kZXBlbmRlbnQuIFRoZSByZWFzb24gZm9yIHRoYXQgd2FzIHRoYXQgdGhlIHNh bWUga2V5IGNvdWxkIGJlIHVzZWQgZm9yIHNldmVyYWwgdG9waWNzLCBpLmUuIFB1Ymxpc2hlciBQ IGNvdWxkIGJlIGFsbG93ZWQgdG8gcHVibGlzaCBvbiB0b3BpYyAxIGJ1dCBub3Qgb24gdG9waWMg MiwgZXZlbiB0aG91Z2ggdG9waWMgMSBhbmQgMiB1c2UgdGhlIHNhbWUgZW5jcnlwdGlvbiBrZXku IFllcywgdGhhdCBjb3VsZCBiZSBhIHdheSB0byBkbyBpdCwgYnV0IEkgYW0gbm90IHN1cmUgYWJv dXQgdGhlIGFkdmFudGFnZSwgYXBhcnQgZnJvbSB0aGUgb2J2aW91cyBwb2xpY2llcyBzeW5jaHJv bml6YXRpb24gKGkuZS4gaW4gdGhpcyB3YXkgdGhlcmUgd291bGQgYmUgbm8gbmVlZCBmb3Igc3lu Y2hyb25pemluZyBzaW5jZSBpbiBwcmFjdGljZSBBUzEgd291bGQga25vdyBib3RoIHdoYXQgdG9w aWMgUHVibGlzaGVyIFAgY2FuIHB1Ymxpc2ggdG8gYW5kIHdoYXQgY29udGVudCBlbmNyeXB0aW9u IGtleSBpdCBjYW4gcmV0cmlldmUpLiBCdXQgSSdkIGJlIGhhcHB5IHRvIGRpc2N1c3MgdGhhdCBm dXJ0aGVyLg0KDQooNSkgUmVnYXJkaW5nIGdyb3VwcyBhbmQgZ3JvdXAgbWVtYmVyc2hpcHMsIGl0 IHNlZW1zIGxpa2UgZm9yIHRoZSBkcmFmdCBncm91cCA9IGEgc2luZ2xlIHRvcGljLg0KDQpJbiBN UVRULCB0b3BpY3MgY2FuIGhhdmUgbGV2ZWwgc2VwYXJhdG9ycyBhbmQgbXVsdGktbGV2ZWwgKCMp IGFuZCBzaW5nbGUtbGV2ZWwgKCspIHdpbGRjYXJkcy4gIFNpbWlsYXJseSwgQ29BUCB3b3VsZCBh bHNvIGhhdmUgaGllcmFyY2hpZXMuDQoNCkZQOiBUaGFuayB5b3UgZm9yIGJyaW5naW5nIHRoaXMg dXAuIFlvdSBhcmUgcmlnaHQsIGhpZXJhcmNoaWVzIGFyZSBzb21ldGhpbmcgbm90IHJlYWxseSB0 aG91Z2h0IHRocm91Z2ggcmlnaHQgbm93IGluIHRoaXMgZG9jdW1lbnQuDQoNCkNvbnNpZGVyIHRo ZSBjYXNlIHdoZW4gYSBQVUJMSVNIRVIgaXMgYWxsb3dlZCB0byBwdWJsaXNoIHRvIHNwb3J0L3Rl bm5pcy9wbGF5ZXIxLyMgYnV0IG5vdCBzcG9ydC90ZW5uaXMvcGxheWVyMi8jLiAgVGhlIHBsYXll cnMnIGRpcmVjdG9yeSBtYXkgaGF2ZSBzdWItbGV2ZWxzIGxpa2Ug4oCccmFua2luZ3PigJ0uDQpB bmQgYSBzdWJzY3JpYmVyIGhhcyBwZXJtaXNzaW9ucyB0byBnZXQgY29udGVudCBmcm9tIHNwb3J0 L3Rlbm5pcy8jLg0KSXQgc2VlbXMgbGlrZSBzcG9ydC90ZW5uaXMvcGxheWVyMSB3b3VsZCBiZSBh IGdyb3VwLCBhbmQgc3BvcnQvdGVubmlzL3BsYXllcjIgYmUgYW5vdGhlciBncm91cC4NCkFuZCwg dGhlIHN1YnNjcmliZXIgbmVlZHMgdG8gYmUgaW4gdHdvIGdyb3Vwcy4gVGhpcyBpcyBmaW5lLCBJ IGJlbGlldmUsIGFjY29yZGluZyB0byB0aGlzIGRvY3VtZW50Lg0KDQpGUDogWWVzLCB3aGF0IHlv dSBkZXNjcmliZSBpcyBhIHZhbGlkIHNjZW5hcmlvIGNvdmVyZWQgYnkgdGhlIGRvY3VtZW50Lg0K DQpJbiBNUVRUIHRva2VuIHNjb3Blcywgd2UgYWxzbyBhY2NlcHRlZCB0aGF0IGEgcHVibGlzaGVy IHJlcHJlc2VudHMgaXRzIFBVQkxJU0ggcmlnaHRzIHdpdGggdG9waWMgZmlsdGVycyAobm90ZSBh IFBVQkxJU0ggbWVzc2FnZSBjYW5ub3QgYmUgc2VudCB0byBhIGZpbHRlciwgYnV0IHRoZSB0b3Bp YyBmaWx0ZXJzIGFyZSB1c2VmdWwgaW4gc3VtbWFyaXNpbmcgcGVybWlzc2lvbnMpLg0KTGV04oCZ cyBhc3N1bWUgdGhlcmUgaXMgYSBwdWJsaXNoZXIgd2l0aCBzY29wZSDigJxwdWJsaXNoX3Nwb3J0 L3Rlbm5pcy8rL3Jhbmtpbmdz4oCcPw0KDQpGUDogVGhlIGZpcnN0IHF1ZXN0aW9uIEkgaGF2ZSBp cyBpZiBpdCBpcyBldmVuIHBvc3NpYmxlIHRvIGluZGljYXRlIHNjb3BlIGxpa2UgdGhpcyBpbiBB Q0UuIEkgZG8gbm90IHRoaW5rIHNvIChhbmQgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9u ZyksIGFuZCBpbiB0aGlzIGNhc2UgdGhlIHNjb3BlIHdvdWxkIGhhdmUgdG8gYmUgZXhwcmVzc2Vk IGFzIHRoZSB1bmlvbiBvZiB0aGUgZm9sbG93aW5nIFVSSXM6IHB1Ymxpc2hfc3BvcnQvdGVubmlz L3BsYXllcjEvcmFua2luZ3MgYW5kIHB1Ymxpc2hfc3BvcnQvdGVubmlzL3BsYXllcjIvcmFua2lu Z3MNCg0KVGhlbiBiZWluZyBhIHBhcnQgb2YgYWxsIGdyb3VwcyAocGxheWVyIDEgYW5kIHBsYXll cjIpIGlzIHRvbyBnZW5lcmFsIGFzIHRoaXMgcHVibGlzaGVyIGNhbm5vdCBwdWJsaXNoIHRvIGV2 ZXJ5dGhpbmcgYnV0IG9ubHkgdG8g4oCccmFua2luZ3PigJ0uDQoNCkZQOiBCdXQgb25jZSB0aGUg c2NvcGUgaXMgZXhwcmVzc2VkIGZvciAicmFua2luZ3MiIG9ubHksIHRoZW4gdGhlIGRvYyBzaG91 bGQgY292ZXIgdGhpcyBjYXNlIHRvby4gVGhlbiBpdCBpcyB1cCB0byB0aGUgdG9waWMgb3duZXIg KGFuZCByZWZsZWN0ZWQgb24gdGhlIEFTMikgdG8gZGVjaWRlIGlmIHRoZSBrZXlpbmcgbWF0ZXJp YWwgaXMgdGhlIHNhbWUgZm9yIHJhbmtpbmdzIGFuZCBmb3IgdGhlIHVwcGVyLXRvcGljcyAoPyBh cyBvcHBvc2VkIHRvIHN1Yi10b3BpYykgcGxheWVyMSBhbmQgcGxheWVyMi4gQW5kIHNpbWlsYXJs eSwgaXQgd2lsbCBiZSB1cCB0byB0aGUgYnJva2VyIHRvIHZlcmlmeSB0aGF0IHRoZSBhdXRob3Jp emF0aW9uIGZvciBwdWJsaXNoaW5nIHRvIHJhbmtpbmdzIGlzIHNlcGFyYXRlIGZyb20gcHVibGlz aGluZyB0byBwbGF5ZXIxIGFuZCBwbGF5ZXIyLiBJdCBpcyBhbHNvIGEgdmFsaWQgY2FzZSB0byBt YWtlIGl0IHNvIHN1Yi10b3BpY3MgaW5oZXJpdCBhdXRob3JpemF0aW9ucywgYnV0IHRoYXQgd291 bGQgYmUgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHRvIGRlY2lkZS4gQW55d2F5LCB0aGVzZSBhcmUg YWxsIHZhbGlkIGNvbnNpZGVyYXRpb25zIHRoYXQgbmVlZCB0byBiZSBtYWRlIGluIHRoZSBkb2N1 bWVudC4NCg0KQW5vdGhlciBhcHByb2FjaCBjb3VsZCBiZSBlYWNoIHB1Ymxpc2hlciBjcmVhdGlu ZyBpdHMgZ3JvdXAuIFRoaXMgd2F5IHRoZSBudW1iZXIgb2YgZ3JvdXBzIHNjYWxlcyB3aXRoIHRo ZSBudW1iZXIgb2YgcHVibGlzaGVycyAoYW5kIHRoZSBDT1NFIGtleXMgaXMgcGVyIHB1Ymxpc2hl cikuDQoNCkZQOiBJIGRvbid0IHRoaW5rIHRoaXMgc2NhbGVzIHdlbGwsIGJ1dCB5ZXMsIGFuIGFw cGxpY2F0aW9uIGNvdWxkIGFsc28gZG8gdGhpcy4NCg0KU28sIHRoZSBzdWJzY3JpYmVyIHN0aWxs IGFza3MgcGVybWlzc2lvbnMgZm9yIGFuZCBzdWJzY3JpYmVzIHRvIHRvcGljIGZpbHRlcnMuDQpU aGVyZSBuZWVkcyB0byBiZSBhIHNvbHV0aW9uIHRoYXQgbWFwcyB0aGUgdG9waWNzIHRvIGEgcHVi bGlzaGVyIGxpc3QuLi4NCkFTMSAgKHNlZSBteSBlYXJsaWVyIGRpc2N1c3Npb24gb24gd2hvIGtl ZXBzIHRoZSBwb2xpY3kgaW5mb3JtYXRpb24pIGtub3dzIHdobyBoYXMgdGhlIHJpZ2h0IHRvIHB1 Ymxpc2ggdG8gdGhlc2UgdG9waWNzIGluIHRoZWlyIHBvbGljeSBkYXRhYmFzZSBhbmQgaGFzIHRo ZSBwdWJsaWMga2V5IGluZm9ybWF0aW9uIGZvciB0aGVtLiBBUzIgaG9zdHMgdGhlIENPU0Uga2V5 IGZvciB0aGlzIHB1Ymxpc2hlci4NCg0KUHV0dGluZyBhbGwgdGhpcyBpbmZvcm1hdGlvbiB0b2dl dGhlciwgIHdoZW4gYSBtZXNzYWdlIGlzIHJlY2VpdmVkLCB0aGUgc3Vic2NyaWJlciB3b3VsZCB1 c2UgdGhlIHB1Ymxpc2hlcidzIHB1YmxpYyBrZXkgdG8gdmVyaWZ5IHRoZSBwdWJsaXNoZXIgc2ln bmF0dXJlICh0aGUgZHJhZnQgYWxyZWFkeSBzdXBwb3J0cyB0aGlzKSwgdGhlbiBsb2NhdGUgdGhl IHN5bW1ldHJpYyBrZXkgaXQgcmVjZWl2ZWQgZnJvbSB0aGUgQVMyIGZvciB0aGlzIHB1Ymxpc2hl ciB0byBkZWNyeXB0IHRoZSBtZXNzYWdlLg0KDQpXb3VsZCB0aGVyZSBiZSBhbnkgcHJvYmxlbXMg d2l0aCB0aGlzIGFwcHJvYWNoPw0KDQpGUDogTm8gSSBkb24ndCBzZWUgcHJvYmxlbXMgd2l0aCB0 aGlzLCBhbHRob3VnaCBJIGFtIG5vdCBzdXJlIHdlIG5lZWQgdG8gZGVzY3JpYmUgdGhpcyBpbiB0 aGlzIGRvY3VtZW50LiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUgc2NlbmFyaW9zIHNo b3VsZCBiZSBjb3ZlcmVkIGJ5IHRoZSBjdXJyZW50IHNwZWMuIE9yIGRpZCBJIG1pc3Mgc29tZXRo aW5nPw0KDQpOaXRzOg0KRmlndXJlIDI6IE5lZ29jaWF0aW9uIC0+IE5lZ290aWF0aW9uDQoNCkZQ OiBPaywgd2lsbCBmaXguDQoNCktpbmQgcmVnYXJkcywNCi0tQ2lnZGVtDQo= --_000_75220EAA945546919E993E16401D1309ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9FFEB65B8F61384391940EDB23119792@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIENpZ2RlbSw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldyBhbmQgeW91 ciBzdXBwb3J0IG9mIHRoaXMgZG9jdW1lbnQhIFlvdXIgcG9pbnRzIGFyZSB2ZXJ5IHZhbGlkLCBh bmQgb2YgY291cnNlIHlvdSBhcmUgcmlnaHQgd2l0aCBub3RpY2luZyB0aGF0IGEgcmV2aXNpb24g aXMgbmVlZGVkIHRvIGFkYXB0IHRoZSB0ZXh0IHRvIG1ha2UgaXQgd29yayBmb3IgTVFUVC4gSSBh cHByZWNpYXRlIHlvdXIgY29tbWVudHMgYWJvdXQNCiB0b3BpY3MgaGllcmFyY2h5IGFzIHdlbGws IHRoYXQgaXMgc29tZXRoaW5nIHdlIGRpZCBub3QgdGhpbmsgYWJvdXQgYmVmb3JlIGFuZCBkZWZp bml0ZWx5IG5lZWQgc29tZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZXRh aWxlZCBhbnN3ZXJzIGlubGluZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJhbmNlc2NhPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb206IEFjZSAmbHQ7YWNlLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiBDaWdkZW0gU2VuZ3VsICZsdDtjaWdkZW0uc2VuZ3VsQGdtYWlsLmNv bSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdGU6IEZyaWRheSwg MjkgTm92ZW1iZXIgMjAxOSBhdCAxNzoxMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VG86IEFjZSBXZyAmbHQ7YWNlQGlldGYub3JnJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogW0FjZV0gUmV2aWV3IGZvciBkcmFmdC1wYWxvbWJp bmktYWNlLWNvYXAtcHVic3ViLXByb2ZpbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8s IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIHJlbW90ZWx5IHByb21pc2VkIGluIHRoZSBX RyBtZWV0aW5nIGluIFNpbmdhcG9yZSwgaGVyZSBpcyBteSByZXZpZXcgb2YgdGhlIHB1YnN1Yi1j b2FwIGRvY3VtZW50Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gcmV2aWV3aW5nIHRo ZSBkb2N1bWVudCwgSSBoYXZlIGtlcHQgdHdvIHRoaW5ncyBpbiBtaW5kOiBob3cgdGhlIGRvY3Vt ZW50IHJlYWRzIG5vdywgYW5kIHdoZXRoZXIgaXQgY2FuIGVhc2lseSBiZSBleHRlbmRlZCB0byBp bmNsdWRlIE1RVFQgYXMgd2VsbC4mbmJzcDsgSeKAmXZlIHVuZGVyc3Rvb2QgaW5jbHVkaW5nIE1R VFQgaXMgaW4gc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQgaW4gdGhlIHdvcmtncm91cCBtZWV0aW5n DQogaW4gU2luZ2Fwb3JlLiBJIHdvdWxkIGJlIGhhcHB5IHRvIGhlbHAsIGlmIHlvdSBuZWVkIG1l IHRvLCBmb3IgTVFUVC1zcGVjaWZpYyBjb250cmlidXRpb25zIHRvIHRoaXMgZHJhZnQuJm5ic3A7 IERvaW5nIHRoaXMgd291bGQgYWxsb3cgdGhlIG1xdHRfdGxzIHByb2ZpbGUgdG8gcHJvZ3Jlc3Mg aW5kZXBlbmRlbnRseSBvZiB0aGlzIGRvY3VtZW50IGJ5IHN0YXRpbmcgdGhhdCBjb250ZW50IHBy b3RlY3Rpb24gaXMgb3V0IG9mIHNjb3BlIGZvciBtcXR0X3Rscw0KIHByb2ZpbGUgYW5kIHJlZmVy cmluZyB0byB0aGlzIGRvY3VtZW50IGZvciBhIHNvbHV0aW9uLiA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB3YW50IHRvIHJlcGVhdCBteSBzdXBwb3J0IGZvciB0aGUgYWRvcHRpb24gb2YgdGhp cyBwcm9maWxlLCBhcyBpdCBhZGRyZXNzZXMgYSBzaWduaWZpY2FudCBwcm9ibGVtIGZvciBwdWJs aXNoZXJzIHRvIGNvbnN0cmFpbiB0aGUgY29udGVudCBvZiB0aGVpciBwdWJsaWNhdGlvbnMgdG8g b25seSB0aGVpciBzdWJzY3JpYmVycy4gSXQgZG9lcyBoYW5kbGUgdGhlIG11bHRpcGxlIHB1Ymxp c2hlcnMgdG8gYSBzaW5nbGUNCiB0b3BpYyBjYXNlIHdlbGwgKGFsbG93aW5nIHN1YnNjcmliZXJz IHRvIGxlYXJuIGFib3V0IGFsbCB0aGUgcHVibGlzaGVycyB0byBhIHNwZWNpZmljIHRvcGljKS4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgZm9sbG93aW5nLCBJIGxpc3QgYSBmZXcg dGhpbmdzIHJlYWRpbmcgdGhlIGRyYWZ0IG1hZGUgbWUgdGhpbmssIGVzcGVjaWFsbHkgaW4gaXRz IGFwcGxpY2FiaWxpdHkgdG8gTVFUVDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPigxKSBXaGF0IGlzIHBsYW5uZWQgdG8gbWFrZSB0aGlzIGRvY3VtZW50IGEgZ2VuZXJpYyBw dWJzdWIgc29sdXRpb24/IFdpbGwgdGhlcmUgYSBnZW5lcmljIGFyY2hpdGVjdHVyZSBzZWN0aW9u LCBhbmQgc3BlY2lmaWMgZGVzY3JpcHRpb25zIGZvciBlYWNoIG9mIHRoZSBwcm90b2NvbHM/Jm5i c3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RlA6IFllcywgSSBhbSBwbGFubmluZyB0byBt YWtlIHNvbWUgdXBkYXRlcyB0byB0aGUgdGV4dCB0byBtYWtlIHRoaXMgZ2VuZXJpYy4gSW4gZ2Vu ZXJhbCwgSSB0aGluayB0aGUgc3RydWN0dXJlIG9mIHRoZSBkcmFmdCB3aWxsIGJlIHRoZSBzYW1l LCBidXQgZWFjaCBzZWN0aW9uIHdvdWxkIGVpdGhlciBoYXZlIGEgc2VudGVuY2Ugb3IgKGlmIGxv bmdlciB0ZXh0IGlzIG5lZWRlZCkgYSBzdWJzZWN0aW9uIHRhbGtpbmcNCiBhYm91dCB0aGUgZGlm ZmVyZW50IGFsdGVybmF0aXZlcy4gRm9yIGV4YW1wbGUsIFNlY3Rpb24gMiB3b3VsZCByZW1vdmUg Y3VycmVudCBzcGVjaWZpYyB0ZXh0IGFib3V0IENvQVAgcHVic3ViIChvbmx5IHRhbGsgYWJvdXQg Z2VuZXJhbCBwdWJzdWIpIGFuZCB3b3VsZCByZXBsYWNlIHRoYXQgdGV4dCB3aXRoIGFuIGFkZGl0 aW9uYWwgcGFyYWdyYXBoIG1lbnRpb25pbmcgdGhhdCB0aGUgcHVic3ViIHByb3RvY29sIGNhbiBi ZSBDb0FQIG9yIE1RVFQuDQogU2VjdGlvbiAzIHdvdWxkIGhhdmUgMiBzdWJzZWN0aW9ucywgY29h cF9wdWJzdWJfYXBwIGFuZCBtcXR0X3B1YnN1Yl9hcHAsIGV0Yy4gPG86cD4NCjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Rm9yIGluc3RhbmNlLCBpZiBhbiBNUVRUIGNsaWVudCBpbXBsZW1lbnRzIHRoaXMs Jm5ic3A7IHRoZSBjbGllbnQgd291bGQgdGFsayB0byBBUzEgdG8gZ2V0IGEgdG9rZW4gYmFzZWQg b24gdGhlIHdheSB3ZSBkZXNjcmliZSBpbiB0aGUgbXF0dC10bHMgcHJvZmlsZSwgYW5kIHRoZW4g Z2V0IGtleWluZyBtYXRlcmlhbCBmb3IgdG9waWNzIGZyb20gQVMyLiZuYnNwOw0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGV4cGVjdCB0aGUgTVFUVCBjbGllbnQgd291 bGQgdXNlIGEgZGlmZmVyZW50IHByb2ZpbGUgbmFtZSBsaWtlIG1xdHRfdGxzX2FwcCB0byBzaWdu YWwgdG8gQVMxIHRoYXQgaXQgaXMgc3VwcG9ydGluZyB0aGUgYXBwbGljYXRpb24gbGF5ZXIgc2Vj dXJpdHkuIFRoaXMgaXMgYmVjYXVzZSB0aGUgZHJhZnQgaGludHMgdGhhdCB0aGVyZSBzaG91bGQg YmUgYSBwb2xpY3kgYWdyZWVtZW50IGJldHdlZW4gQVMxIGFuZA0KIEFTMjog4oCcTm90ZSB0aGF0 IEFTMSBhbmQgQVMyIG1pZ2h0IGVpdGhlciBiZSBjby1yZXNpZGVudCBvciBiZSAyIHNlcGFyYXRl IHBoeXNpY2FsIGVudGl0aWVzLCBpbiB3aGljaCBjYXNlIGFjY2VzcyBjb250cm9sIHBvbGljaWVz IG11c3QgYmUgZXhjaGFuZ2VkIGJldHdlZW4gQVMxIGFuZCBBUzIsIHNvIHRoYXQgdGhleSBhZ3Jl ZSBvbiByaWdodHMgZm8mbmJzcDsgam9pbmluZyBub2RlcyBhYm91dCBzcGVjaWZpYyB0b3BpY3Mu 4oCdDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RlA6IFRoYXQgaXMgYWxsIGNvcnJlY3QuIE1v cmVvdmVyLCB3ZSBjYW4gYWxzbyBkaXNjdXNzIGRldGFpbHMgc3VjaCBhcyB3aGF0IGNvbW11bmlj YXRpb24gcHJvdG9jb2wgdGhlIENsaWVudCB1c2VzIHRvIHRhbGsgdG8gQVMyLiBSaWdodCBub3cg YWNlLWtleS1ncm91cGNvbW0gaXMgb25seSBkZWZpbmVkIGZvciBDb0FQLCBidXQgaWYgTVFUVCBw cmVmZXJzIHRvIHVzZSBIVFRQLCB0aGF0IGlzIHZlcnkgZWFzeQ0KIHRvIGRlZmluZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4oMikgSWYgd2Uga2VlcCBBUzEgYXMgdGhlIG1xdHQtdGxzIHByb2ZpbGUgQVMsIHRoZW4g Zm9yIGNvbnNpc3RlbmN5IHNha2UsIHRoZSBNUVRUIGNsaWVudCB3b3VsZCBleHBlY3QgdG8gdGFs ayB0byBIVFRQUyB0byBBUzIsIGJ1dCB0aGUgY29hcC1wdWJzdWIgZHJhZnQgZGVzY3JpYmVzIHRo ZXNlLCBleHBlY3RlZGx5LCBpbiBDb0FQLiBXaWxsIHRoZXJlIGJlIHN1cHBvcnQgZm9yIEhUVFBT PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GUDogSSBwcm9taXNlIEkgZGlkIG5vdCByZWFkIHRo aXMgcXVlc3Rpb24gYmVmb3JlIGFuc3dlcmluZyB0aGUgdGV4dCBhYm92ZSA6KSBZZXMuIFRoaXMg aXMgcmVhbGx5IGVhc3kgdG8gc3BlY2lmeSwgd2UgYWxyZWFkeSBkbyB0aGlzIHdpdGggQ0JPUi9K U09OLCBpbiBhY2Uta2V5LWdyb3VwY29tbTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEFD RSBmcmFtZXdvcmsgaXMgYmFzZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBvbiBDQk9SIFtSRkM3MDQ5XSwgc28gQ0JPUiBpcyB0aGUgZm9ybWF0IHVz ZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IEhvd2V2ZXIsIHVzaW5nIEpTT04gW1JGQzgyNTldIGluc3RlYWQg b2YgQ0JPUiBpcyBwb3NzaWJsZSwgdXNpbmcgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgY29udmVyc2lvbiBtZXRob2Qgc3BlY2lmaWVkIGluIFNl Y3Rpb25zIDQuMSBhbmQgNC4yIG9mIFtSRkM3MDQ5XS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2Ugd291bGQgYWRkIENvQVAvSFRUUCBpbiB0aGUgc2FtZSB3YXkgKCZxdW90O0NvQVAgaXMgZGVm YXVsdCwgYnV0IEhUVFAgd29ya3MgdGhlIHNhbWUgd2F5JnF1b3Q7KS4gVGhlbiB0aGUgcHVic3Vi LXByb2ZpbGUgY291bGQgc3BlY2lmeSB3aGljaCBwcm90b2NvbCBpcyB1c2VkIGluIHRoZSBkaWZm ZXJlbnQgcHJvZmlsZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigzKSBJbiB0aGUgbXF0dF90 bHMgcHJvZmlsZSwgdGhlIEFTIGdyYW50cyB0b2tlbnMgdGhhdCBpZGVudGlmeSBib3RoIOKAnHB1 Ymxpc2jigJ0gYW5kIOKAnHN1YnNjcmliZeKAnSByaWdodHMgYW5kIHRoZSB0b3BpY3MgYnkgYWRk aW5nIHNjb3BlcyBpbiB0aGUgZm9ybWF0LCBlLmcuIOKAnHB1Ymxpc2hfdG9waWMx4oCdIOKAnHN1 YnNjcmliZV90b3BpYzIvI+KAnS4uJm5ic3A7IFRoaXMgZm9ybWF0IGFsbG93cyByZXByZXNlbnRp bmcgYWxsIHB1Ymxpc2gvc3Vic2NyaWJlDQogcGVybWlzc2lvbnMgY29uY2lzZWx5IGZvciB0aGUg Y2xpZW50IHdoaWNoIG1heSBiZSBhY3RpbmcgYm90aCBhcyBhIHB1Ymxpc2hlciBhbmQgYSBzdWJz Y3JpYmVyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgY29h cC1wdWJzdWIsIHRoaXMgaXMgc2VwYXJhdGVkIGJldHdlZW4gQVMxIGFuZCBBUzIuIOKAnEFTMSBo b3N0cyB0aGUgcG9saWNpZXMgYWJvdXQgdGhlIEJyb2tlcjogd2hhdCBlbmRwb2ludHMgYXJlIGFs bG93ZWQgdG8gUHVibGlzaCBvbiB0aGUgQnJva2VyLuKAnSDigJxUaGUgQVMyIGhvc3RzIHRoZSBw b2xpY2llcyBhYm91dCB0aGUgdG9waWM6IHdoYXQgZW5kcG9pbnRzIGFyZSBhbGxvd2VkIHRvIGFj Y2Vzcw0KIHdoYXQgdG9waWMuIOKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIGNvYXAtcHVic3ViIGFsc28gcGVybWl0cyB0aGF0IEFTMSBjYW4gaG9zdCBwb2xpY2ll cyBhYm91dCB3aGF0IGVuZHBvaW50cyBhcmUgYWxsb3dlZCB0byBTdWJzY3JpYmUgdG8gdGhlIEJy b2tlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgd291bGRu4oCZdCB0aGlzIHNl cGFyYXRpb24gYmV0d2VlbiBBUzEgYW5kIEFTMiBoYXZlIHRoZSBmb2xsb3dpbmcgaXNzdWU6IFB1 Ymxpc2hlciBQLCBoYXZpbmcgdGhlIHBlcm1pc3Npb24gdG8gcHVibGlzaCB0byB0b3BpYzEgYW5k IGhlbmNlLCBzdWNjZXNzZnVsbHkgZ2V0dGluZyBhbiBhY2Nlc3MgdG9rZW4gZnJvbSBBUzEsIHRo ZW4gZ29lcyBhaGVhZCBhbmQgc2VuZHMgYSBQVUJMSVNIIG9uIHRvcGljDQogMiwgd2hpY2ggaXQg ZG9lc27igJl0IGhhdmUgYSByaWdodCB0byBwdWJsaXNoLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldvdWxkbid0IHRoZSBicm9rZXIgd291bGQgcGFzcyB0aGlzIG1lc3Nh Z2UgdG8gc3Vic2NyaWJlcnMsIGFuZCB0aGUgc3Vic2NyaWJlcnMgd291bGQgZGlzY2FyZCB0aGUg bWVzc2FnZSBiZWNhdXNlIHRoZSBwdWJsaXNoZXIgZG9lcyBub3QgYmVsb25nIHRvIHRoZWlyIOKA nHB1Ymxpc2hlcnMgbGlzdOKAnSAoc3Vic2NyaWJlcnMgaGF2ZSBhbGwgdGhlIHB1YmxpYyBrZXlz IG9mIGFsbCBwdWJsaXNoZXJzKS4gSGF2ZSBJDQogbWlzc2VkIHNvbWV0aGluZywgZG9lcyB0aGUg ZHJhZnQgcHJvdGVjdCBhZ2FpbnN0IHRoaXMgYXQgdGhlIGJyb2tlcj8gPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZQOiBObywgdGhlIGJyb2tlciB3b3VsZCBub3QgYWNjZXB0IHRoaXMgbWVzc2Fn ZS4gSW4gZmFjdCwgZHVyaW5nIHRoZSBBQ0UgZXhjaGFuZ2UgYmV0d2VlbiBQdWJsaXNoZXIsIEFT MSwgYW5kIEJyb2tlciwgdGhlIFB1Ymxpc2hlciB3b3VsZCBwb3N0IGEgdG9rZW4gdG8gdGhlIEJy b2tlciB0aGF0IGNvbnRhaW5zIHRoZSByZXNvdXJjZSBpdCBpcyBhbGxvd2VkIHRvIHB1Ymxpc2gg dG8sIG5hbWVseSBpbiB0aGlzDQogY2FzZSB0b3BpYyAxLiBJZiBpdCBkb2VzIGhhdmUgcmlnaHRz IHRvIHB1Ymxpc2ggdG8gdG9waWMgMiBhcyB3ZWxsLCB0aGF0IHdvdWxkIGJlIGluY2x1ZGVkIGlu IHRoZSB0b2tlbi4gVGhhdCBpcyBjb3ZlcmVkIGJ5IHRoZSB0cmFuc3BvcnQgcHJvZmlsZSB1c2Vk LCBhcyB5b3UgbWVudGlvbmVkIChNUVRUTC1UTFMvQ29BUCBPU0NPUkUpLiBPcnRob2dvbmFsbHkg dG8gdGhpcywgd2hlbiBnZXR0aW5nIHRoZSBrZXlzIGZyb20gQVMyIHRvIHByb3RlY3QNCiB0aGUg cHVibGljYXRpb24sIGlmIHRoZSBQdWJsaXNoZXIgaGFzIHRyaWVkIHRvIHB1Ymxpc2ggdG8gdG9w aWMgMiB3aXRob3V0IGhhdmluZyB0aGUgY29ycmVjdCBjb250ZW50IGVuY3J5cHRpb24ga2V5aW5n IG1hdGVyaWFsLCB0aGUgZGVjcnlwdGlvbiBvZiB0aGUgcHVibGljYXRpb24gYXQgdGhlIHN1YnNj cmliZXIgd291bGQgZmFpbCBldmVuIGJlZm9yZSBzaWduYXR1cmUgdmVyaWZpY2F0aW9uLiBCdXQg dGhlIFN1YnNjcmliZXIgd291bGQgbm90DQogZ2V0IHRoZSBwdWJsaWNhdGlvbiBpZiB0aGUgUHVi bGlzaGVyIGlzIG5vdCBhdXRob3JpemVkIHRvIHB1Ymxpc2ggb24gdGhhdCB0b3BpYy4gTm90ZSB0 aGF0IGlmIHRoZSBvd25lciB3YW50cyB0byBwcm90ZWN0IHRvcGljIDEgYW5kIHRvcGljIDIgd2l0 aCB0aGUgc2FtZSBrZXlpbmcgbWF0ZXJpYWwsIHRoYXQgaXMgcG9zc2libGUsIGJ1dCB0aGVuIHRo ZSBjYXNlIGFib3ZlIHdvdWxkIG5vdCBiZSBhbiBhdHRhY2sgYnV0IGFuIGFjY2VwdGFibGUgc2Nl bmFyaW8NCiAoUHVibGlzaGVyIGFsbG93ZWQgdG8gcG9zdCB0byBib3RoIHRvcGljcywgcHVibGlj YXRpb24gcHJvdGVjdGVkIHdpdGggdGhlIHNhbWUga2V5KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RGlmZmVyZW50bHksIHdpdGggdGhlIGN1cnJlbnQgd2F5IG1xdHRfdGxzIHNjb3BlcyBhcmUg ZGVzY3JpYmVkLCBBUzEgd291bGQgbmVlZCB0byBrbm93IG5vdCBvbmx5IHdobyBjYW4gcHVibGlz aCBvciBzdWJzY3JpYmUsIGJ1dCBhbHNvIHRoZSBwb2xpY2llcyBvbiB0b3BpY3MuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RlA6IEJ5IHBvbGljaWVzIG9uIEFTMSBJIG1lYW4gZXhhY3RseSB0 aGF0OiAmcXVvdDt3aGF0IGVuZHBvaW50cyBhcmUgYWxsb3dlZCB0byBwdWJsaXNoIG9uIHdoYXQg dG9waWNzJnF1b3Q7LiBJZiBvbmUgd2FudHMgdG8gY29udHJvbCB3aG8gY2FuIHN1YnNjcmliZSwg dGhhdCB3b3VsZCBhbHNvIGJlIHBhcnQgb2YgdGhlIHNvLWNhbGxlZCBwb2xpY2llcy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KDQpIFRoYXQgYnJpbmdzIG1lIHRvIGFub3RoZXIgcG9pbnQgcmVn YXJkaW5nIHRoaXMgbm90ZSBpbiBjb2FwLXB1YnN1YiBwcm9maWxlLiBUaGUgcHJvZmlsZSBzYXlz OiDigJxIb3cgdGhlIHBvbGljaWVzIGFyZSBleGNoYW5nZWQgW2JldHdlZW4gQVMxIGFuZCBBUzJd IGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uLuKAnSBJIHdvbmRlciB3aGV0 aGVyIHRoZSB0b2tlbiB0aGUgY2xpZW50IGdldHMNCiBmcm9tIEFTMSBzaG91bGQgYWxzbyBiZSB1 c2FibGUgdG93YXJkcyBBUzIsIGFuZCBBUzIgaXMgcmVwbGFjZWQgd2l0aCBhbiBSUyBmb3IgcmV0 cmlldmluZyB0aGUga2V5aW5nIG1hdGVyaWFsIGZvciB0b3BpY3MgKG1vcmUgb24gdGhpcyBsYXRl ciksIGkuZS4sIEFTMiBkb2VzIG5vdCBuZWVkIHRvIGhvc3QvbWFuYWdlL2Nvb3JkaW5hdGUgcG9s aWNpZXMgd2l0aCBBUzEuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RlA6IFRoYXQgaXMgYSBw b3NzaWJpbGl0eS4gUmlnaHQgbm93IHRoaXMgaXMgbm90IHRoZSBjYXNlIGJlY2F1c2UgSSB0aG91 Z2h0IGl0IHdvdWxkIGJlIGJldHRlciB0byBrZWVwIHRoZSB0d28gKCZxdW90O2F1dGhvcml6YXRp b24gdG8gcHVibGlzaCBvbiBvbmUgb3IgbW9yZSB0b3BpY3Mgb24gQnJva2VyJnF1b3Q7IGFuZCAm cXVvdDthdXRob3JpemF0aW9uIHRvIGdldCBlbmNyeXB0aW9uIGtleXMgZm9yIG9uZSBvciBtb3Jl IHRvcGljcyZxdW90OykNCiBpbmRlcGVuZGVudC4gVGhlIHJlYXNvbiBmb3IgdGhhdCB3YXMgdGhh dCB0aGUgc2FtZSBrZXkgY291bGQgYmUgdXNlZCBmb3Igc2V2ZXJhbCB0b3BpY3MsIGkuZS4gUHVi bGlzaGVyIFAgY291bGQgYmUgYWxsb3dlZCB0byBwdWJsaXNoIG9uIHRvcGljIDEgYnV0IG5vdCBv biB0b3BpYyAyLCBldmVuIHRob3VnaCB0b3BpYyAxIGFuZCAyIHVzZSB0aGUgc2FtZSBlbmNyeXB0 aW9uIGtleS4gWWVzLCB0aGF0IGNvdWxkIGJlIGEgd2F5IHRvIGRvIGl0LCBidXQNCiBJIGFtIG5v dCBzdXJlIGFib3V0IHRoZSBhZHZhbnRhZ2UsIGFwYXJ0IGZyb20gdGhlIG9idmlvdXMgcG9saWNp ZXMgc3luY2hyb25pemF0aW9uIChpLmUuIGluIHRoaXMgd2F5IHRoZXJlIHdvdWxkIGJlIG5vIG5l ZWQgZm9yIHN5bmNocm9uaXppbmcgc2luY2UgaW4gcHJhY3RpY2UgQVMxIHdvdWxkIGtub3cgYm90 aCB3aGF0IHRvcGljIFB1Ymxpc2hlciBQIGNhbiBwdWJsaXNoIHRvIGFuZCB3aGF0IGNvbnRlbnQg ZW5jcnlwdGlvbiBrZXkgaXQgY2FuDQogcmV0cmlldmUpLiBCdXQgSSdkIGJlIGhhcHB5IHRvIGRp c2N1c3MgdGhhdCBmdXJ0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oNSkgUmVnYXJkaW5n IGdyb3VwcyBhbmQgZ3JvdXAgbWVtYmVyc2hpcHMsIGl0IHNlZW1zIGxpa2UgZm9yIHRoZSBkcmFm dCBncm91cCA9IGEgc2luZ2xlIHRvcGljLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIE1R VFQsIHRvcGljcyBjYW4gaGF2ZSBsZXZlbCBzZXBhcmF0b3JzIGFuZCBtdWx0aS1sZXZlbCAoIykg YW5kIHNpbmdsZS1sZXZlbCAoJiM0MzspIHdpbGRjYXJkcy4mbmJzcDsgU2ltaWxhcmx5LCBDb0FQ IHdvdWxkIGFsc28gaGF2ZSBoaWVyYXJjaGllcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G UDogVGhhbmsgeW91IGZvciBicmluZ2luZyB0aGlzIHVwLiBZb3UgYXJlIHJpZ2h0LCBoaWVyYXJj aGllcyBhcmUgc29tZXRoaW5nIG5vdCByZWFsbHkgdGhvdWdodCB0aHJvdWdoIHJpZ2h0IG5vdyBp biB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25zaWRlciB0aGUgY2Fz ZSB3aGVuIGEgUFVCTElTSEVSIGlzIGFsbG93ZWQgdG8gcHVibGlzaCB0byBzcG9ydC90ZW5uaXMv cGxheWVyMS8jIGJ1dCBub3Qgc3BvcnQvdGVubmlzL3BsYXllcjIvIy4mbmJzcDsgVGhlIHBsYXll cnMnIGRpcmVjdG9yeSBtYXkgaGF2ZSBzdWItbGV2ZWxzIGxpa2Ug4oCccmFua2luZ3PigJ0uDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBhIHN1YnNjcmliZXIgaGFz IHBlcm1pc3Npb25zIHRvIGdldCBjb250ZW50IGZyb20gc3BvcnQvdGVubmlzLyMuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIGxpa2Ugc3BvcnQvdGVubmlz L3BsYXllcjEgd291bGQgYmUgYSBncm91cCwgYW5kIHNwb3J0L3Rlbm5pcy9wbGF5ZXIyIGJlIGFu b3RoZXIgZ3JvdXAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQsIHRo ZSBzdWJzY3JpYmVyIG5lZWRzIHRvIGJlIGluIHR3byBncm91cHMuIFRoaXMgaXMgZmluZSwgSSBi ZWxpZXZlLCBhY2NvcmRpbmcgdG8gdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RlA6IFllcywgd2hhdCB5b3UgZGVzY3JpYmUgaXMgYSB2YWxpZCBzY2VuYXJpbyBjb3ZlcmVk IGJ5IHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gTVFUVCB0b2tlbiBz Y29wZXMsIHdlIGFsc28gYWNjZXB0ZWQgdGhhdCBhIHB1Ymxpc2hlciByZXByZXNlbnRzIGl0cyBQ VUJMSVNIIHJpZ2h0cyB3aXRoIHRvcGljIGZpbHRlcnMgKG5vdGUgYSBQVUJMSVNIIG1lc3NhZ2Ug Y2Fubm90IGJlIHNlbnQgdG8gYSBmaWx0ZXIsIGJ1dCB0aGUgdG9waWMgZmlsdGVycyBhcmUgdXNl ZnVsIGluIHN1bW1hcmlzaW5nIHBlcm1pc3Npb25zKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TGV04oCZcyBhc3N1bWUgdGhlcmUgaXMgYSBwdWJsaXNoZXIgd2l0aCBz Y29wZSDigJxwdWJsaXNoX3Nwb3J0L3Rlbm5pcy8mIzQzOy9yYW5raW5nc+KAnD88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RlA6IFRoZSBmaXJzdCBxdWVzdGlvbiBJIGhhdmUgaXMgaWYgaXQgaXMg ZXZlbiBwb3NzaWJsZSB0byBpbmRpY2F0ZSBzY29wZSBsaWtlIHRoaXMgaW4gQUNFLiBJIGRvIG5v dCB0aGluayBzbyAoYW5kIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcpLCBhbmQgaW4g dGhpcyBjYXNlIHRoZSBzY29wZSB3b3VsZCBoYXZlIHRvIGJlIGV4cHJlc3NlZCBhcyB0aGUgdW5p b24gb2YgdGhlIGZvbGxvd2luZyBVUklzOg0KIHB1Ymxpc2hfc3BvcnQvdGVubmlzL3BsYXllcjEv cmFua2luZ3MgYW5kIHB1Ymxpc2hfc3BvcnQvdGVubmlzL3BsYXllcjIvcmFua2luZ3M8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlbiBiZWluZyBhIHBhcnQgb2YgYWxsIGdyb3VwcyAocGxheWVy IDEgYW5kIHBsYXllcjIpIGlzIHRvbyBnZW5lcmFsIGFzIHRoaXMgcHVibGlzaGVyIGNhbm5vdCBw dWJsaXNoIHRvIGV2ZXJ5dGhpbmcgYnV0IG9ubHkgdG8g4oCccmFua2luZ3PigJ0uDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RlA6IEJ1dCBvbmNlIHRoZSBzY29wZSBpcyBleHByZXNzZWQgZm9y ICZxdW90O3JhbmtpbmdzJnF1b3Q7IG9ubHksIHRoZW4gdGhlIGRvYyBzaG91bGQgY292ZXIgdGhp cyBjYXNlIHRvby4gVGhlbiBpdCBpcyB1cCB0byB0aGUgdG9waWMgb3duZXIgKGFuZCByZWZsZWN0 ZWQgb24gdGhlIEFTMikgdG8gZGVjaWRlIGlmIHRoZSBrZXlpbmcgbWF0ZXJpYWwgaXMgdGhlIHNh bWUgZm9yIHJhbmtpbmdzIGFuZCBmb3IgdGhlIHVwcGVyLXRvcGljcw0KICg/IGFzIG9wcG9zZWQg dG8gc3ViLXRvcGljKSBwbGF5ZXIxIGFuZCBwbGF5ZXIyLiBBbmQgc2ltaWxhcmx5LCBpdCB3aWxs IGJlIHVwIHRvIHRoZSBicm9rZXIgdG8gdmVyaWZ5IHRoYXQgdGhlIGF1dGhvcml6YXRpb24gZm9y IHB1Ymxpc2hpbmcgdG8gcmFua2luZ3MgaXMgc2VwYXJhdGUgZnJvbSBwdWJsaXNoaW5nIHRvIHBs YXllcjEgYW5kIHBsYXllcjIuIEl0IGlzIGFsc28gYSB2YWxpZCBjYXNlIHRvIG1ha2UgaXQgc28g c3ViLXRvcGljcyBpbmhlcml0DQogYXV0aG9yaXphdGlvbnMsIGJ1dCB0aGF0IHdvdWxkIGJlIHVw IHRvIHRoZSBhcHBsaWNhdGlvbiB0byBkZWNpZGUuIEFueXdheSwgdGhlc2UgYXJlIGFsbCB2YWxp ZCBjb25zaWRlcmF0aW9ucyB0aGF0IG5lZWQgdG8gYmUgbWFkZSBpbiB0aGUgZG9jdW1lbnQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgYXBwcm9hY2ggY291bGQgYmUgZWFjaCBwdWJs aXNoZXIgY3JlYXRpbmcgaXRzIGdyb3VwLiBUaGlzIHdheSB0aGUgbnVtYmVyIG9mIGdyb3VwcyBz Y2FsZXMgd2l0aCB0aGUgbnVtYmVyIG9mIHB1Ymxpc2hlcnMgKGFuZCB0aGUgQ09TRSBrZXlzIGlz IHBlciBwdWJsaXNoZXIpLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZQOiBJIGRvbid0IHRo aW5rIHRoaXMgc2NhbGVzIHdlbGwsIGJ1dCB5ZXMsIGFuIGFwcGxpY2F0aW9uIGNvdWxkIGFsc28g ZG8gdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIHRoZSBzdWJzY3JpYmVyIHN0aWxs IGFza3MgcGVybWlzc2lvbnMgZm9yIGFuZCBzdWJzY3JpYmVzIHRvIHRvcGljIGZpbHRlcnMuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIG5lZWRzIHRvIGJlIGEg c29sdXRpb24gdGhhdCBtYXBzIHRoZSB0b3BpY3MgdG8gYSBwdWJsaXNoZXIgbGlzdC4uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QVMxJm5ic3A7IChzZWUgbXkgZWFybGll ciBkaXNjdXNzaW9uIG9uIHdobyBrZWVwcyB0aGUgcG9saWN5IGluZm9ybWF0aW9uKSBrbm93cyB3 aG8gaGFzIHRoZSByaWdodCB0byBwdWJsaXNoIHRvIHRoZXNlIHRvcGljcyBpbiB0aGVpciBwb2xp Y3kgZGF0YWJhc2UgYW5kIGhhcyB0aGUgcHVibGljIGtleSBpbmZvcm1hdGlvbiBmb3IgdGhlbS4g QVMyIGhvc3RzIHRoZSBDT1NFIGtleSBmb3IgdGhpcyBwdWJsaXNoZXIuDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UHV0dGluZyBhbGwgdGhpcyBpbmZvcm1hdGlvbiB0b2dldGhlciwmbmJzcDsg d2hlbiBhIG1lc3NhZ2UgaXMgcmVjZWl2ZWQsIHRoZSBzdWJzY3JpYmVyIHdvdWxkIHVzZSB0aGUg cHVibGlzaGVyJ3MgcHVibGljIGtleSB0byB2ZXJpZnkgdGhlIHB1Ymxpc2hlciBzaWduYXR1cmUg KHRoZSBkcmFmdCBhbHJlYWR5IHN1cHBvcnRzIHRoaXMpLCB0aGVuIGxvY2F0ZSB0aGUgc3ltbWV0 cmljIGtleSBpdCByZWNlaXZlZCBmcm9tDQogdGhlIEFTMiBmb3IgdGhpcyBwdWJsaXNoZXIgdG8g ZGVjcnlwdCB0aGUgbWVzc2FnZS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIHRoZXJl IGJlIGFueSBwcm9ibGVtcyB3aXRoIHRoaXMgYXBwcm9hY2g/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZQOiBObyBJIGRvbid0IHNlZSBwcm9ibGVtcyB3aXRoIHRoaXMsIGFsdGhvdWdoIEkgYW0g bm90IHN1cmUgd2UgbmVlZCB0byBkZXNjcmliZSB0aGlzIGluIHRoaXMgZG9jdW1lbnQuIElmIEkg dW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZSBzY2VuYXJpb3Mgc2hvdWxkIGJlIGNvdmVyZWQgYnkg dGhlIGN1cnJlbnQgc3BlYy4gT3IgZGlkIEkgbWlzcyBzb21ldGhpbmc/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk5pdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaWd1 cmUgMjogTmVnb2NpYXRpb24gLSZndDsgTmVnb3RpYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RlA6IE9rLCB3aWxsIGZpeC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCByZWdhcmRz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1DaWdkZW08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_75220EAA945546919E993E16401D1309ericssoncom_-- From nobody Sat Dec 14 03:58:41 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDC412007C; Sat, 14 Dec 2019 03:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 7pbg6ysrBLxU; Sat, 14 Dec 2019 03:58:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 16A7812006B; Sat, 14 Dec 2019 03:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576324709; bh=4heapEDiKbnSADfYNhNKEJBr53zZBckMHqqWNiCnCBo=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=aVOPiRQxLDaUTUCDsLUxTO/wbF0sloY5H9vzFUH4eQn4gWayLnd+/ixUA4MV3jf2m ee78+duYSjBnGtYyYRXVzcisNzTA/oLhE8MzT2KqdaSrW35voaJ6W0m3dZrS2uzBTS 5zZGGPl/q1+pGb3fwXO6FK4K/SFYhr+nGqNXIRYQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MjS5A-1i0jhH24Zm-00kxyN; Sat, 14 Dec 2019 12:58:29 +0100 To: kent@alum.mit.edu, secdir@ietf.org References: <157582913296.4934.15140560361782598959@ietfa.amsl.com> Cc: ace@ietf.org, last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org From: Ludwig Seitz Message-ID: Date: Sat, 14 Dec 2019 12:58:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <157582913296.4934.15140560361782598959@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+mkxzRcWwP0fa7gDAha7g44bWMAK4REqDro7md6batoFV41eG+l zllYqfO0SV0qAx4gCCZB5IHEqWUxJT9i3DR0YaifrPpGm+uLvOFXw8mw067ESI6OUPmoGFH tVIhE52yM0mnSOYBAN080y1oDTttRjJsy2xHBk5oWdvdAqzCBnY4WBVU868qTIznT3SLIxH tG/doB6osIe1rpi/tIdpg== X-UI-Out-Filterresults: notjunk:1;V03:K0:tWM5mC1rLfo=:wEtnKc0lXjs34KvXsgMqv5 +T503+YAPW8QpI3CQPPx2gH9lvccvSbsIICyuGZptgegwh2U5a3kOleAo/ofccT3o9/u8q2WE HvH+g/bmn2aOz8pKdKQdo/f9Ot3YLsvFicT7JU4lncAbuPagkQAzRIHj9LC4d8gugMBoewniA IcouvYnVIExbUN+8NlHO4f5TV4Gn0e1exks5Lu2MTtczrTtxdOy92rEih04nDoRw5AWkj5MTU YT8YLZ9wISRJZpGRDcYf0f+F1wBn3Vd8Xaqa1gbEp0mgF/cvIVEhkr4FwaY/jz/CtbDJ+HLyW Hw9PQdg+iogVMvrNIqPfBSxNdqPRnJ835ACssK+BhDE8wLOD++35xi8HKNq6w4kQIGlrBBQqj SfsjcyCxWkCg+VKIJpJeGPQmAsLVPB2Q+OL/LWt1Y2yI61+TG63UCW/DK28V5LaiUkRORZ2Yt s5vTR4OqbHVY4jDpfDwzpaSPxfv5oLIHZni93YvK2k7R5qzBodBBzxvU7PZkAgRS6OsKav2zf l1hU3XJlpilSQe8UppaDmOMbyvL4Z+Mg0tT5PVE2JuKiGCopFF/wD52CfB/KVul/SBeR4Zldi PxDQ23mjnXXgfPPfnsaLGTWc/x11x1SRiMugfZaS3c/fqWh1Fke2x98x0oyEtF2KxC6ehH9Or MGwR+uA6kxiqTZ08F5T2rusDG+75oAHYw+p4v1MKQtIVXhGd8qaoqLv+107MLrxj57iwb3pRV b9Jb+hZZ66KtCG4NDw8AZ+fiRmByGtdlPtKTuqjGUSoWzSjzONc0MX0L3bFNelELO4vApBHvm p5jBOT5GLK93/MeynT7J5rgFGZvN1shm/YJOB8Q+ieM9oYlbUF3LM5II+cr8pSA4xCIXRuTKA n2V96beza4nAR/D4rU1NUNRhMDG2ohxhBLqQx2aNIYuls88jzdxaNy6VWBpl7O20PD23ew0zu IzJE73oc7ame0j1ne0qaKuMpRfRsPuzySVUds5JzR1Pzjc246z7dBzPnzHe7ZOW7oH4A/mWdh ZG7yh4hXperPU18m3akMgQT8PiRdGYG38KzqFsQEDJsyQy1mLnJ3vASvnMatd9BWJtiu0fcJP YzxfUf/Pn9R2GNCmf1yGtkNh4MUgrsUOnH7kNSuBdxJRv21kfFJhG/mTTOFBpP1dv2+zHKJNG 8EC6+Q6GrtnTe5+fVni0b39d3VMXtdl53+OdeZJDfOKEo2/6Np1JgixniiUlGBijqKArmDMa8 YB21M3orDoSIB+y8X3Zp2ILN2pk76vE9k103ra0XBf1QVYiTEUgTNlmgybRE= Archived-At: Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: ace@ietf.org 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: Sat, 14 Dec 2019 11:58:40 -0000 On 2019-12-08 19:18, Stephen Kent via Datatracker wrote: > Reviewer: Stephen Kent > Review result: Has Issues > > SECDIR review of draft-ietf-ace-oauth-authz-27 > > The summary of the review is almost ready, but needs some revisions. > > I have reviewed this document as part of the security directorate's ongo= ing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements= and > considerations in IETF drafts. Comments not addressed in last call may = be > included in AD reviews during the IESG review. Document editors and WG = chairs > should treat these comments just like any other last call comments. > Thank you for your helpful review Stephen. I have some follow-up questions inline. I will submit a draft update as soon as possible, note that this may be delayed by my affiliation change. Regards, Ludwig > This is a long document- 86 pages! It is a proposal for how to use OAuth= 2.0 > and CoAP to provide authorization security for Internet of Things (IoT) > devices. IoT devices are often criticized as not being very secure, so t= his > seems like a useful initiative. RFC 7228 (Technology for Constrained-Nod= e > Networks, and Informational document) is cited as inspiration and refere= nce for > this work. CoAP (RFC 7252) is expressly designed for the sort of environ= ment > that characterizes many IoT devices, hence is seems a natural choice for= this > authorization-focused framework. OAuth is not as obvious a candidate bui= lding > block in this context, e.g., it is expressly designed for the HTTP conte= xt, yet > CoAP is cited as the replacement for HTTP. This document adapts OAuth fo= r the > CoAp context. As Ben stated the ACE WG has had extensive discussions on which solution to choose, and the OAuth model has the advantage of being able to temporally decouple the authorization decision from the actual resource access, which enables several use cases involving devices with intermittent connectivity (note that several other proposals had the same design property). Furthermore the possible re-use of OAuth specifications was seen as favorable when the final decision was made to go forward with this solution. > This document has an extensive, 6-page Security Considerations section, > appropriate for a document specifying an authorization framework. It beg= ins by > citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819= ), and > OAuth 2.0 Token Introspection (RFC 7662). All three of these documents = are > relevant, and they contain substantial Security Consideration sections. > > Section 6.1 deals with security for the tokens that are transmitted to c= onvey > authorization information. In general the requirements and advice provid= ed here > are good; I would prefer to see the admonition against use of a shared s= ecret > key for a group of serves to be a MUST NOT, as opposed to just NOT RECOM= MENDED. Ok, will fix. > I am not convinced that the suggestion for short lifetime tokens is nece= ssary; > we have seen how short duration certificate lifetimes and frequent CRL i= ssuance > in PKI contexts often is neither required nor advisable. In constrained environments with intermittent connectivity, short token lifetime is seen as an advantage, as it might be hard to convey revocation decisions or other changes of access rights to offline devices. The short token lifetime limits the window of exposure, if a token and the corresponding proof-of-possession credentials get stolen. I would therefore prefer to keep that paragraph as it is. > This section ends by > noting that only client-initiated revocation of tokens is addressed by R= FC > 7009. The authors note that revocation of long lifetime token remains an= open > issue. If this is likely to be a common case for IoT devices, leaving th= is as a > TBD is not great. The situation is the same as for OAuth 2.0. The short token lifetime is often given as an explanation why a revocation mechanism is not really needed. We have however submitted a proposal for a revocation mechanism in https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notificati= on > > Section 6.2 addresses communication security issues. The section opens b= y > requiring an authorization server to offer confidentiality for client > interactions, but the wording implies that a client need not make use of= such > protection. The reader is reminded that security requirements expressed = in > Section 5 of this document (a 25-page long section) MUST be addressed by= a > profile. I=E2=80=99d prefer to see references to specific parts of Secti= on 5 that > expressly addresses confidentiality, so that a reader can better underst= and > when it is safe to reject the offer of confidentiality by a server. The implication you read from the text was not intended, section 5 clearly specifies that confidentiality is mandatory. This is addressed in the body part of that section (4th paragraph). I'm a bit at a loss on how to make that more apparent, so that the reader does not go an a fruitless hunt in the subsections of section 5. Any suggestions are most welcome. In the meantime I will adjust the wording to clarify that confidentiality is mandatory. Note that Appendix C collects all requirements on profiles and lists the specific subsection where they appears. > Encryption > of CWTs is used as an example, which is appropriate because CBOR CWT is = the > default token format. The final paragraph of this section says that =E2= =80=9Cdevelopers > MUST ensure that =E2=80=A6 ephemeral credentials =E2=80=A6 are not leake= d to third parties.=E2=80=9D > This is good advice, but since adversaries are assumed to have physical = access > to IoT devices, the scope of this mandate is not clear. For example, is = this > text arguing for use of tamper-resistant hardware for storing private or > session keys in IoT devices? I guess it is up to the security level required by the specific application. I physical key extraction attack is not trivial, so the value of the protected asset has to be gauged against the additional cost for tamper-resistant hardware. A more simple, but less secure mitigation could e.g. be to glue over interfaces that an attacker could use for key extraction (e.g. debug ports) if they are not needed for normal operations. Would you like to have such considerations added to this section? > > Section 6.3 focuses on long-term credentials. The sections begins by not= ing the > challenges associated with providing protection for such credentials in = devices > in publicly-accessible locations, explicitly referring to specialized ha= rdware. > This a good, clear statement, not like the ambiguous MUST at the end of = 6.2. > The text requires that compromise of a credential at one device MUST NOT= lead > to compromise of other credentials not linked to the device in question. > However, the next sentence says that sharing of secret (and, presumably, > private) keys is NOT RECOMMENDED. This is a somewhat inconsistent pair o= f > statements; if secret keys are shared, then the MUST NOT will be violate= d, > right? Why not just say that secret keys MUST NIOT be shared across devi= ces? Agreed, will fix. > The section states that operators should have procedures to replace cred= entials > that have been (or are suspected to have been) compromised. Why is this > admonition not a SHOULD? The mildly-worded (=E2=80=9C=E2=80=A6 also need= to =E2=80=A6) advice about > decommissioning devices seems minimally helpful. If this is important th= an make > it a SHOULD, if it=E2=80=99s not, then RECOMMEND it. Ageed, I will make both a SHOULD. > > Section 6.5 summarizes the =E2=80=9Cminimal=E2=80=9D communication secur= ity requirements for > the elements of the system described in this document (clients, AS=E2=80= =99s and RS=E2=80=99s). > I think it=E2=80=99s useful to collect these requirements in one place, = although they > have been described in various parts of Section 5. Unfortunately, the fi= rst > sub-section seems to contradict Section 6.2! Specifically the text here = says > that all communication between a client and an AS MUST be encrypted, whe= re as > 6.2 requires only that an AS offer confidentiality. This inconsistency n= eeds to > be reconciled. The rewriting of 6.2 should fix this inconsistency. > The next subsection seems to be consistent. The final subsection > (C-RS) notes the challenges of initial C/RS communication, and offers so= me > suggested approaches. Some of the wording here is awkward. For example, = the > text notes that DTLS with server-side authentication =E2=80=9Ccan be pos= sible and are > RECOMMENDED if supported by both parties.=E2=80=9D It would be better t= o state that > =E2=80=9CDTLS with server-side authentication is a RECOMMENDED mechanism= for use in > this context, and SHOULD be employed if supported by both the C and the = RS.=E2=80=9D > I'll try to rephrase to make it more readable. > Section 6.6 deals with token lifetimes. The section begins by suggesting= use of > nonces (as described in 5.1.2) to counter replay attacks in the event of= =E2=80=9Cclock > drift=E2=80=9D between an RS and an AS. I appreciate the analysis of mec= hanisms that > can be used to address the clock drift issue, including the discussion o= f > potential problems associated with using nonces in the face of a reboot. > However, the text provides no indication of how much =E2=80=9Cdrift=E2= =80=9D is tolerable, vs. > when use of nonces is needed, and 5.1.2 does not even mention clock drif= t. > Perhaps the text can be revised to provide additional advice re clock dr= ift. > I will add a paragraph about that noting that the critical factors are the lifetime time of a token (lifetime >> clock drift), and the criticality of timely expiration. > Section 6.7 very briefly discussed the issue of combining profiles. The = bottom > line is that the security of a profile MUST NOT depend on the assumption= that > the profile is used exclusively throughout a given deployment. That=E2= =80=99s a nice, > straightforward warning! > > Section 6.8 discusses circumstances in which data is transmitted and may= not > encrypted, e.g., error messages. The discussion here is fairly clear, an= d > includes a RECOMMENTATION and a MUST, as well as an analysis of potentia= l risks > associated with transmitting different types of information w/o confiden= tiality > protection. The section title says =E2=80=9Cunprotected=E2=80=9D but thi= s discussion focuses > only on confidentiality, so a more descriptive title might help. I added a sentence instead that also points out the option that active attackers may manipulate unprotected information to induce incorrect behavior. /Ludwig From nobody Sat Dec 14 08:04:10 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1361200E9; Sat, 14 Dec 2019 08:04:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157633944911.14852.6826923798761489229@ietfa.amsl.com> Date: Sat, 14 Dec 2019 08:04:09 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-28.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2019 16:04:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-28.txt Pages : 87 Date : 2019-12-14 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-28 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 14 08:22:48 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30461200E9 for ; Sat, 14 Dec 2019 08:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 xos6RDNFTHfL for ; Sat, 14 Dec 2019 08:22:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 6A39C120091 for ; Sat, 14 Dec 2019 08:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576340560; bh=zmLVtkhk4FsBR0aTE+ij5PexglVKMYgRLRr0fXYbMaI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=D3rJaysudRFX7gNPCXZoGd/jOr5MAZf9s90vqV6db0ljjO4mhgtMLbyFgMjIjUW7m E0JX/GGB5KYU1kENRQfUviI+Oo4XWh+5rUixgQ/A1uP/qYnC1bHB1Sa9wJmua0phbD 4RrqJTRaxU8YnE/Pb7gzzXUIEFk7es9t3SgblSwo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MkHMZ-1i0FwH0xVx-00kjuL for ; Sat, 14 Dec 2019 17:22:40 +0100 To: ace@ietf.org References: <157633944911.14852.6826923798761489229@ietfa.amsl.com> From: Ludwig Seitz Message-ID: Date: Sat, 14 Dec 2019 17:22:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157633944911.14852.6826923798761489229@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:YEhTjyVr3tCPynoVIRj7rPFgrorfjg5enjXgb2zYlMsML9fXL22 q/pMDlr1MrKHPuAYrSs61VkVrELuy3mfC9OnFnLKWQtkiI1SP6OLwymwvzv0UZkr/m7Ikx6 0H+59Ns1N3P4/xKZKsqHMHACkja6EbFLMD1a0hmRx+3L3wXJ/SiV8aPYVIsMWFgyMIYCKro HWjWIPA3UdysVJMi5zjIg== X-UI-Out-Filterresults: notjunk:1;V03:K0:xVSHJH5cH5U=:LfeWS8mu7+xxr3lfwH7QMO fM88Y8VkTTLrdrjqC99VdXpeQgfKui8gIhW2dWLDj1h/09B//jAvbEdKWgQk8/kNIbO50qEht ktZCg2S/5eTH3jqaX/VUsMaRWOryTr1LkwESJS4KqXAGVqPvfdZ6I5HKLwG7YXq/45hEbAZ43 IFe98VLsT+vaQiH3k0rcsRlJe5uPcDnRWm10F62ZDTKWFxka8AGP0Gd3vlEhdt4jBtt3VSYJf L0SZc9eYEpWgfOsWjSXJ1sH5MvgXiQff7vWf9dJlGKCN9YA30eRWaT5ClXh3P9DTantf6tXfX U/S9FxCVGh/cm5IuaTvjG2LXbM6676fmfZdM9O1SIygoWWm73BYA9bgDCcoU/0ZFyl36xfBMp EVH29503xQ8Oo9fiWFH7TcDyUecyaX9G+iy886VU3DHK2b9ocBRgcqJtheBbgx9iQmSMhEp6d XAMhE5AnOLyyGoj7pLT85e/Egw0o+KHIdabh9fQFTNpBU0C7U+vhSfNgSIVBHu3F4G1v3yARH s0351Dfzy4olhzOG0ppySkL7R7df9yyMHinPyqpQfR0c9Mfz7y7IyJWWPAQfam+saB8oIwC6H KmHFxXKFnnyz3jmfMDk4jHRr9/dUct8tI6mGtBxkamYvYXWVONxqnNgD2Dxd7Ut3x/LxkwIXt fWSTBv6xf6E9Opc7V3yyhVmHgz6/qtDaZkEfnCzc7anzUSHnNaOkejN2J3UVqe/wKBAHCIp+0 QhDw3SDMBALeffJCBmKDEv2a2MB6ttG7PtUvB4R7NfB6p4vqo1nerwLMkwhad4lfB0BShtNas /fpKt1D/jLMmjIqyCNzRVDqN2UHAaQY5oVXNbJdSU7CW3BBNUjZSs2jhBVbt0oF+1pN6LJAaH xa5/2Rrw8V2uc29FnJ+NjXxY75GtB7URNeFEOu+Fx4+K8WQ0N6outqqlo3BTeTAx2nivCa5Jf +z+3SltVrhT5/zJdtm5CuIzvHzzzyvP9KGYuHwDIcipf9ghk5x3wYD7hqpnPjqIWeluzs1ut4 kwRjk4HJIGi+BbQdvk6GLFqEmxC3K/4NxiJ6jTZJUW3qgSaemAX3mxmA20ubqcPRfjn88NmPn g+tqSAPKNAh5dOk/X8UOBS+6AfSANCPhmQw5zNStTZngd4lLLHDilymFy/XOru3ShR1hdhfP9 fjGeygJSeoaMRxB9w+seEdGjjWWjc5HGqDwbAlPw8A5AdlYcTK93r+e+HH1XN03SVeoWBCaz1 +deG9IWMbmFy9fU3lG9foBtzF5BK1d1Ko0xszQodCJgpKXLPVpF2Fj5PfxUA= Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-28.txt X-BeenThere: ace@ietf.org 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: Sat, 14 Dec 2019 16:22:47 -0000 Hello ACE, this update addresses the Secdir review kindly provided by Stephen Kent. /Ludwig PS: Please note my changed affiliation and email address in case you want to email me off-list. On 2019-12-14 17:04, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the Authentication and Authorization for Co= nstrained Environments WG of the IETF. > > Title : Authentication and Authorization for Constrai= ned Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) > Authors : Ludwig Seitz > Goeran Selander > Erik Wahlstroem > Samuel Erdtman > Hannes Tschofenig > Filename : draft-ietf-ace-oauth-authz-28.txt > Pages : 87 > Date : 2019-12-14 > From nobody Sat Dec 14 08:25:52 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE7D1200E9; Sat, 14 Dec 2019 08:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 xza0baSKIxrO; Sat, 14 Dec 2019 08:25:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 5D645120091; Sat, 14 Dec 2019 08:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576340745; bh=4VtxGCLkqsvHzChJZ1akYeLTO3poaKsYkjduSrF35Ug=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=lw95QOAuAzldWZL/8+9f9NtRYnU19FYM8/Ni+uwHJfJTj6QYNIUhS5Yh9JFbBgNqg VXCNzCaOIu+CBDOpwZsdfME+iiFvEiQsDcR/QBUM1kGkzsiDhM2pbpjwr0l2g7tVx3 E1IUWb3fvJ/m0ryaYXUUWJPNatKS5JubgOlBflqw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N1OXZ-1hjGmh21Od-012owa; Sat, 14 Dec 2019 17:20:40 +0100 To: ace@ietf.org, stewart.bryant@gmail.com References: <157618348089.20903.16122189372846633578@ietfa.amsl.com> Cc: last-call@ietf.org From: Ludwig Seitz Message-ID: Date: Sat, 14 Dec 2019 17:20:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157618348089.20903.16122189372846633578@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:6PLU9Eu23UxM2YjaQfHSSC2pZjieUdGuN77uyTW84l9hec3Juyl VoSzTEAxAPlUX6LVsuc9B249/mJhtRb34lRuHEXaOC+UYFGQye2LXX65Zry8zQ/3AC1wutt D7oV1FPB6wCGKR5ErKCBlbUfVwkCfIXvfXtuG9Z6qYbG3Q/aGcMQzmPyAoiywkNCNf5HLn0 Lsbua4qb+q54lWnunQK6Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:2HFK1fA3KLg=:WOrdiPqSWQPQS9AugGWVQg QoJv1GVKaMgxdWiBpJmQFCsmMuIOEMTgJDOz0WMhvxLWZX4I8Zs9HUCqBvWm05NdaGksdP9kh bj6+/ls2g4dai2+wWrTET5v2wuZjCHOgmNF5G/BIyxx+ca2P6HmB/ft8/EIsZleSAuuIVkPM2 HQ7UwDDqoFEg5S/jTHEMN4jLCM3N0852eGUzpiN62Dev47QRXvG98Po4iSWvnzXCIMSe2wgi8 lBeIppL3tIKzVni0PJ4zK7jomCaUPW4ccy+JUJfqiNYvMdJDNpBtjykleliZ10kQuFThmdVuu Yz3HoLR0A+3tvHkRM0KEB5VWvjToVYkn7IcXOY+EnzEr1fJbHE5CakgSUAW78Idnhtigtug58 jEZGBkaAvCRIfi4O7WnpDn+mnsSZ//iomHdgAdHrrjGQh6tED6jOQtty7frpfIFFD9OScvvl8 yiangmiAcssqxpSGQrAl7DeqJC31NIhAmd3saxPHv6D6taMMgRFazoEta6iqiLXRh6uwdZXQE Ipx7v+gUWK6Edekoi5I+hw2cuHlXcg43esaTQmOCD5MzMQTKoe7ek/tlRYhCzuBSPU6X3+Lhv tT8Md7Q+gxebDYsv3hEWpa+viRBGgCmt/6/JzC6q6oAzNgzKjRGqv7XnjG06Z2/7X17F/eB44 3ah2/+uZNp/72mpPgQOyNSecTZ6Hs9+vrXCxOcqLSTpoHt8gzdAoJfwuS8gz1m6dhtf7lBcP2 bVo8CdjLR1Rqtt+5JEtaee/rO0ixrWTYrUyc36G53lds/K/P2rrp9bREc1aq/hkYcxee9/SD6 8mj3U3UrmAvG8a0ByaEAV6mw19VJdOXXKc22hzrnjS+G6cMz9uLgUMB80Cx+wIOj1sgQy6MQj 4YkHACS8XDSesozxRdtULR8H52sGOCQsIH8K7ndbQtsRuHkWs1uqoA/ZB8gh8T6V2VCKfWfIm VlkrwBsJQqxziOB8i3WD/r9GwYNrofL8aTqT4d1GKoPuqSWicNSEg+stpntBo7mLhdmQe3YJu t4g1mdOl/2RoBZPOPcvLmyioFpyNsIcfsq2yimUHZMpe1JdAC8EU05atPjJ0NAQVxR0dhs08K GUW5LjiecrYyw7q5JbybAh+bILpViWSwVPrlg+8KJYErjs3PU9ep9oSrg/xVeHb76IunIkPt+ nLa5EBhgnGyfH0Lq7fTGJoXEj6dH81qkpXbxfHW5W43mxR65CJwHKNESSduxzglZP3078/Je/ yE4bL+o61DhH29rof0EDn0GCoOOfwEY/WYkMAykRF7PzJSZ8FgsXofLjZlWA= Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: ace@ietf.org 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: Sat, 14 Dec 2019 16:25:50 -0000 On 2019-12-12 21:44, Stewart Bryant via Datatracker wrote: > Reviewer: Stewart Bryant > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > Thank you Stewart for this review, comments inline. Note that the posting of an update draft might be a bit delayed due to issues with my affiliation change. You can inspect my edits here meanwhile: https://github.com/ace-wg/ace-oauth /Ludwig > > Nits/editorial comments: > > Abstract > > This specification defines a framework for authentication and > authorization in Internet of Things (IoT) environments called ACE- > OAuth. The framework is based on a set of building blocks including > OAuth 2.0 > SB> OAuth 2.0 needs a RFC or other reference > =3D=3D=3D=3D=3D > and CoAP, Both fixed > > SB> CoAP is not in the list of well-known abreviations and needs expandi= ng Fixed > =3D=3D=3D=3D > thus transforming a well-known and widely used > authorization solution into a form suitable for IoT devices. > Existing specifications are used where possible, but extensions are > added and profiles are defined to better serve the IoT use cases. > > While prior work on authorization solutions for the Web and for the > mobile environment also applies to the Internet of Things (IoT) > environment, many IoT devices are constrained, for example, in terms > of processing capabilities, available memory, etc. For web > applications on constrained nodes, this specification RECOMMENDS the > use of CoAP [RFC7252] as replacement for HTTP. > > SB> Please expand CoAP Fixed > =3D=3D=3D > A detailed treatment of constraints can be found in [RFC7228], and > > SB> I think you should provide a short context on "constraints" I added a reference to Appendix A which does just that. > > the different IoT deployments present a continuous range of device > and network capabilities. Taking energy consumption as an example: > At one end there are energy-harvesting or battery powered devices > which have a tight power budget, on the other end there are mains- > powered devices, and all levels in between. > =3D=3D=3D > > More detailed, interoperable specifications can be found in profiles= . > SB> What do you mean by "profiles" as a word on its own? I added some clarification > =3D=3D=3D=3D > > A third building block is CBOR [RFC7049], > SB> CBOR needs to be expanded on first use. Fixed > =3D=3D=3D=3D > > HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also > viable candidates. > > SB> These really need references > SB> Except for HTTP the abreviations need expanding on first use. Done, note that there does not seem to be an expansion for QUIC. > =3D=3D=3D=3D=3D > > In this example, the attribute AS points the receiver of this messag= e > to the URI "coaps://as.example.com/token" to request access > permissions. The originator of the AS Request Creation Hints payloa= d > (i.e., RS) uses a local clock that is loosely synchronized with a > time scale common between RS and AS (e.g., wall clock time). > Therefore, it has included a parameter "nonce" (see Section 5.1.2.1)= . > > SB> I think the above text could usefully be re-worded for clarity. > SB> The "therefore" does not seem to follow the preceeding text. I rephrased this to hopefully improve readability and clarify the "therefore" (and s/nonce/cnonce). > =3D=3D=3D=3D > o A RS sending a "cnonce" parameter in an an AS Request Creation > SB> An RS... This doesn't feel right, since there is no consonant in RS and the R in "Resource Server" (the expansion of RS) is not silent either. Is there a grammar rule that I'm unaware of? You did however make me aware of a typo later in that sentence where there it says: "an an". From nobody Sat Dec 14 08:29:43 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DEF1200EB; Sat, 14 Dec 2019 08:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 sUr-S5HPiAjA; Sat, 14 Dec 2019 08:29:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 2AD94120091; Sat, 14 Dec 2019 08:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576340978; bh=OyionxHi8/Jpmj7/2CuAtuAMXn3zqwVdJ/gGh21eWrY=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=PtkP+vs+2qXoyQ6KOSoE+Qvd6c7aE5kfiH9BU15rMAn0JyuSQjASOatUZSzK4QukU Ry/6wElZ1TuM+8wJSi117W5mDNnzWm1T4wRaja3490S46EnfPJcVkvj5K+9K4WjKX0 51zwM4oWi0Qp9UKMuqBau+SVhJWAnW8Nkoh/XAmg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M9Wuk-1iag7C05GW-005cSA; Sat, 14 Dec 2019 17:29:38 +0100 To: ace@ietf.org, stewart.bryant@gmail.com References: <157618348089.20903.16122189372846633578@ietfa.amsl.com> Cc: last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org From: Ludwig Seitz Message-ID: <052b5679-1caa-1feb-e880-387669fa2246@gmx.de> Date: Sat, 14 Dec 2019 17:29:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157618348089.20903.16122189372846633578@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:lNVJCDUwK4tqD/P3LA7qkGTupmG5DVJ1Xun2ZakIt7Y1L9SEVIo jSsZ87yjsHyTPU6pNuTZVpTSTuPO7EmP0COzIDEygIt0TB6dirL1nAbX0DLppeVe7a98eou GJI9YzBYD0HCC+E3k5igSUpgZw4Dqfj5hPOZWQn32LFlc/HBHvMyN5nDfEMbo7+BeirnqGA or6fFc9gcGwc8qzmk69UQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:wLHHuI8Gh4w=:mnToMDyvFGPWqXbnWWMb0o v2ebJ1ESwq0lXzMff2O6zdnzdf/Og8K3Its60bKo7iaFEwm94nKizyancvxUPIHZyz0yI0Q2W ej64WiKMaGXERpHDXhf9ZHDYF7whM+3ytsXj4scvVqEyPaNgrC8gR2mMrVahROsP4WQuIY5Py IddksH/svIr4tvCloS38ZUqZ8fbv+FxLMoOVyTcJvPipxMXVrFG+x1v1Zt+jsZx6v+5jiH6WM AfvCk6IHvWQs9in9XbaJEunpzMjRa5wetze5YSZC5CiDC8MBrm/k5fKnd3nULce5GasipzW8Y 9yRNoW02MMbpjTEa4WMJ399AL/ZUV3Zhr9ro04VPfsMS2zOk8JptYi0oeWbbDNIrEJ9fKwsph ribnlz7HjDe6LVaQqlitzO78GYamvBsvfX3dPT5W0QyJ0SvFjjyi65swn15FEnusBgdYsXY8G U0Ld47jevSBylwbxyO/dAQ9vnmAyzQRN6eA88KZgN38Ep2S2kQhcoJVHJSFelZbw+uxr+fvBQ heCVyByWCvpjWYc8LKVHFfRSr75KdpvydejP7Z3Ru5bM3RV1L7BFf9FRQZMj85riZCcp/SA92 R+wQnxx6nLY7vqm7ffjvgUChwIUTFIKVuxhtNxrOEATsgitAb+MjrjHXkIICr60qW2H7C466U lU9K+1Qyz3CdeDQDZEIddXKqtAFipFizHZbTDasKDi3P7VOFkhz8ZToSrjLKvlGxmRNHfxHEU 5RHxHSdnQa9LtuefbU3g91cxoSJ6g4FGlTTYieqpHRjFoB/el5Q7OrA5xr7tBfvtGmIwLKb3p iMJ7V5J+0gXVeuce420AA9zY5vFNONMvB0g4pHKl2lpb5JDMB2J637kOWIApfvD8hvJGFdbp+ 0FZZbowHJPUbVzbLA7lHFvX809MMWVjMlHNMSdSgW0Z4exDlt7kmY5MhxwlIucRKuLzFtZimc r62c2ADR8aQPg0vxq8gCej7Nf1835K96+yziNe3/IfvUGxXM//+mHM0Z+3hdfCAoKlXhMKx3g hW5GMA90RKDg0jsgNBQRU1usAvu/BevwVxbAy7XAEjtWLtQRxj6rEfgA5QGTYdl9X6GI8QCyn tuZTbqcNI/b/Fp8usv/wYJxNrXMESUhlSt8Sy5p+smZrTiJlgyjpBBgK+ONHg7LuTOGVeGvBP sjueMndllD4Wq0/mNN2Nti4MCnlV76IHG1ayz4kLfMjg2tXZq1hPvgN7t3m0n0oiSG5rxK5M5 3GK5UUzBfY9JxZsmAoEByRv1nr0cMJGfPTNlvQAy1lRdsp4s/tsxu5nGQeDU= Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: ace@ietf.org 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: Sat, 14 Dec 2019 16:29:42 -0000 On 2019-12-12 21:44, Stewart Bryant via Datatracker wrote: > > > Abstract > > This specification defines a framework for authentication and > authorization in Internet of Things (IoT) environments called ACE- > OAuth. The framework is based on a set of building blocks including > OAuth 2.0 > SB> OAuth 2.0 needs a RFC or other reference I'm now in the process of posting -29 including the updates you suggested. The idnits tool complains that the abstract should not contain references, so I'm rolling back those changes. There is a reference to the RFCs of OAuth and CoAP at first mention in the text body. /Ludwig From nobody Sat Dec 14 08:37:35 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F92120105; Sat, 14 Dec 2019 08:37:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157634145359.14864.9921344474293552729@ietfa.amsl.com> Date: Sat, 14 Dec 2019 08:37:33 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-29.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2019 16:37:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-29.txt Pages : 87 Date : 2019-12-14 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 14 08:40:06 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8131212006B for ; Sat, 14 Dec 2019 08:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 pwttak3Phikw for ; Sat, 14 Dec 2019 08:40:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 8139412004F for ; Sat, 14 Dec 2019 08:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576341600; bh=8GwCrsYJ/p9lYq7WaEbL2y83CUSp2e33boyESgSAHFs=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ZnTPq1IrRUEEFEHMhwMAEsvuWMwyNSl01PV5hDuHIBD4VlxUEwR+IC9zRYbz0ff0p FdSAbSlpNTulEF9gvFhK/JvtboGT0D5XbimKFS45pIIsh6ntc7kTf65n0y4hkx1d0i f3evH9kZV3Rh19HRJ4Wa4E7oQWlep+oeNq7dgclY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MYeMj-1iBjXP2yN1-00Vgoa for ; Sat, 14 Dec 2019 17:40:00 +0100 To: ace@ietf.org References: <157634145359.14864.9921344474293552729@ietfa.amsl.com> From: Ludwig Seitz Message-ID: <343fb895-3f24-920f-f677-590a3fc1a679@gmx.de> Date: Sat, 14 Dec 2019 17:40:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157634145359.14864.9921344474293552729@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yBxtwR3KP1T7MBAFGAHZ4XkrpxwqOCDxJsVjmsGGY6nxRBlsv31 lOYzs/9b52Y0hiJcmyVTcIf/7GF8UmvLeX8X3le6nOdgCC+fclFsuStwSoUini1W2XCzuXs 20KjgWcaAoNadn0kGR7zKIEQ1hTFCY3Cq2+IkrhDbq5YZq3apfys3PwUtWFttkTbhwpTGEh jvqOdrqFXCSfFPy3TYvuQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:2MD0WmHzF0I=:VFzTiPR4fFxMY1xq87PUCn 575f7s0PHbzl/XuavG2kTnOpl/V+NtI/6VLLS7y2Bidb5JBvYdQPw9OVDcWd3w6+G3HAx9sM2 EyQdYq70R6DgbWoYaeNzXgI2UQjQ3dkZKa+r+Sfw66s4p3nM++Fon5oNTJac41lxCw3gOT19/ 0FCJZsZdBe3FMJ//SPjsCOQhSnc0GzaDoSO+DFxQh5IL3pkTaN4mdssAYOiPKUpHgc6KWtqyS qcrO+2LGKn5NmoEBSgqy9JJvHbjNJxSNvoclWhdMlXKjV2xHo9Yq5x+/AKNvNWQtIfMf0dXb8 U4746V9FDyc3wvzkbp1VullzRr9x/xy8r5P+VUrEl2vQMX/oYatU2sySymmAti3tatcq2k9jD YHfvS3kZXTC4by9ewt8Ggu5G3V7jWtcnh6D++nUOlH9DrCv7W7rkfiZpzhddqYPXiDWwcUDbv ayeR5mC69YxEzQBxvRrAASXAAynr4hzbwrm0nIc7p5Sm6Yh5fSXNL7Igg9VywH4LpY1X1bgHQ ui31Tgp13eOlUTMFJwkvCuz43DjeoeWm8DCM/Z8jXScw3GPG139rarO8Ih+eXnchnGaulk4vR aPI0wXqQ7syb2HzIP15R9JPHY24s6ZF1e9coXCt3u4KnDIODUkl0pMi30ZEVT/MJiqYLZAGhu H1Ztg+i+B4lJ4+b9KFqJeFRReU/QLOhlu1UT7Z7Hu6vjo+FcHsY9gEcK3IAR1S95zFT+3Zy2G S06bBoAEKSisJ8vAC08TYg0tALImgdgNmVWB6IB/UGlDeJHJl46CJq5U5nQY93Sk4HtSAli0b +PND8vhqO1hR6cbyFmpbqjsLSnU7d1+mmWKqrfoX9oTUg3MbMSSCiFQcAVF5YXZ8QuwYi6VoG leQKBUfHA6lsj65pjT8wi/MzKM492l72dxTIoMn+yeB8Jj9nZDLXJDts5B9NAYXY3I3k8DehX bS6KJDkQqXtIEuBR3gajEwerumqjnSYek7ZXmgNf/6kfKQ3a2YqNWDR/VsVHMMOaly1cbH6Db iuDGyK7JquZEbiSYgbZoa0HHhY/kWoQccX4GrZ30OPgtV+WjJrSc8qdZwU8vcUvp7cyFMFLx3 dXBZhbm53/J8gOdw4O9fdzmdD2XsNLYFiNSqpfV6Q8sWMsWpvZZQ0VfEiIaWVMY68MsR1+WBl wUnm7edosGMu+5FEpaSKrMV6wwHb48l+2oNsQkxgKKosAaqF/Rwlg/pj6umLlhJnR5G6AW6uX 3FkV4+Yw3b8JfNCHrLM2XvZlSk9QulrkLSolr5cRxQOEC9uemAwjVQjFexiM= Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-29.txt X-BeenThere: ace@ietf.org 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: Sat, 14 Dec 2019 16:40:04 -0000 Hello Ace, this update addresses the Genart review kindly provided by Stewart Bryant. /Ludwig On 2019-12-14 17:37, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the Authentication and Authorization for Co= nstrained Environments WG of the IETF. > > Title : Authentication and Authorization for Constrai= ned Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) > Authors : Ludwig Seitz > Goeran Selander > Erik Wahlstroem > Samuel Erdtman > Hannes Tschofenig > Filename : draft-ietf-ace-oauth-authz-29.txt > Pages : 87 > Date : 2019-12-14 > From nobody Sat Dec 14 14:46:08 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3D21200A1; Sat, 14 Dec 2019 14:46:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ace-oauth-params.all@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Elwyn Davies Message-ID: <157636356557.14894.14267145373083139598@ietfa.amsl.com> Date: Sat, 14 Dec 2019 14:46:05 -0800 Archived-At: Subject: [Ace] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2019 22:46:06 -0000 Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ace-oauth-params-06 Reviewer: Elwyn Davies Review Date: 2019-12-14 IETF LC End Date: 2019-12-13 IESG Telechat date: Not scheduled for a telechat I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments. For more information, please see the FAQ at <">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. Document: draft-ietf-ace-oauth-params-06 Reviewer: Elwyn Davies Review Date: 2019/12/14 IETF LC End Date: 2019/2/13 IESG Telechat date: (if known) N/A Summary: Not ready.  In particular there seems to be some doubt as to whether the definitions in this document are actually stable - or alternatively that it lacks a versioning mechanism to cope with changes that the might be. Major issues: Dealing with possible updates to items defined here: In s1 the following appears: These parameters and claims can also be used in other contexts, and may need to be updated to align them with ongoing OAuth work. Therefore, these parameters and claims have been put into a dedicated document, to facilitate their use and any potential updates in a manner independent of [I-D.ietf-ace-oauth-authz]. I am unclear whether this implies that it is intended that these potential updates would alter the definitions here after they have been standardized or alternatively that the standardization of this document should be delayed until the alternative usage is defined.  If the first case applies, I do not see any versioning mechanism that would allow early implementations to cope with later updates of the items defined here.  In the second case, I have to ask myself why this document has been submitted for standardization before the usages have stabilized. Minor issues: ss3.1, 3.2 and 4.1:  The COSE_Key type 'EC' used in several kty fields is not defined.  I assume it should be 'EC2'. ss3.1, 3.2 and 4.1:  Does it matter that the definitions of the x and y parameters in an EC2 key are given as 'h' encodings in RFC8152 but are given as 'b64' in this document?  I am very much not an expert here. s6: This section starts with 'If CBOR is used...': The main ACE draft draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and CBOR encodings of payloads, although CBOR is recommended.  This is not made explicit in this addition to that specification and the use of CBOR diagnostic representation and the prominence of COSE_Key items could make it appear up until s6 that this specification is intended just for CBOR encoding.  A few words at the beginning would clarify the dual alternatives. Nits/editorial comments: General: s/e.g./e.g.,/ (3 places) Abstract, 2nd sentence: s/whishes/wishes/ Abstract: Need to expand AS and RS. s2:  RS, AS and (probably) various other terms are defined in RFC 6749 and need to be expanded on  first use.  Adding something like the para from draft-ietf-ace-oauth-authz would solve this (except for the abstract). Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749] such as client (C), resource server (RS), and authorization server (AS).s2, para 3: Need to expand CoAP on first use. s3:  This section needs a reference to RFC 8152 for the specification of the CWT COSE_Key item that is used extensively. s3/s4: Some introductory text for each section is desirable. s3.1, para 2 (definition of req_cnf):: Possibly add a note that the recommendation against symmetric keys implies currently kty being 'Symmetric'.  Will it ever be anything else? s3.1:  The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-03 contans the following The COSE_Key MUST contain the required key members for a COSE_Key of that key type and MAY contain other COSE_Key members, including the "kid" (Key ID) member. 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. These riders probably apply to all the subsectons of s3 and to s4.1 and could be included in the currently empty main section text. s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also all other uses do not hyphenate and RPK needs to be expanded. s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/ From nobody Sun Dec 15 13:41:33 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9258120096; Sun, 15 Dec 2019 13:41:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ace-coap-est.all@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <157644608676.11574.11677986393566128538@ietfa.amsl.com> Date: Sun, 15 Dec 2019 13:41:26 -0800 Archived-At: Subject: [Ace] Secdir telechat review of draft-ietf-ace-coap-est-17 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2019 21:41:27 -0000 Reviewer: Yaron Sheffer Review result: Ready All my previous review comments have been addressed, either through a mail exchange or in version -16/17. Thank you! From nobody Sun Dec 15 23:32:44 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADC6120025; Sun, 15 Dec 2019 23:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7vYuCfzjGfMN; Sun, 15 Dec 2019 23:32:35 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E13F1200E7; Sun, 15 Dec 2019 23:32:35 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBG7WShF029845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Dec 2019 02:32:30 -0500 Date: Sun, 15 Dec 2019 23:32:27 -0800 From: Benjamin Kaduk To: Ludwig Seitz Cc: ace@ietf.org, stewart.bryant@gmail.com, last-call@ietf.org Message-ID: <20191216073227.GR81833@kduck.mit.edu> References: <157618348089.20903.16122189372846633578@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27 X-BeenThere: ace@ietf.org 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, 16 Dec 2019 07:32:37 -0000 On Sat, Dec 14, 2019 at 05:20:34PM +0100, Ludwig Seitz wrote: > On 2019-12-12 21:44, Stewart Bryant via Datatracker wrote: > > ==== > > o A RS sending a "cnonce" parameter in an an AS Request Creation > > SB> An RS... > > This doesn't feel right, since there is no consonant in RS and the R in > "Resource Server" (the expansion of RS) is not silent either. Is there a > grammar rule that I'm unaware of? > > You did however make me aware of a typo later in that sentence where > there it says: "an an". I think you would say "a resource server" but "an ar ess". -Ben From nobody Mon Dec 16 14:02:12 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A956A120936; Mon, 16 Dec 2019 14:02:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <157653372668.24465.13819182999807823012.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 14:02:06 -0800 Archived-At: Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 22:02:07 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 4. Per “the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other”, I think the text means that some EST messages are more likely to occur one after another. It would be worth being clearer what these would be. * Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does Table 1 imply that when using EST-coaps the “longer names” from RFC7030 wouldn’t be valid? * Section 5.2 Per “The latter ones are deemed to expensive …”, was difficult to parse as the sentence prior has three things (instead of two). Is this sentence referring to the “not specified functions” only? * Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite this metric, please do. * Section 5.8. Per “In summary, the symmetrically encrypted key is included in the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in a server-side key generation scenario, where is the client getting the key to decrypt the server computed key material? Should the DecryptKeyIdentifier/ AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections 4.4.1.1/4.4.1.2 of RFC7030? * Section 10.1. Per “When server-side key generation is used, the constrained device depends on the server to generate the private key randomly, but it still needs locally generated random numbers for use in security protocols, as explained in Section 12 of [RFC7925].”, is the “security protocols” referenced here anything beyond DTLS? * Section 10.1. Per “In such occasions, checking the certificate revocation status or authorizing the client using another method is important for the server to ensure that the client is to be trusted.” -- does this text suggest that expired+revoked certificates should not be used? -- to word-smith: s/for the server to ensure that the client is to be trusted/for the server to raise its confidence that the client can be trusted/ * Section 10.1. Per “More information about recommendations of TLS and DTLS are included in [BCP195]”, thanks for referencing BCP195. Could you please clarify with normative language if these recommendations SHOULD/MUST be followed? * Editorial - Section 4. Per “Authenticating and negotiating DTLS keys requires resources on low- end endpoints and consumes valuable bandwidth”, I’m not sure this sentence is needed. Technically, “authenticating and negotiating DTLS keys requires resources” on any endpoint. - Section 4. OLD: Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, NEW: Given that after a successful enrollment, it is more likely that a new EST transaction will not take place for a significant amount of time, - Section 5.5. Typo. s/successfull/successful/ - Section 5.8. s/Such scenarios could be when it is …/Such scenarios apply when it is …/ - Section 5.8. s/ client, or when the resources/client, when the resources/ - Section 5.8. s/Then the private key/The private key/ From nobody Mon Dec 16 18:58:44 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 573C212009C; Mon, 16 Dec 2019 18:58:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <157655152334.24617.3401591731456466633.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 18:58:43 -0800 Archived-At: Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 02:58:44 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this — a useful document. I have a bunch of comments, but they’re all editorial. Please consider them, but there’s not a need to give a detailed reply. -- Section 4 -- In that case, the server MAY want to authenticate a client certificate against its trust store although the certificate is expired (Section 10). Total nit: Why "want to"? Why not "server MAY authenticate"? As described in Section 2.1 of [RFC5272] proof-of-identity refers to a value that can be used to prove that the private key corresponding to the certified public key is in the possession of and can be used by an end-entity or client. I find the passive voice to be quite awkward here, and suggest making it active: NEW As described in Section 2.1 of [RFC5272], proof-of-identity refers to a value that can be used to prove that an end-entity or client is in possession of and can use the private key corresponding to the certified public key. END the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed as if each handshake message had been sent as a single fragment (Section 4.2.6 of [RFC6347]). I know this wording is directly from 6347, but I think it's unclear and would like to suggest an alternative. The "as a single fragment" part is odd, because I think what it's really saying is that it's computed as if it had not been fragmented. My suggestion is to change it thus (and similarly for the next paragraph after): NEW the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed on each reassembled message, as if each handshake message had not been fragmented (Section 4.2.6 of [RFC6347]). END If that's not correct, please take that as further evidence that it's unclear, and adjust accordingly. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions which was not the case with [RFC7030]. For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. Two total nits: a. Comma before "which", please. b. The "for example" needs some rewording to make it work: NEW For example, if an EST csrattrs request is followed by a simpleenroll request, both can use the same authenticated DTLS connection. END -- Section 5.1 -- EST-coaps is targeted for low-resource networks with small packets. Two types of installations are possible (1) rigid ones where the address and the supported functions of the EST server(s) are known, and (2) flexible one where the EST server and it supported functions need to be discovered. This needs a colon (:) after "possible", a comma after "rigid ones", "a" before "flexible one", another comma after "flexible one", and make it "its supported". -- Section 5.5 -- Similarly, 2.04 is used in successfull response to EST-coaps POST requests (/sen, /sren, /skg, /skc). There's odd spacing here; please fix it. And "successful" is misspelled. -- Section 5.7 -- If the server is very slow (i.e., minutes) in providing the response (i.e., when a manual intervention is needed), I think you mean "e.g." for both of those, evidence for my general aversion to using Latin abbreviations that many people don't fully understand. It also feels odd to have the two examples separated in this way. I suggest this: NEW If the server is very slow in providing the response (for example, manual intervention is required and it could take minutes for it to respond), END it SHOULD respond with an ACK containing response code 5.03 (Service unavailable) and a Max- Age Option to indicate the time the client SHOULD wait to request the content later. Perhaps, "to indicate the time the client SHOULD wait before sending another request to obtain the content." ? After a delay of Max-Age, the client SHOULD resend the identical CSR to the server. As long as the server responds with response code 5.03 (Service Unavailable) with a Max-Age Option, the client SHOULD keep resending the enrollment request until the server responds with the certificate or the client abandons the request for other reasons. That last sentence reads very strangely to me. It SHOULD keep resending the request until it decides to stop? What does that actually mean? Maybe what you're really trying to say is something like this?: NEW As long as the server continues responding with response code 5.03 (Service Unavailable) with a Max-Age Option, the client will continue to delay for Max-Age and then resend the enrollment request until the server responds with the certificate or the client abandons the request for policy or other reasons. END -- Section 5.8 -- In scenarios where it is desirable that the server generates the private key, server-side key generation is available. This seems like a content-free sentence. Maybe this?: NEW Private keys can be generated on the server. Scenarios where that makes sense include those where it is considered more secure... END Of course, that does not eliminate the need for proper random numbers in various protocols like (D)TLS (Section 10.1). May I suggest this?: NEW As always, it is necessary to use proper random numbers in various protocols such as (D)TLS (Section 10.1). END server or proxy to generate the private key and the certificate which are transferred back to the client Needs a comma before "which". or the asymmetric keypair establishment method is out of scope of the specification. "of this specification". [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.3) . The two representations More odd spacing. Dependent on the request, the private key can be in unprotected PKCS#8 [RFC5958] format "Depending upon the request" In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client-defined (in the CSR) asymmetric public key and is carried in an encryptedKey attribute in a KeyTransRecipientInfo structure. Long sentence that needs punctuation: comma after "operations", comma before "which", comma before "and". Also, I would move "(in the CSR)" a few words later, after "public key". -- Section 7 -- It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). Odd spacing, again. But "it is recommended to follow" is also odd English. I suggest making this active, rather than passive, thus: NEW Implementations should follow the default CoAP configuration parameters ([RFC7252]). END I don't think the "based on experiments" bit adds anything, but if you want to keep it you can prepend "Experiments have shown that" to my suggestion. -- Section 9.1 -- Don't you want to remove the "TBD" on "TBD287" here? Wasn't the "TBD" just a flag to remind people that it hadn't been formally allocated yet? — Section 10.1 — It is important to note that sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs are not available on many constrained devices, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, as pointed out in [PsQs]. The sentence order is wrong here. For example, mouse movement is not a constrained device. The correct order is more like this: NEW It is important to note that, as pointed out in [PsQs], sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, are not available on many constrained devices. END From nobody Tue Dec 17 08:31:16 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9A3120A83; Tue, 17 Dec 2019 08:31:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157660027579.26344.9707041316143820389@ietfa.amsl.com> Date: Tue, 17 Dec 2019 08:31:15 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 16:31:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-07.txt Pages : 13 Date : 2019-12-17 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client whishes to use, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 17 08:53:08 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4DD12007C; Tue, 17 Dec 2019 08:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 CDVY-ULUhuDa; Tue, 17 Dec 2019 08:52:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C37512002F; Tue, 17 Dec 2019 08:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576601571; bh=c9d+xk1QPzKfC7vDjZu3y5w4ckX62ZxwsBoV1iGzGLg=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=kRotzttMNl7nMDyJgWO4VSi8D2QVIeJnBILB5v1bB3q7+WkafvRxk3SNAfKtE+Wey JoboTYeAzcTxEdyNQnEIYJTqD3/wLto/5Uu/4pPDr4cSGicwGNGPEH+dYAz2zA3J1Z DYvyhGbAUTTWkhuEOytg9rX5n8m+XCyLvqGGcelI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJE6F-1iNoCG04c7-00KiL3; Tue, 17 Dec 2019 17:52:51 +0100 To: elwynd@dial.pipex.com References: <157636356557.14894.14267145373083139598@ietfa.amsl.com> Cc: ace@ietf.org, gen-art@ietf.org, last-call@ietf.org From: Ludwig Seitz Message-ID: <6da3360a-157e-e3cf-d1ea-109d8515da42@gmx.de> Date: Tue, 17 Dec 2019 17:52:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157636356557.14894.14267145373083139598@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:fKPO6uXBZwk7PnVx2MZn8qVJVdEv2pB19gQAVVN3T5AMJcEvrzV P7yKBG6CNbAQ2H6sg17GTq2bDa5LkE0aUIzKYEG6vZMe7dLZHrff4TFgXtTfUC5y9EzNrcP iZNrByaTE+oHTUeEIz1jRdcde7R/X3ZDZ8x7a0ym5eihO5jC0hAZSQoosRb/ApaQstaK+gz oEGF+igAVl8OJVnUfqQIA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Cl3qiFYRSEE=:sJT8nuD8kkPNu0OvbXO+8m syumei06wDWLeo9gBNB8VTi3DazeCrNu1U5J34dM5xnW/lST8dfeeeSe6/SN3V8kezDhW8wPp +Zzgzey67XlY+h+pEnJX0j9GuJhpCgWNPXFw9lazSlLlsk53akmFevG6J45ov8RM3X4UvWQtC WyrgV7dmkR3CfF37RWrAwvvw1uos6kIXubbhOAoGoqPrn7buKHHqgA9AvUR8W5SRZIIW4c/d+ qTgytMNAGAj5mmJ9axZGjyMyNmBtFfc8ZjE4RRnieDWeH48lyuVp1MkGXF4C8lFw6t9PpDIKp m+CDPi+BhlO5tCS6oT8O1EQaXnbLdbjmiOcBHdGAcjBahp2MO41G9GEq1tB9GVHRD63ZESLCY xZu4mLaIG6yXilKOnK9pi3yDxcVIHbU/Hyjx3RrRLFQTxjGSIMpKxz7bEIKjW13MSiblNvEDV dDtu199AJfJODoqC9nanRmF/ze9ukFr3554TuDpulmfX7e/Os7bMbHFw1lcAERfchwyR8ipaK MVSru+eFwcOI9S5FVW6R7Vpf1tvb0B4066xzGcfLD9OihwrtO8octegCtop9A3/nPOurCjo1b trwveJIuKE7xUVGzAyu6LjyPe8NGalLQt6/k2aYyO9TABAqjnJXl3dIibWo0gvMvvA9FankMA /2R/GM8E+IVxbChmuY3oDaTqdVyNxI6I+E1nr5r+ePVLRqpp+XY2sUCPhXoA/2ae+eiullspY qZLQktHpmsYITXviHDvLFOuFLF24Qewzlbfp3BHjC7kyLq664GAcN0NzHjd2cZZlnwhsNkr+p NbXjY6gJSFE8+CsdC53Hco6tJGTP/2aDJ/m+IdocMd0JDNlJXINONjRSgUkSEuiGbhELsEbPm miVoWT/oIHAXiN9r+T84ffr652110kW+6UGYyuo1xOtkmVJpAhsJ6xjLrVLFefbQYWABMRKwz A+lHbFWkUSIm9kJtEZV/2ZRDfVp76n23NXCFUAkYjT3f1IsVrQtlhYEuREjfnFpdzu8U4rqAZ Pu4nF2f+hkfKg/qm/d/qAf9MVgj2GVEyB9HFH+1nr8x0Z+20RL6/OpDVOn826EDLap3Re7nww f6dgKAFx2A375ic/p/zW+leB9HxRvEJQWlw9qXAlGe870Q7ARJmjLJCeHlR7N01M7EYHpLqoG O15aAglE+jphoQ5vzWc5PIiTvi40Zpi99H7LtEAIwcnvJk1XCe76OSboGcPWb1vME1sVTYSek w2Zvn6tZW7Qlh/y6/S0AtvWiX95zv5NFGuEV7uduVufHvjK6itXwAfxqcZjc= Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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, 17 Dec 2019 16:52:59 -0000 Hello Elwyn, thank you for your review. Comments inline. /Ludwig On 2019-12-14 23:46, Elwyn Davies via Datatracker wrote: > Reviewer: Elwyn Davies > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ace-oauth-params-06 > Reviewer: Elwyn Davies > Review Date: 2019-12-14 > IETF LC End Date: 2019-12-13 > IESG Telechat date: Not scheduled for a telechat > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair.=C2=A0 Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. > > Document:=C2=A0draft-ietf-ace-oauth-params-06 > Reviewer: Elwyn Davies > Review Date: 2019/12/14 > IETF LC End Date: 2019/2/13 > IESG Telechat date: (if known) N/A > > Summary: Not ready.=C2=A0 In particular there seems to be some doubt as = to whether > the definitions in this document are actually stable - or alternatively = that it > lacks a versioning mechanism to cope with changes that the might be. > > Major issues: > Dealing with possible updates to items defined here: > In s1 the following appears: > > These parameters and claims can also be used in other contexts, and= may > need to be updated to align them with ongoing OAuth work. Therefore= , these > parameters and claims have been put into a dedicated document, to > facilitate their use and any potential updates in a manner independ= ent of > [I-D.ietf-ace-oauth-authz]. > > I am unclear whether this implies that it is intended that these potenti= al > updates would alter the definitions here after they have been standardiz= ed or > alternatively that the standardization of this document should be delaye= d until > the alternative usage is defined.=C2=A0 If the first case applies, I do = not see any > versioning mechanism that would allow early implementations to cope with= later > updates of the items defined here.=C2=A0 In the second case, I have to a= sk myself > why this document has been submitted for standardization before the usag= es have > stabilized. > The intention with this document was to place certain parameters (req_cnf, cnf, rs_cnf) needed for draft-ietf-ace-oauth-authz into a separate document, that could be updated or obsoleted by other drafts without obsoleting or updating draft-ietf-ace-oauth-authz. This is mainly due to some work in the OAuth WG which has been running in parallel, especially https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution. Since this is not a high priority item for OAuth (the draft named above has expired), the feeling in ACE was (@ACE please correct me if I misrepresent) that going forward with this document was a good compromise to get these parameters standardized, while causing minimal breakage if OAuth at some later point finalized the pop key distribution work. > Minor issues: > ss3.1, 3.2 and 4.1:=C2=A0 The COSE_Key type 'EC' used in several kty fie= lds is not > defined.=C2=A0 I assume it should be 'EC2'. > Correct, will fix > ss3.1, 3.2 and 4.1:=C2=A0 Does it matter that the definitions of the x a= nd y > parameters in an EC2 key are given as 'h' encodings in RFC8152 but are g= iven as > 'b64' in this document?=C2=A0 I am very much not an expert here. This is just a matter of the diagnostic representation used here for human readability. On the wire this will be the same binary string. Note that the hex encoding h'....' renders a much longer string than the Base64 encoding b64'...' so I prefer b64 for readability. > > s6: This section starts with 'If CBOR is used...': The main ACE draft > draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and= CBOR > encodings of payloads, although CBOR is recommended.=C2=A0 This is not m= ade explicit > in this addition to that specification and the use of CBOR diagnostic > representation and the prominence of COSE_Key items could make it appear= up > until s6 that this specification is intended just for CBOR encoding.=C2= =A0 A few > words at the beginning would clarify the dual alternatives. > I will add a clarification. The intention is to cover both JSON and CBOR. > Nits/editorial comments: Will fix. > General: s/e.g./e.g.,/ (3 places) > > Abstract, 2nd sentence: s/whishes/wishes/ > > Abstract: Need to expand AS and RS. > > s2:=C2=A0 RS, AS and (probably) various other terms are defined in RFC 6= 749 and need > to be expanded on=C2=A0 first use.=C2=A0 Adding something like the para = from > draft-ietf-ace-oauth-authz would solve this (except for the abstract). > > Terminology for entities in the architecture is defined in OAuth 2.= 0 > [RFC6749] such as client (C), resource server (RS), and authorizati= on > server (AS).s2, para 3: Need to expand CoAP on first use. > > s3:=C2=A0 This section needs a reference to RFC 8152 for the specificati= on of the > CWT COSE_Key item that is used extensively. > > s3/s4: Some introductory text for each section is desirable. > > s3.1, para 2 (definition of req_cnf):: Possibly add a note that the > recommendation against symmetric keys implies currently kty being 'Symme= tric'. > Will it ever be anything else? > > s3.1:=C2=A0 The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-0= 3 contans > the following > > The COSE_Key MUST contain the required key members for a COSE_Key of= that > key type and MAY contain other COSE_Key members, including the "kid"= (Key > ID) member. > > 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 exp= lained > in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be > encrypted as described in Section 3.3. > > These riders probably apply to all the subsectons of s3 and to s4.1 and = could > be included in the currently empty main section text. > > s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also al= l other > uses do not hyphenate and RPK needs to be expanded. > s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Tue Dec 17 08:54:56 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652A9120B09 for ; Tue, 17 Dec 2019 08:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 oIOOwOpbF4m5 for ; Tue, 17 Dec 2019 08:54:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 91842120B07 for ; Tue, 17 Dec 2019 08:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576601687; bh=DTuLnZYXKU9eaUgq0kSkNiFdRIJpDirRICu8OtE12eA=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=V/gL55dPuEBfBdtCLIAol9JJ2Qvtc5GTu59ivkty4aoJ7HVvCXAD6OMGtxVonLLT2 7266t9cnSXJ/ShIlFxqrD34aHhq0aES/Noen82tcVyHX5yNLfaZnA/CsQWFXrU733n tjZfyrjeVbQZf7kwTDrtvTed/XFTub+RW1mmu1BE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MF3HU-1iRu3D14HI-00FThW for ; Tue, 17 Dec 2019 17:54:47 +0100 To: ace@ietf.org References: <157660027579.26344.9707041316143820389@ietfa.amsl.com> From: Ludwig Seitz Message-ID: <10d3463f-c495-62d2-b97a-67cf732435ed@gmx.de> Date: Tue, 17 Dec 2019 17:54:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157660027579.26344.9707041316143820389@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:QoQ0zbMrI/eydQFf+VL93fSRw5CgFVlsskHaZmanQR0UlveLjkM whkCwCqwWOHpQg+A+5ApHoaMpIDZx8HjyrP3LqUtyJPXbfOahgMWuT5oRbu4paRtNZf+NxK NfzRQ0fu3IVw2UCtWz7baPI8uQ/86lBao0rvzSmUiD1HhIa+MVhY5J3vzFYNbDNAbvU7QEA Vgta6hpHD3n1iv7cp02kQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:cP23mUkl+9E=:67z6xxY1PU2vkXKrJ2P3Ho UCv7YdbR8JsvOryZd9axBq8p0hHcB8P2xqTQRJ3M0dF5/37uxAUhRoQNjSDoZLJuT2j2Tm6e/ Kc8J2hVi2Ikx7YBkoDF7e0gwCSRcx+aTQXeBSbMY79fDeV68ZPCKFKL43XrO1K+6eBisN81Ma euQb7gGe7qphb9jaqEJvxofcmr09wMYOIyFejf1Fk55YdwsQTcyFprCnkyj0WPsg8/TpPT4a4 hTcN8hLR/FWyaPVEfTJxCQ5BMJzA30XWCvqsR0srqbWcmSX1Jv/sjjpFmwjs20IPScM2uDaqa asl4VBcrm/3Vc2MiHy+Kj5sOIF9RPRqabHvJk3jxS1FNywu3FCiCBgCdETVz5/FhsQTf1o6Bw tbaafSouv+2MoQK0I85R2G8gQ1N37ZmItippD6vMLsqTijJIiRpm3802I7yf2BRM9sXMcjrko HDZofVNQLjro6VsX2Ezs32ccsDj9tjKmdZAKXqSGNIv6IPVxsg7d/RgXCSKfvF8PCTvRCbbyf 42KDm7E1hHx9dItoc/oVQfHS7Ne21MYq6YYA805EoWrQuvnuw+tqVR1P972NUPi+4te0ocyyY M8WDmu1R2pOq733vWBKDOJHNudu1+mxSo4hOCrotPAxCh4CnqBnaGW6rYmFVf8sZu7+7zF1do Luaak049F99m2XXXfNRd5U0KJ7/xwF1o5JdMOGvU77etJiiXsNBpzM5LnriZFqnozsfjL1pyk 07THE05J/hSXW4QTfK9nl24zVL7iQfGGJOqTg7MQ6JhKSPsoAb13yMo8ZYNiUPtkd3g+Fd+z3 2ldLwNR5zgCrfUxkKBocjCUFk87uY3tmDtrSVroB8RYGh0LPuxguD1BzRVTgCJLE9ZQ4l3Ayv ogZDun204IM8awSyv1QNkFXcjVFm5cc//BEGA2VsFw4XBxuG64Pq44buAMw4ChWXtN7ivhn/A X525nku6GUpzQUFr+N8WPJG96jXWvd+7/aSq1dUudPy+LCzJutGeJPtz6jIE6f1ft+T0+mKg+ OvwpEH9xhIA8Ok/Rgd0rvj0nsqUreodRvJFaasWz82qbaJ+3YTpkI6VDJkXma4nnKSnUlfSQ7 5vTIo6ucV+wZEs2AB3ztXSTLO8lmHaszEVVxQEoNGiU1JFSVDWV1FdGvZ24/j9by92EzZ7KCF dSMjjpKqU9t1lCjwYKdfrk4Lu1+tjmHbbiwm6MjS8YdYfMYmPOR3Aw6pRPeixR7ulNjfEUiT5 aG5iEElE6qTT/DvgqNbdVCyIMyhXoGirXMyZ4qLNBmVgAc++rd/ahOKbP/x4= Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-params-07.txt X-BeenThere: ace@ietf.org 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, 17 Dec 2019 16:54:55 -0000 Hello ACE, this update is just to correct my affiliation and contact email. No other changes should be made here. /Ludwig > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the Authentication and Authorization for Co= nstrained Environments WG of the IETF. > > Title : Additional OAuth Parameters for Authorization= in Constrained Environments (ACE) > Author : Ludwig Seitz > Filename : draft-ietf-ace-oauth-params-07.txt > Pages : 13 > Date : 2019-12-17 > > Abstract: > This specification defines new parameters for the OAuth 2.0 token an= d > introspection endpoints when used with the framework for > authentication and authorization for constrained environments (ACE). > These are used to express the proof-of-possession key the client > whishes to use, the proof-of-possession key that the AS has selected= , > and the key the RS should use to authenticate to the client. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-params-07 > > > Please note that it may take a couple of minutes from the time of submis= sion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Tue Dec 17 11:35:32 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 387C2120874; Tue, 17 Dec 2019 11:35:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157661132422.26387.11388034337323397614.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2019 11:35:24 -0800 Archived-At: Subject: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 19:35:24 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 10.1: "It is also RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication." This strikes me as a slightly odd use of normative language (what are the exception cases when the trust anchor database should not be carefully managed?). From nobody Tue Dec 17 11:36:48 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222FA120864; Tue, 17 Dec 2019 11:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Af2oMvJJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O4NMIf/D 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 tob30ixfu1gl; Tue, 17 Dec 2019 11:36:41 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D2D120125; Tue, 17 Dec 2019 11:36:41 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 5C640547; Tue, 17 Dec 2019 14:36:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 17 Dec 2019 14:36:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=pf+I+61K/xgDWthqrVp6Zk+ l/bPYHInvAwTCPSv2iR8=; b=Af2oMvJJHUUgov9ikv6B46CgirQOM4v8E8SSB00 Ar2nBOGQSTtwnmrC2lyoVXWohmvt8qna5ai/AuzGHrO6jHixmDoql0opmESgsfXX A3fO3r99OmfqLG2cddcu5cURDR5FhP38S0VVQjH80EKpIpgDcZUhTRot2Of9Nyam 6I1BmJsNppIteWDhYJWd/cZopFYO4LlxhMRZwiGDVSOs4ZDHuMnxEwsTnjzhrE6k UXgcxQgB7R+w16ZOehgUILfCPbylrDU2VrBxiSr/VWgvIRzAjTGgG5/1boT8NRyT cxmcOVih1NGDkcdqMUkWj1U5subVOewXl+QWVMpfpZhZUEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pf+I+6 1K/xgDWthqrVp6Zk+l/bPYHInvAwTCPSv2iR8=; b=O4NMIf/DejPYs39r15Nxvj 7KHbhSnbyuPo0ErL658VbQBn8SM0tmAE6DenPmptXg2tFLzorF76mrLQqo48TgNT WC8tOMyx7FblhsJfs6sMvEAz/a7xc4HV3IK4HdaMTcz8Autaf9QKO3GvPX0XEKak vWyfO1IzC/pJd2noFL5rIKrhV2dllAOFa/cla0+okAMccvqMfDVQAJ459/BKJ7El zL/aaluBAtWiJfESKy6bGQyMis6qIHTPsw53fLHOJKZrFLwzaHaV/vCifDFTKQZZ MP4W3DVCoviHaRgpc09LQ65cEHZVTv9crzt9rQWrSA1TDOGOwT5HYE/UkRMkJOww == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtjedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepud ejfedrfeekrdduudejrdeltdenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgr segtohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id D6A3680059; Tue, 17 Dec 2019 14:36:38 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D60C67A5-9F45-4827-96FD-F6CBDEFAA024" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 17 Dec 2019 14:36:36 -0500 In-Reply-To: Cc: "gen-art@ietf.org" , "draft-ietf-ace-coap-est.all@ietf.org" , "ace@ietf.org" , last-call@ietf.org To: "Panos Kampanakis (pkampana)" , David Schinazi References: <157033736912.16707.14556141146758239410@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-coap-est-15 X-BeenThere: ace@ietf.org 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, 17 Dec 2019 19:36:44 -0000 --Apple-Mail=_D60C67A5-9F45-4827-96FD-F6CBDEFAA024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii David, thanks for your review. Panos, thanks for your response. I = entered a No Objection ballot. There will not be further Gen-ART = reviews. Alissa > On Oct 8, 2019, at 2:37 PM, Panos Kampanakis (pkampana) = wrote: >=20 > Thanks David. Done. I replaced the RFC7525 references with BCP195.=20 >=20 > Should I upload or will there be more Gen-ART reviews? >=20 >=20 > -----Original Message----- > From: Ace > On = Behalf Of David Schinazi via Datatracker > Sent: Sunday, October 06, 2019 12:49 AM > To: gen-art@ietf.org > Cc: draft-ietf-ace-coap-est.all@ietf.org = ; ietf@ietf.org = ; ace@ietf.org > Subject: [Ace] Genart last call review of draft-ietf-ace-coap-est-15 >=20 > Reviewer: David Schinazi > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please treat these comments just like any = other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ace-coap-est-?? > Reviewer: David Schinazi > Review Date: 2019-10-05 > IETF LC End Date: 2019-10-18 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Document is clear and well-written. >=20 > Major issues: None. >=20 > Minor issues: None. >=20 > Nits/editorial comments: I believe references to RFC7525 should = instead refer to it as BCP195 to point to future revisions. >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace = >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_D60C67A5-9F45-4827-96FD-F6CBDEFAA024 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii David, thanks for your review. Panos, thanks for your = response. I entered a No Objection ballot. There will not be further = Gen-ART reviews.

Alissa


On Oct = 8, 2019, at 2:37 PM, Panos Kampanakis (pkampana) <pkampana@cisco.com> = wrote:

Thanks David. Done. I replaced = the RFC7525 references with BCP195. 

Should I upload or will there be = more Gen-ART reviews?


-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of David Schinazi via Datatracker
Sent: Sunday, October 06, 2019 = 12:49 AM
To: gen-art@ietf.org
Cc: draft-ietf-ace-coap-est.all@ietf.org; ietf@ietf.org; ace@ietf.org
Subject: [Ace] Genart last call = review of draft-ietf-ace-coap-est-15

Reviewer: David Schinazi
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The = General Area Review Team (Gen-ART) reviews all IETF documents being = processed by the IESG for the IETF Chair.  Please treat these = comments just like any other last call comments.

For more information, please see = the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: = draft-ietf-ace-coap-est-??
Reviewer: David Schinazi
Review Date: 2019-10-05
IETF LC End Date: 2019-10-18
IESG Telechat date: Not scheduled for a telechat

Summary: Document is clear and = well-written.

Major issues: = None.

Minor issues: = None.

Nits/editorial = comments: I believe references to RFC7525 should instead refer to it as = BCP195 to point to future revisions.


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_D60C67A5-9F45-4827-96FD-F6CBDEFAA024-- From nobody Tue Dec 17 18:28:45 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB8120043; Tue, 17 Dec 2019 18:28:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157663612332.4994.1427589526663831052.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2019 18:28:43 -0800 Archived-At: Subject: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 02:28:43 -0000 Adam Roach has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work that the authors and working group put into this document. I have one DISCUSS-level comment that should be very easy to resolve, and a small number of editorial nits. --------------------------------------------------------------------------- §9: Since this specification is adding new endpoints under /.well-known/est, it needs to update the "Well-Known URIs" registry so that the entry for "est" indicates this document (in addition to RFC 7030). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §5.3: > The Content-Format (HTTP Media-Type equivalent) of the CoAP message HTTP doesn't have a "Media-Type" field. Presumably this intends to say "Content-Type"? --------------------------------------------------------------------------- §5.3: > Media-Types specified in the HTTP Content-Type header (Section 3.2.2 Nit "...header field..." --------------------------------------------------------------------------- §5.5: > HTTP response code 202 with a Retry-After header in [RFC7030] has no Nit "...header field..." From nobody Wed Dec 18 02:57:01 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232B7120949 for ; Wed, 18 Dec 2019 02:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QUD2r5ZFPzkD for ; Wed, 18 Dec 2019 02:56:53 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 797C9120959 for ; Wed, 18 Dec 2019 02:56:52 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id e6so1599601qtq.7 for ; Wed, 18 Dec 2019 02:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=pdtdsbnEQNbHnLeggRisVUHuROwlr8BhnOlEH3THvnY=; b=jOkBceDu0pxJsG5Lk2YZYvhu+EZfSnZp8ZAG4WQ9Ulr+0LMQV0dgSEE0P5krKawxWV sL+H4El4hHXa3CErGbNp0tN9NrKV6iImsjOfkWrD6MMFIzskxGNe9uBKvOaZ3ZVYnGHG p3iFI0RE9dyc9xNgLWuKRSDOwzaXVcvawSVnbPe9kWY3g35nbCojNr3upRtXOrxKvuWl FksCsIfhqlUNiAbQKYBcK5qBRXi0+QqPMD2+ayU/uKXbrkRi4TEQnB6VnkDjlBCh1SKZ l2RP+WZjhP0H90HAhlcUleHZiHOf93L4VRIJHRQI7kkKYWdCRID//3yu5GNbPvjTQG6G 2KPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pdtdsbnEQNbHnLeggRisVUHuROwlr8BhnOlEH3THvnY=; b=jn3Axm8/Thb1GvufciSRAyMFi8dhpvKd/ckNtojokCZxoURCop+1nJDfu5CMkOtjn2 nOpr+UGFpfJ0SVPccsfD+4LiIdkHMFcEHrAQARd2N3i37hSeW5FtefWzm54zmgm0zV7w jZh1PeRmWgAap2YPiqSn3jitw/zeuK4tk9YHApKSEiSpWVbZtHQvlRDQZvx126lnKgHU x0qvcXR+y6wE7OiUPTw/98q9CbYIXKZgBQdYhMQwJxo+LFOKT4bvew3xQKOvkLyrBu0f 5xXXYmgXI3d8/YJ+N1ktp5kzjahQESLSgwKMawZKNAWkjKpRkD0Q44wnvX+3+zjfwdCY EZrQ== X-Gm-Message-State: APjAAAXqS7uCDDwEZurKDbgxhe8px79VdG2grgoaXN/K3L2xoAyWxbTC Xdq/MWuKIJBTV5HH5I42wzgW+6pmbB7JG5y0cMzWrCEBsck= X-Google-Smtp-Source: APXvYqwkZmSWEEkSkA+kXpQM6GcVj2JiJCld9F6ikSvVN93UuB6xVq1/VBFAQccAu2xBSsjai4MTS9mqHn6AMpaTT2k= X-Received: by 2002:ac8:42cd:: with SMTP id g13mr1561921qtm.168.1576666611466; Wed, 18 Dec 2019 02:56:51 -0800 (PST) MIME-Version: 1.0 From: Cigdem Sengul Date: Wed, 18 Dec 2019 10:56:40 +0000 Message-ID: To: Jim Schaad , Daniel Migault Cc: Ace Wg Content-Type: multipart/alternative; boundary="0000000000004e47970599f84de4" Archived-At: Subject: [Ace] Version -03 prep for draft-ietf-ace-mqtt-tls-profile X-BeenThere: ace@ietf.org 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: Wed, 18 Dec 2019 10:57:00 -0000 --0000000000004e47970599f84de4 Content-Type: text/plain; charset="UTF-8" Dear Jim and Daniel, As discussed in Singapore, we've started working on the -03 based on the comments we've received. https://github.com/ace-wg/mqtt-tls-profile/tree/v-03-WIP The main changes are: Version 02 to 03: 1) Added the option of Broker certificate thumbprint in the 'rs_cnf' sent to the Client. 2) Clarified the use of a random nonce from the TLS Exporter for PoP, added to the IANA requirements that the label should be registered. 3) Added a client nonce, when Challenge/Response Authentication is used between Client and Broker. 4) Clarified the use of the "authz-info" topic and the error response if token validation fails. 5) Added clarification on wildcard use in scopes for publish/subscribe permissions 6) Reorganised sections so that token authorisation for publish/subscribe messages are better placed. 7) Clarified protection of Application Message payload as out of scope, and cited draft-palombini-ace-coap-pubsub-profile for a potential solution Could you provide input regarding the following: 1) Based on Jim's suggestion I added a statement that says: The AS MAY include the thumbprint of the RS's X.509 certificate in the 'rs_cnf' (thumbprint as defined in ), then the client MUST validate the RS certificate against this thumbprint. Is this implemented by rs_cnf = x5t and then the client computes the hash and checks against x5t? Regarding other questions raised by Jim on OASIS certificate guidelines and the mqtt/mqtt(s), I have not managed to get more information than: 1. there is no official UIR scheme but there is a community wiki entry which proposes something: https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme. The MQTT 5 server redirection feature uses a very simple way of indicating a server reference, see https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Server_redirection 2. There's currently no certificate validation document. The recommendations linked in the spec can be found here: https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901280 . 2) I temporarily added the exporter label to our draft but will wait on the final decision on that. So, if it is defined and registered in another document, I can refer to it. I will push changes as 03 once there is an agreement on how to resolve these issues. Kind regards, --Cigdem --0000000000004e47970599f84de4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jim and Daniel,=C2=A0

A= s discussed in Singapore, we've started working on the -03 based on the= comments we've received.=C2=A0

https://github.com/ace-wg= /mqtt-tls-profile/tree/v-03-WIP

The main changes are= :
=C2=A0Version 02 to 03:
=C2=A01) Added the option of Broker = certificate thumbprint in the 'rs_cnf' sent to the Client.
=C2= =A02) Clarified the use of a random nonce from the TLS Exporter for PoP, ad= ded to the IANA requirements that the label should be registered.
=C2=A0= 3) Added a client nonce, when Challenge/Response Authentication is used bet= ween Client and Broker.
=C2=A04) Clarified the use of the "authz-in= fo" topic and the error response if token validation fails.
=C2=A05= ) Added clarification on wildcard use in scopes for publish/subscribe permi= ssions
=C2=A06) Reorganised sections so that token authorisation for pub= lish/subscribe messages are better placed.
7) Clarified protectio= n of Application Message payload as out of scope, and cited draft-palombini= -ace-coap-pubsub-profile for=C2=A0a potential solution
=C2=A0 =C2=A0 =C2= =A0 =C2=A0
Could you provide input regarding the following:
=
1) Based on Jim's suggestion I added a statement that says:
<= div>=C2=A0The AS MAY include the thumbprint of the RS's X.509 certifica= te in the 'rs_cnf'
(thumbprint as defined in <xref tar= get=3D"I-D.ietf-cose-x509"></xref>),
=C2=A0then the c= lient MUST validate the RS certificate against this thumbprint.
I= s this implemented by=C2=A0rs_cnf =3D x5t=C2=A0

and then the client computes t= he hash and checks against x5t?


Regarding other q= uestions raised by Jim on OASIS certificate guidelines and the mqtt/mqtt(s)= , I have not managed to get more information than:

  1. there is n= o official UIR scheme but there is a community wiki entry which proposes so= mething:=C2=A0https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme. The MQTT 5 = server redirection feature uses a very simple way of indicating a server re= ference, see=C2=A0https://docs.oasis-op= en.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Server_redirection

  2. There's currently no certificate validation d= ocument. The recommendations linked in the spec can be found here:=C2=A0https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/= mqtt-v5.0-os.html#_Toc3901280.

2) I tempo= rarily added the exporter label to our draft but will wait on the final dec= ision on that.=C2=A0
So, if it is def= ined and registered in another document, I can refer to it.=C2=A0

I will = push changes as 03 once there is an agreement on how to resolve these issue= s.=C2=A0

<= font color=3D"#000000" face=3D"sans-serif">Kind regards,=C2=A0
--Cigdem= =C2=A0
--0000000000004e47970599f84de4-- From nobody Wed Dec 18 05:27:08 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA9C12003E; Wed, 18 Dec 2019 05:27:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> Date: Wed, 18 Dec 2019 05:27:06 -0800 Archived-At: Subject: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 13:27:06 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this well written document. I have a couple of small DISCUSS points and a few minor comments/questions that I would like to discuss. DISCUSS: 5.4. Message Bindings o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- Format, Block1, Block2, and Accept. These CoAP Options are used to communicate the HTTP fields specified in the EST REST messages. The Uri-host and Uri-Port Options can be omitted from the COAP message sent on the wire. The statement above When omitted, they are logically assumed to be the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. and the last quoted statement: How can the sender know whether or not it is Ok to omit Uri-Host/Uri-Port? 7. Parameters It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). However, depending on the implementation scenario, retransmissions and timeouts can also occur on other networking layers, governed by other configuration parameters. When a change in a server parameter has taken place, the parameter values in the communicating endpoints MUST be adjusted as necessary. The last sentence: use of MUST with passive voice is really unhelpful here. Adjusted by whom? How can this MUST be satisfied? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Comment: 5.1. Discovery and URIs Clients and servers MUST support the short resource EST-coaps URIs. Just to clarify: the original EST URIs are prohibited in COAP-EST? In 5.8: In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client-defined (in the CSR) I would break up this sentence into 2 to make it clearer, as I initially read this as 2 encryption operations applying to the generated private key itself. So I suggest something like: In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key. The symmetric key itself is encrypted by the client-defined (in the CSR) asymmetric public key and is carried in an encryptedKey attribute in a KeyTransRecipientInfo structure. Finally, if the asymmetric encryption key is suitable for key agreement, the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. As above. From nobody Wed Dec 18 07:20:33 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB6E12024E; Wed, 18 Dec 2019 07:20:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157668242792.29895.8196611486116290525@ietfa.amsl.com> Date: Wed, 18 Dec 2019 07:20:28 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 15:20:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) Authors : Stefanie Gerdes Olaf Bergmann Carsten Bormann Göran Selander Ludwig Seitz Filename : draft-ietf-ace-dtls-authorize-09.txt Pages : 21 Date : 2019-12-18 Abstract: This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-09 https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-dtls-authorize-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 18 07:23:03 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3505A12026E for ; Wed, 18 Dec 2019 07:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rlX48JAQCz1r for ; Wed, 18 Dec 2019 07:23:00 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90616120241 for ; Wed, 18 Dec 2019 07:23:00 -0800 (PST) Received: from wangari.tzi.org (eduroam-pool13-1615.wlan.uni-bremen.de [134.102.166.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47dJfq2Vxdzycv for ; Wed, 18 Dec 2019 16:22:59 +0100 (CET) From: Olaf Bergmann To: ace@ietf.org References: <157668242792.29895.8196611486116290525@ietfa.amsl.com> Date: Wed, 18 Dec 2019 16:22:59 +0100 In-Reply-To: <157668242792.29895.8196611486116290525@ietfa.amsl.com> (internet-drafts's message of "Wed, 18 Dec 2019 07:20:28 -0800") Message-ID: <87eex1slnw.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-09.txt X-BeenThere: ace@ietf.org 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: Wed, 18 Dec 2019 15:23:02 -0000 Dear ACE mailing list, We uploaded a new version of the DTLS profile for ACE. The only change is an update of one of the authors' affiliation. internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Authentication and Authorization for Con= strained Environments WG of the IETF. > > Title : Datagram Transport Layer Security (DTLS) Profil= e for Authentication and Authorization for Constrained Environments (ACE) > Authors : Stefanie Gerdes > Olaf Bergmann > Carsten Bormann > G=C3=B6ran Selander > Ludwig Seitz > Filename : draft-ietf-ace-dtls-authorize-09.txt > Pages : 21 > Date : 2019-12-18 Gr=C3=BC=C3=9Fe Olaf From nobody Wed Dec 18 07:47:22 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E8912025D for ; Wed, 18 Dec 2019 07:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0wwA41L3egRB for ; Wed, 18 Dec 2019 07:47:16 -0800 (PST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 6704E1201A3 for ; Wed, 18 Dec 2019 07:47:16 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id n8so909391qvg.11 for ; Wed, 18 Dec 2019 07:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jvPG8L/HFvtmoHePzWeJ3RL6+0fUfhRdCRc0wfnnvV4=; b=tzgtrnAq8hMUc4tr374nWv8tCqm1Dk4z1TPXrRhj4cV3J1AcSW+BlSrbPzS/Qewc1+ 1YdOloX/G1vEKRx3+RecX1HPaIsvGXOdXELdm9pzR41oMlEodxePZKUdZmVj/rrLVboW j6rBfjEX9VsgJFW4oaPvYxcDRDwhnneFUYcC9fUic1c6EagxWR+bWI3a72U5SAmUE+im u837fjPSJIcY9u1pjPOviODNO7AwYPjeYUxha1joHdFontrB2RgMxs9t+iXlndvnZmob EId9AilAL4oN86FIKxgQBJqTMGvOHAZOtXGagLGmksFOpfskdfyUKnqI24ImAweGSX5c /9jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jvPG8L/HFvtmoHePzWeJ3RL6+0fUfhRdCRc0wfnnvV4=; b=aes40ZWhDUCZvHzUXg/xSV1kUk54G8DD/AiMISL2fDL7CE5ixXsKM/OCusFyPw0luz Zm0fRJ9Q2T11a8FLhNUOU/T28q5/yUYsZggRwjO3vasSP/bxtnerp5efa7k1jP1QjnIV stVqyjIAcKJNAUZ+OxpQGgKmWHkBUrDfB3HAg12RVVRNWC7zntw/A+xTQdVJEwfnfwaS /s0B/X+HdYnZSERA6/rdUqhUxQIO3zWHLwQ6yxdlgwYg9VRNJN1M7eEM3aPuiFmVwlma FSuP7xWzJip/v1EapZtG1kHq1tvUqK0JePDS4rOUibRoGgSfo1fjwZuFw7nNbb3vdQoT iItQ== X-Gm-Message-State: APjAAAWCJkRxS1NVfGtKdVoykE6KwiESIMIUL4Q6tZnmmZ667pZkPfNM ooi5B2mkTuT0XhR93f9hbWnYWV/PkascPAr+9is= X-Google-Smtp-Source: APXvYqzJYDqT0uup73LVbCuaJMq/rlhSd6pyrR4ia2/1mcPj/Tw6hOcI4nZ00x9qWOLAAfcPeQs3oaUe0C++Vp+2S48= X-Received: by 2002:ad4:40cb:: with SMTP id x11mr2868603qvp.167.1576684035425; Wed, 18 Dec 2019 07:47:15 -0800 (PST) MIME-Version: 1.0 References: <75220EAA-9455-4691-9E99-3E16401D1309@ericsson.com> In-Reply-To: <75220EAA-9455-4691-9E99-3E16401D1309@ericsson.com> From: Cigdem Sengul Date: Wed, 18 Dec 2019 15:47:04 +0000 Message-ID: To: Francesca Palombini Cc: Ace Wg Content-Type: multipart/alternative; boundary="000000000000dad55c0599fc5be1" Archived-At: Subject: Re: [Ace] Review for draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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: Wed, 18 Dec 2019 15:47:20 -0000 --000000000000dad55c0599fc5be1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Francesca, Thank you for your responses to my comments. My comments are inline. > > > In the following, I list a few things reading the draft made me think, > especially in its applicability to MQTT: > > (1) What is planned to make this document a generic pubsub solution? Will > there a generic architecture section, and specific descriptions for each = of > the protocols? > > > > FP: Yes, I am planning to make some updates to the text to make this > generic. In general, I think the structure of the draft will be the same, > but each section would either have a sentence or (if longer text is neede= d) > a subsection talking about the different alternatives. For example, Secti= on > 2 would remove current specific text about CoAP pubsub (only talk about > general pubsub) and would replace that text with an additional paragraph > mentioning that the pubsub protocol can be CoAP or MQTT. Section 3 would > have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, etc. > > > CS: YEs, sounds good. > For instance, if an MQTT client implements this, the client would talk t= o > AS1 to get a token based on the way we describe in the mqtt-tls profile, > and then get keying material for topics from AS2. > > I expect the MQTT client would use a different profile name like > mqtt_tls_app to signal to AS1 that it is supporting the application layer > security. This is because the draft hints that there should be a policy > agreement between AS1 and AS2: =E2=80=9CNote that AS1 and AS2 might eithe= r be > co-resident or be 2 separate physical entities, in which case access > control policies must be exchanged between AS1 and AS2, so that they agre= e > on rights fo joining nodes about specific topics.=E2=80=9D > > > > FP: That is all correct. Moreover, we can also discuss details such as > what communication protocol the Client uses to talk to AS2. Right now > ace-key-groupcomm is only defined for CoAP, but if MQTT prefers to use > HTTP, that is very easy to define. > > > > > (2) If we keep AS1 as the mqtt-tls profile AS, then for consistency sake, > the MQTT client would expect to talk to HTTPS to AS2, but the coap-pubsub > draft describes these, expectedly, in CoAP. Will there be support for HTT= PS? > > > > FP: I promise I did not read this question before answering the text abov= e > :) Yes. This is really easy to specify, we already do this with CBOR/JSON= , > in ace-key-groupcomm: > > > > The ACE framework is based > > on CBOR [RFC7049], so CBOR is the format used in this specification. > > However, using JSON [RFC8259] instead of CBOR is possible, using the > > conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. > > > > We would add CoAP/HTTP in the same way ("CoAP is default, but HTTP works > the same way"). Then the pubsub-profile could specify which protocol is > used in the different profiles. > CS: Cool. Because, I imagine a client or its AS would follow the same protocol, HTTPS, to talk to the ASes, and then talk to MQTT to RS. > (3) In the mqtt_tls profile, the AS grants tokens that identify both > =E2=80=9Cpublish=E2=80=9D and =E2=80=9Csubscribe=E2=80=9D rights and the = topics by adding scopes in the > format, e.g. =E2=80=9Cpublish_topic1=E2=80=9D =E2=80=9Csubscribe_topic2/#= =E2=80=9D.. This format allows > representing all publish/subscribe permissions concisely for the client > which may be acting both as a publisher and a subscriber. > > In the coap-pubsub, this is separated between AS1 and AS2. =E2=80=9CAS1 h= osts the > policies about the Broker: what endpoints are allowed to Publish on the > Broker.=E2=80=9D =E2=80=9CThe AS2 hosts the policies about the topic: wha= t endpoints are > allowed to access what topic. =E2=80=9C > > The coap-pubsub also permits that AS1 can host policies about what > endpoints are allowed to Subscribe to the Broker. > > > > However, wouldn=E2=80=99t this separation between AS1 and AS2 have the fo= llowing > issue: Publisher P, having the permission to publish to topic1 and hence, > successfully getting an access token from AS1, then goes ahead and sends = a > PUBLISH on topic 2, which it doesn=E2=80=99t have a right to publish. > > Wouldn't the broker would pass this message to subscribers, and the > subscribers would discard the message because the publisher does not belo= ng > to their =E2=80=9Cpublishers list=E2=80=9D (subscribers have all the publ= ic keys of all > publishers). Have I missed something, does the draft protect against this > at the broker? > > > > FP: No, the broker would not accept this message. In fact, during the ACE > exchange between Publisher, AS1, and Broker, the Publisher would post a > token to the Broker that contains the resource it is allowed to publish t= o, > namely in this case topic 1. If it does have rights to publish to topic 2 > as well, that would be included in the token. That is covered by the > transport profile used, as you mentioned (MQTTL-TLS/CoAP OSCORE). > Orthogonally to this, when getting the keys from AS2 to protect the > publication, if the Publisher has tried to publish to topic 2 without > having the correct content encryption keying material, the decryption of > the publication at the subscriber would fail even before signature > verification. But the Subscriber would not get the publication if the > Publisher is not authorized to publish on that topic. Note that if the > owner wants to protect topic 1 and topic 2 with the same keying material, > that is possible, but then the case above would not be an attack but an > acceptable scenario (Publisher allowed to post to both topics, publicatio= n > protected with the same key). > CS: OK, it wasn't clear to me what the scope of the token for the publish permission the Publisher P got from the AS1. It read as it got a token that just said Publish, without constraining the resource. Your explanation now clarifies this, and maybe it should be put in the text as well how publish tokens are scoped. > Differently, with the current way mqtt_tls scopes are described, AS1 woul= d > need to know not only who can publish or subscribe, but also the policies > on topics. > > > > FP: By policies on AS1 I mean exactly that: "what endpoints are allowed t= o > publish on what topics". If one wants to control who can subscribe, that > would also be part of the so-called policies. > CS: Yes, this is more clear now. > > > (4) That brings me to another point regarding this note in coap-pubsub > profile. The profile says: =E2=80=9CHow the policies are exchanged [betwe= en AS1 and > AS2] is out of scope for this specification.=E2=80=9D I wonder whether th= e token > the client gets from AS1 should also be usable towards AS2, and AS2 is > replaced with an RS for retrieving the keying material for topics (more o= n > this later), i.e., AS2 does not need to host/manage/coordinate policies > with AS1. > > > > FP: That is a possibility. Right now this is not the case because I > thought it would be better to keep the two ("authorization to publish on > one or more topics on Broker" and "authorization to get encryption keys f= or > one or more topics") independent. The reason for that was that the same k= ey > could be used for several topics, i.e. Publisher P could be allowed to > publish on topic 1 but not on topic 2, even though topic 1 and 2 use the > same encryption key. Yes, that could be a way to do it, but I am not sure > about the advantage, apart from the obvious policies synchronization (i.e= . > in this way there would be no need for synchronizing since in practice AS= 1 > would know both what topic Publisher P can publish to and what content > encryption key it can retrieve). But I'd be happy to discuss that further= . > CS: I could not understand the reason for two ASes: "Publisher P could be allowed to publish on topic 1 but not on topic 2, even though topic 1 and 2 use the same encryption key." In my head, AS1 would grant a token that would tell Client C what publish/subscribe permissions they have. Client C submits the token to AS2, which returns the encryption keys for these topics. Client C submits the token to RS, which checks what publish/subscribe permissions the Client has - it would not allow client C to publish to topic 2, if it doesn't have permission. But client C can subscribe (if the token says it can) to topic 2 and use the same encryption key as topic 1 to read the messages. A JWT/CWT can have multiple audiences as an array, so the token can be used for both. To me, the advantage of not having to synchronise policies in two different ASes would be considerable. > > > In MQTT token scopes, we also accepted that a publisher represents its > PUBLISH rights with topic filters (note a PUBLISH message cannot be sent = to > a filter, but the topic filters are useful in summarising permissions). > > Let=E2=80=99s assume there is a publisher with scope > =E2=80=9Cpublish_sport/tennis/+/rankings=E2=80=9C? > > > > FP: The first question I have is if it is even possible to indicate scope > like this in ACE. I do not think so (and please correct me if I am wrong)= , > and in this case the scope would have to be expressed as the union of the > following URIs: publish_sport/tennis/player1/rankings and > publish_sport/tennis/player2/rankings > CS: This is possible in the mqtt_tls profile because MQTT accepts topic filters. And, we defined our scopes such as publish_topic1/# subscribe_+/topic2 etc. > > Then being a part of all groups (player 1 and player2) is too general as > this publisher cannot publish to everything but only to =E2=80=9Crankings= =E2=80=9D. > > > > FP: But once the scope is expressed for "rankings" only, then the doc > should cover this case too. Then it is up to the topic owner (and reflect= ed > on the AS2) to decide if the keying material is the same for rankings and > for the upper-topics (? as opposed to sub-topic) player1 and player2. And > similarly, it will be up to the broker to verify that the authorization f= or > publishing to rankings is separate from publishing to player1 and player2= . > It is also a valid case to make it so sub-topics inherit authorizations, > but that would be up to the application to decide. Anyway, these are all > valid considerations that need to be made in the document. > CS: I see that I wasn't clear in my thinking before and mixed up things. I was trying to understand how groups map to topics and the topic hierarchy; and how group maintenance scales with the increasing number of topics, publisher and subscribers. Said another way, who creates groups, and creates/updates keys for these groups to be maintained in the KDC? I agree topic hierarchies require more thought. Here is my second attempt at explaining my thinking, which is by no means complete: In MQTT, it is possible to publish to all levels in a topic hierarchy e.g., if you have sport/tennis/player1/rankings, it is possible to publish to the sport, sport/tennis, sport/player1, sport/player1/rankings... One option is to have as many keys as the nodes on the hierarchy independent of actual publishers and subscribers to them. (Assuming this hierarchy is pre-built, and AS2 maintains a complete topic-key database). So, if publisher P1 comes with rights to publish to sport/tennis - he gets the keys for that. But, if he comes with the right to publish to sport/tennis/#, he gets multiple keys, one each for every node under tennis. The other option is creating groups dynamically and subtopics inherit authorisations (as captured by the wildcards), i.e., publisher and subscribers that have an exact match in their topic filters form a group. Going back to the previous example, assuming AS2 is generating the keys (need to read the groupcomm in detail to understand how the KDC and its endpoints work in general), I imagine something like this may work: Publisher P1 - publish_sport/tennis/# -> AS2 checks if a matching group exists, doesn't find one, generates the key, and hands it out to P1, stores the mapping. Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching group exists, find one, gives out the key to P2. Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching group exists, find one, gives out the key to S1. Until now, assumed no rekeying when the new members join an existing group, as this would work well with MQTT RETAIN option, which enables the publisher to indicate to the Broker that it should store the most recent message for the associated topic. Hence, the new subscribers can receive the last sent message from the publisher of that particular topic without waiting for the next PUBLISH message. Subscriber S2 - publish_sport/tennis/+/rankings - AS2 checks if a matching group exists, does not find an exact match -> generates new key, but then needs to update P1, P2, S1 as well as publish_sport/tennis/+/rankings will be sent encrypted with the new key, and the rest will be with the old key. When they are rekeyed, the publishers may send RETAINED messages again with the new key. i.e., P1-P2-S1 are one group P1-P2-S1-S2 would be another group Two groups - two keys. Do not know what is best, or there is a third option. Another thing to consider would be rekeying policies of course. > > Another approach could be each publisher creating its group. This way the > number of groups scales with the number of publishers (and the COSE keys = is > per publisher). > > > > FP: I don't think this scales well, but yes, an application could also do > this. > CS: Yes, scratch that - that actually wouldn't work. Thanks, --Cigdem > > > Kind regards, > > --Cigdem > --000000000000dad55c0599fc5be1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Francesca,=C2=A0

=
Thank you for your responses to my comments.=C2=A0
My commen= ts are inline.=C2=A0

=C2=A0

In the following, I list a few things reading the dr= aft made me think, especially in its applicability to MQTT:

(1) What is planned to make this document a generic = pubsub solution? Will there a generic architecture section, and specific de= scriptions for each of the protocols?=C2=A0

=C2=A0

FP: Yes, I am planning to make some updates to the t= ext to make this generic. In general, I think the structure of the draft wi= ll be the same, but each section would either have a sentence or (if longer= text is needed) a subsection talking about the different alternatives. For example, Section 2 would remove curr= ent specific text about CoAP pubsub (only talk about general pubsub) and wo= uld replace that text with an additional paragraph mentioning that the pubs= ub protocol can be CoAP or MQTT. Section 3 would have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, e= tc.

=C2=A0


<= /div>
CS: YEs, sounds good.=C2=A0
=C2=A0

For instance, if an MQTT client implements this,=C2= =A0 the client would talk to AS1 to get a token based on the way we describ= e in the mqtt-tls profile, and then get keying material for topics from AS2= .=C2=A0

I expect the MQTT client would use a different profi= le name like mqtt_tls_app to signal to AS1 that it is supporting the applic= ation layer security. This is because the draft hints that there should be = a policy agreement between AS1 and AS2: =E2=80=9CNote that AS1 and AS2 might either be co-resident or be 2 se= parate physical entities, in which case access control policies must be exc= hanged between AS1 and AS2, so that they agree on rights fo=C2=A0 joining n= odes about specific topics.=E2=80=9D

=C2=A0

FP: That is all correct. Moreover, we can also discu= ss details such as what communication protocol the Client uses to talk to A= S2. Right now ace-key-groupcomm is only defined for CoAP, but if MQTT prefe= rs to use HTTP, that is very easy to define.


=C2=A0<= /p>

(2) If we keep AS1 as the mqtt-tls profile AS, then = for consistency sake, the MQTT client would expect to talk to HTTPS to AS2,= but the coap-pubsub draft describes these, expectedly, in CoAP. Will there= be support for HTTPS?

=C2=A0

FP: I promise I did not read this question before an= swering the text above :) Yes. This is really easy to specify, we already d= o this with CBOR/JSON, in ace-key-groupcomm:

=C2=A0

The ACE framework is based

=C2=A0=C2=A0 on CBOR [RFC7049], so CBOR is the forma= t used in this specification.

=C2=A0=C2=A0 However, using JSON [RFC8259] instead o= f CBOR is possible, using the

=C2=A0=C2=A0 conversion method specified in Sections= 4.1 and 4.2 of [RFC7049].

=C2=A0

We would add CoAP/HTTP in the same way ("CoAP i= s default, but HTTP works the same way"). Then the pubsub-profile coul= d specify which protocol is used in the different profiles.

=

CS:=C2=A0Cool. Because, I imagine a client= or its AS would follow the same protocol, HTTPS,=C2=A0 to talk to the ASes= , and then talk to MQTT to RS.=C2=A0
=C2=A0=C2=A0

(3) In the mqtt_tls profile, the AS grants tokens th= at identify both =E2=80=9Cpublish=E2=80=9D and =E2=80=9Csubscribe=E2=80=9D = rights and the topics by adding scopes in the format, e.g. =E2=80=9Cpublish= _topic1=E2=80=9D =E2=80=9Csubscribe_topic2/#=E2=80=9D..=C2=A0 This format a= llows representing all publish/subscribe permissions concisely for the client which may be acting both as a publish= er and a subscriber.

In the coap-pubsub, this is separated between AS1 an= d AS2. =E2=80=9CAS1 hosts the policies about the Broker: what endpoints are= allowed to Publish on the Broker.=E2=80=9D =E2=80=9CThe AS2 hosts the poli= cies about the topic: what endpoints are allowed to access what topic. =E2=80=9C

The coap-pubsub also permits that AS1 can host polic= ies about what endpoints are allowed to Subscribe to the Broker.<= /u>

=C2=A0

However, wouldn=E2=80=99t this separation between AS= 1 and AS2 have the following issue: Publisher P, having the permission to p= ublish to topic1 and hence, successfully getting an access token from AS1, = then goes ahead and sends a PUBLISH on topic 2, which it doesn=E2=80=99t have a right to publish.

Wouldn't the broker would pass this message to s= ubscribers, and the subscribers would discard the message because the publi= sher does not belong to their =E2=80=9Cpublishers list=E2=80=9D (subscriber= s have all the public keys of all publishers). Have I missed something, does the draft protect against this at the broker?

=C2=A0

FP: No, the broker would not accept this message. In= fact, during the ACE exchange between Publisher, AS1, and Broker, the Publ= isher would post a token to the Broker that contains the resource it is all= owed to publish to, namely in this case topic 1. If it does have rights to publish to topic 2 as well, that w= ould be included in the token. That is covered by the transport profile use= d, as you mentioned (MQTTL-TLS/CoAP OSCORE). Orthogonally to this, when get= ting the keys from AS2 to protect the publication, if the Publisher has tried to publish to topic 2 without = having the correct content encryption keying material, the decryption of th= e publication at the subscriber would fail even before signature verificati= on. But the Subscriber would not get the publication if the Publisher is not authorized to publish on that = topic. Note that if the owner wants to protect topic 1 and topic 2 with the= same keying material, that is possible, but then the case above would not = be an attack but an acceptable scenario (Publisher allowed to post to both topics, publication protected with the = same key).


CS: OK, it wasn&= #39;t clear to me what the scope of the token for the publish permission th= e Publisher P got from the AS1. It read as it got a token that just said Pu= blish, without constraining the resource. Your explanation now clarifies th= is, and maybe it should be put in the text as well how publish tokens are s= coped.=C2=A0

=C2=A0=C2=A0

Differently, with the current way mqtt_tls scopes ar= e described, AS1 would need to know not only who can publish or subscribe, = but also the policies on topics.

=C2=A0

FP: By policies on AS1 I mean exactly that: "wh= at endpoints are allowed to publish on what topics". If one wants to c= ontrol who can subscribe, that would also be part of the so-called policies= .


CS: Yes, this is more cle= ar now.=C2=A0
=C2=A0

=C2=A0

(4) That brings me to another point regarding this n= ote in coap-pubsub profile. The profile says: =E2=80=9CHow the policies are= exchanged [between AS1 and AS2] is out of scope for this specification.=E2= =80=9D I wonder whether the token the client gets from AS1 should also be usable towards AS2, and AS2 is replaced with an RS= for retrieving the keying material for topics (more on this later), i.e., = AS2 does not need to host/manage/coordinate policies with AS1.

=C2=A0

FP: That is a possibility. Right now this is not the= case because I thought it would be better to keep the two ("authoriza= tion to publish on one or more topics on Broker" and "authorizati= on to get encryption keys for one or more topics") independent. The reason for that was that the same key could be used for s= everal topics, i.e. Publisher P could be allowed to publish on topic 1 but = not on topic 2, even though topic 1 and 2 use the same encryption key. Yes,= that could be a way to do it, but I am not sure about the advantage, apart from the obvious policies synchro= nization (i.e. in this way there would be no need for synchronizing since i= n practice AS1 would know both what topic Publisher P can publish to and wh= at content encryption key it can retrieve). But I'd be happy to discuss that further.



CS: I could not understand th= e reason for two ASes: "Publisher P could be allowed to publish on top= ic 1 but not on topic 2, even though topic 1 and 2 use the same encryption = key."
In my head, AS1 would grant a token that would tell Cl= ient C what publish/subscribe permissions they have.=C2=A0
Cl= ient C submits the token to AS2, which returns the encryption keys for thes= e topics.=C2=A0
Client C submits the token to RS, which checks wh= at publish/subscribe permissions the Client has - it would not allow client= C to publish to topic 2, if it doesn't have permission.=C2=A0
But client C can subscribe (if the token says it can) to topic 2 and use = the same encryption key as topic 1 to read the messages.=C2=A0
A JWT/CWT can have multiple audiences as an array, so the toke= n can be used for both.=C2=A0
To me,=C2=A0 the advantage of not h= aving to synchronise policies in two different ASes would be considerable.<= /div>
=

=C2=A0

In MQTT token scopes, we also accepted that a publis= her represents its PUBLISH rights with topic filters (note a PUBLISH messag= e cannot be sent to a filter, but the topic filters are useful in summarisi= ng permissions).

Let=E2=80=99s assume there is a publisher with scope= =E2=80=9Cpublish_sport/tennis/+/rankings=E2=80=9C?

=C2=A0

FP: The first question I have is if it is even possi= ble to indicate scope like this in ACE. I do not think so (and please corre= ct me if I am wrong), and in this case the scope would have to be expressed= as the union of the following URIs: publish_sport/tennis/player1/rankings and publish_sport/tennis/player2/ran= kings


CS: This is possible = in the mqtt_tls profile because MQTT accepts topic filters. And, we defined= our scopes such as publish_topic1/#=C2=A0 subscribe_+/topic2 etc.=C2=A0

=C2=A0

Then being a part of all groups (player 1 and player= 2) is too general as this publisher cannot publish to everything but only t= o =E2=80=9Crankings=E2=80=9D.

=C2=A0

FP: But once the scope is expressed for "rankin= gs" only, then the doc should cover this case too. Then it is up to th= e topic owner (and reflected on the AS2) to decide if the keying material i= s the same for rankings and for the upper-topics (? as opposed to sub-topic) player1 and player2. And similarly, it will be= up to the broker to verify that the authorization for publishing to rankin= gs is separate from publishing to player1 and player2. It is also a valid c= ase to make it so sub-topics inherit authorizations, but that would be up to the application to decide. Anyway,= these are all valid considerations that need to be made in the document.


CS: I see that I wasn't = clear in my thinking before and mixed up things. I was trying to understand= how groups map to topics and the topic hierarchy;=C2=A0 and how group main= tenance scales with the increasing number of topics, publisher and subscrib= ers. Said another way, who creates groups, and creates/updates keys for the= se groups to be maintained in the KDC?

I agree top= ic hierarchies require more thought. Here is my second attempt at explainin= g my thinking, which is by no means complete:
In MQTT, it is poss= ible to publish to all levels in a topic hierarchy e.g., if you have sport/= tennis/player1/rankings, it is possible to publish to the sport, sport/tenn= is, sport/player1, sport/player1/rankings...=C2=A0
One option is = to have as many keys as the nodes on the hierarchy independent of actual pu= blishers and subscribers to them.=C2=A0 (Assuming this hierarchy is pre-bui= lt, and AS2 maintains a complete topic-key database).=C2=A0
So, i= f publisher P1 comes with rights to publish to sport/tennis - he gets the k= eys for that. But, if he comes with the right to publish to sport/tennis/#,= he gets multiple keys, one each for every node under tennis.=C2=A0

The other option is creating groups dynamically and subto= pics inherit authorisations (as captured by the wildcards), i.e., publisher= and subscribers that have an exact match in their topic filters form a gro= up.=C2=A0
Going back to the previous example, assuming AS2 is gen= erating the keys (need to read the groupcomm in detail to understand how th= e KDC and its endpoints work in general), I imagine something like this may= work:
Publisher P1 - publish_sport/tennis/#=C2=A0 -> AS2 chec= ks if a matching group exists, doesn't find one, generates the key, and= hands it out to P1, stores the mapping.=C2=A0
Publisher P2 - pub= lish_sport/tennis/# -> AS2 checks if a matching group exists, find one, = gives out the key to P2.=C2=A0
Subscriber S1 - publish_sport/tenn= is/# -> AS2 checks if a matching group exists, find one, gives out the k= ey to S1. Until now, assumed no rekeying when the new members join an exist= ing group, as this would work well with MQTT RETAIN option, which enables <= span style=3D"font-family:"Helvetica Neue";font-size:12px">the=C2= =A0publisher to indicate to=C2=A0the=C2=A0Broker=C2=A0that=C2=A0it=C2=A0sho= uld=C2=A0store=C2=A0the=C2=A0most=C2=A0recent=C2=A0message=C2=A0for=C2=A0= the=C2=A0associated=C2=A0topic.=C2=A0=C2=A0Hence,=C2=A0the=C2=A0new=C2=A0su= bscribers=C2=A0can=C2=A0receive=C2=A0the=C2=A0last=C2=A0sent=C2=A0message= =C2=A0from=C2=A0the=C2=A0publisher=C2=A0of=C2=A0that=C2=A0particular=C2=A0t= opic=C2=A0without=C2=A0waiting=C2=A0for=C2=A0the=C2=A0next=C2=A0PUBLISH= =C2=A0message.
Subscriber S2 - publish_sport/tennis/+/rank= ings - AS2 checks if a matching group exists, does not find an exact match = -> generates new key, but then needs to update P1, P2, S1 as well as pub= lish_sport/tennis/+/rankings will be sent encrypted with the new key, and t= he rest will be with the old key. When they are rekeyed, the publishers may= send RETAINED messages again with the new key.=C2=A0

<= div>i.e.,=C2=A0
P1-P2-S1 are one group
P1-P2-S1-S2 woul= d be another group
Two groups - two keys.=C2=A0

Do not know what is best, or there is a third option.=C2=A0

Another thing to consider would be rekeying policies of c= ourse.=C2=A0

=C2=A0

Another approach could be each publisher creating it= s group. This way the number of groups scales with the number of publishers= (and the COSE keys is per publisher).

=C2=A0

FP: I don't think this scales well, but yes, an = application could also do this.


=
CS: Yes, scratch that - that actually wouldn't work.=C2=A0

Thanks,
--Cigdem=C2=A0=C2=A0

=C2=A0

=C2=A0

Kind regards,

--Cigdem

--000000000000dad55c0599fc5be1-- From nobody Wed Dec 18 15:07:26 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555E9120047 for ; Wed, 18 Dec 2019 15:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MEfg46fa8Agi for ; Wed, 18 Dec 2019 15:07:23 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 56E5A120013 for ; Wed, 18 Dec 2019 15:07:23 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id f7so1277971uaa.8 for ; Wed, 18 Dec 2019 15:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iDLk3JS4x6QMhozZYtbaU50k3Wg5ueIuZCVgayY8oqY=; b=kRwFfsu2YPgKVny+XF2HETXxUpwM9/09vxqgQb7hcyfG/dCt+CeheIiQ5pfuqecAqP r5iWe8R7X1Wvr0trckL3y+Ie7HmLGBAW4lTLP/5KFU7k7+KPooVSdxx3AmaWqGdOs5Kz YQNohCtIYaMToGj/k5pGU9wUjoPMMMtR4A6+HN7VmmKqvPpNPSNrxaSjvKMfhLpRtn5t RB2q9B1HpUAaqJcxSvFUaikVrX0Gfx2imakscAE0cBQSMRpQ1kgG5X3mu1n/Y6fsXlFn PnBI2lds5ppHK/H5yATgoqG4TXfr2NCtWQFY81tLg5f9FRtsFrHCPNaVNN+SdGIt+oWR gDgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iDLk3JS4x6QMhozZYtbaU50k3Wg5ueIuZCVgayY8oqY=; b=ruIQqqevyRNiIeO6IvKe+WK949obu5i8yKKy6368RjFcRUXFUl8RFizoMlDELVLkNb zIuLNwPTjWZzphAn9vYiXDhKnPnGdzGsBE9YzhIL4XWjsAVLyB/9PvraIckZYGi3/6FK Fcb5qYhaEWVOKNYfNelvyF2EyLKpNhbRgIjMCN3u59Rhhj1Lm3TZdLB64fBN22a+Gdnx /U98V08Xu3hAjkVHOH0O2sTE2SDvFLR6H1ZJtLeK6nMRVCuYKz97NZDmbDWdYIzRI9Mr ECC+h5YOSXSx/cKDz+g60pY9Z9iAoYDSXpMDSi/2DZ8q8y9lkzjdpArLLfV7Im+l5zgH ykjA== X-Gm-Message-State: APjAAAUrYbJFRhwDvj20rKQGLHHbuwMBXYjQllotRbOgPE8dKShoPSKm 7L10yOeRbMwzUoUjQ1zMtCOAuBlUvVowmQLDl/aYCw== X-Google-Smtp-Source: APXvYqypoLugDCg97JfSgt5wzmE8V3m8afja9x87a00HnCkZoYoxKLc7lrZUsvbWF095r1Ie/WRQCTPjMETXbjL+qlI= X-Received: by 2002:a9f:2e03:: with SMTP id t3mr3290317uaj.119.1576710442186; Wed, 18 Dec 2019 15:07:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Wed, 18 Dec 2019 18:07:11 -0500 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="000000000000d1fc5f059a0281cd" Archived-At: Subject: [Ace] ACE January interim meeting X-BeenThere: ace@ietf.org 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: Wed, 18 Dec 2019 23:07:25 -0000 --000000000000d1fc5f059a0281cd Content-Type: text/plain; charset="UTF-8" Hi, We are planning a Virtual Interim meeting the last week of January and invite you to select the most convenient dates and hours by December 24 on the link below. https://doodle.com/poll/mf6emhfevqhrt38s Hours have been selected according to [1]. The expected agenda is: * draft-ietf-ace-key-groupcomm * draft-ietf-ace-key-groupcomm-oscore * draft-ietf-ace-mqtt-tls-profile * draft-palombini-ace-coap-pubsub-profile We expect the draft to integrate the comments received during the IETF106 meeting being published by Jan 15, so the WG has time to review these before the meeting. Yours, Jim and Daniel [1] https://www.timeanddate.com/worldclock/meetingtime.html?iso=20190125&p1=165&p2=239&p3=234&p4=136 -- Daniel Migault Ericsson --000000000000d1fc5f059a0281cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0=

We are planning a Virtual Interim meeting the= last week of January and invite you to select the most convenient dates an= d hours by December 24 on the link below.

Hours have been selected accordi= ng to [1]. The expected agenda is:
* draft-ietf-ace-key-groupcomm=
* draft-ietf-ace-key-groupcomm-oscore
* draft-ietf-ace-mqtt-tls-prof= ile
* draft-palombini-ace-coap-pubsub-profile

We expect the draft to integrate the comments received during the IETF10= 6 meeting being published by Jan 15, so the WG has time to review these bef= ore the meeting.=C2=A0

Yours,=C2=A0
Jim and Dan= iel


=C2=A0=C2=A0
--=
Daniel Migault
Ericsson
--000000000000d1fc5f059a0281cd-- From nobody Thu Dec 19 04:53:40 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13E12006D; Thu, 19 Dec 2019 04:53:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2019 04:53:38 -0800 Archived-At: Subject: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 12:53:39 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 5.6: The EST-coaps client MUST support Block1 only if it sends EST-coaps requests with an IP packet size that exceeds the Path MTU. I think the requirement for when Block1 is required to be supported in the above sentence is unclear. Is the intention to say: An EST-coaps MUST support block1 to be capable to send requests that would otherwise result in the reliance on IP level fragmentation? From nobody Thu Dec 19 12:24:07 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E50120A96; Thu, 19 Dec 2019 12:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VEWIVCR6hzfa; Thu, 19 Dec 2019 12:23:57 -0800 (PST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36561200C7; Thu, 19 Dec 2019 12:23:56 -0800 (PST) Received: from b.5.0.b.9.9.3.9.b.1.d.6.2.3.5.5.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:5532:6d1b:9399:b05b]) by b-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ii2Kx-0000RA-1P; Thu, 19 Dec 2019 20:23:55 +0000 SavedFromEmail: elwynd@folly.org.uk Date: Thu, 19 Dec 2019 20:23:50 +0000 In-Reply-To: <6da3360a-157e-e3cf-d1ea-109d8515da42@gmx.de> Importance: normal From: elwynd To: Ludwig Seitz , elwynd@dial.pipex.com Cc: last-call@ietf.org, gen-art@ietf.org, ace@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_3746339897489100" Message-ID: Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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: Thu, 19 Dec 2019 20:24:01 -0000 ----_com.samsung.android.email_3746339897489100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIEx1ZHdpZy5UaGFua3MgZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuUmVnYXJkaW5nIGhlIG1h am9yIGlzc3VlLCBJIHVuZGVyc3RhbmQgd2hhdCB0aGUgaW50ZW50aW9uIG9mIHRoZSBzcGxpdCB3 YXMsIGJ1dCBhcyBmYXIgYXMgZWFybHkgaW1wbGVtZW50YXRpb25zIGFyZSBjb25jZXJuZWQsIHRo ZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYSAnbWluaW1hbCBicmVha2FnZSc7IHVubGVzcyB0aGVy ZSBpcyBzb21lIGN1bm5pbmcgbWVjaGFuaXNtIGluIHRoZSBiYXNpYyBhY2Utb2F1dGgtYXV0aHog cHJvdG9jb2wsIGNoYW5nZXMgdG8gdGhlIHN0cnVjdHVyZSBvZiB0aGUgaXRlbXMgZGVmaW5lZCBo ZXJlIHdpbGwgYnJlYWsgdGhlIHByb3RvY29sLsKgIE9uZSBwb3NzaWJpbGl0eSB0aGF0IEkgY291 bGQgc2VlIGlzIHRoZSBhZGRpdGlvbiBvZiBleHRyYSBrZXlzIGluIHRoZSBDT1NFX0tleSBkaWN0 aW9uYXJ5IHN0cnVjdHVyZTogSW4gdGhpcyBjYXNlIHlvdSBjb3VsZCBhZGQgc29tZSBleHRyYSB3 b3JkcyAoaW4gdGhlIGFjZS1vYXV0aC1hdXRoeiBkb2N1bWVudCkgdG8gaW5kaWNhdGUgdGhhdCB1 bnJlY29nbml6ZWQga2V5cyBzaG91bGQgYmUgaWdub3JlZC7CoCBUaGlzIGlzIGFzc29jaWF0ZWQg d2l0aCB0aGUgZWRpdG9yaWFsIGNvbW1lbnRzIEkgbWFkZSBhYm91dCBzMy4xIHRoYXQgd291bGQg YWxsb3cgYW55IG90aGVyIGtleXMgdG8gYmUgcHJlc2VudCBpbiB0aGUgQ09TRV9LZXkgb2JqZWN0 IHN0cnVjdHVyZS7CoCBTaW1pbGFybHksIHRoZSBvYmVjdHMgZGVmaW5lZCBoZXJlIGFyZSBlZmZl Y3RpdmVseSBKU09OL0NCT1IgZGljdGlvbmFyaWVzLsKgIFRoZSBjaGFuZ2VzIGNvdWxkIGJlIGFj Y29tb2RhdGVkIGJ5IGFkZGluZyBjb21tZW50cyBpbiBhY2Utb2F1dGggdGhhdCBleHRyYSBrZXlz IGluIHRoZSBpdGVtcyBkZWZpbmVkIHdvdWxkIGJlIGlnbm9yZWQuwqDCoEluIG15IG9waW5pb24s IGl0IHdvdWxkIGJlIGJlc3QgdG8gcmVtb3ZlIHRoZSBjb21tZW50cyBhYm91dCBwb3NzaWJsZSBj aGFuZ2VzIGFuZCBqdXN0IHN0YXRlIHRoYXQgdGhleSBoYXZlIGJlZW4gc2VwYXJhdGVkIG91dCBi ZWNhdXNlIHRoZXkgbWlnaHQgYmUgdXNlZCBpbiBvdGhlciBjb250ZXh0cy7CoCBUaGUgcG9zc2li bGUgJ2NoYW5nZXMgdG8gdGhlIGRlZmluaXRpb25zJyBpc3N1ZSBpcyBqdXN0IGEgbWF0dGVyIG9m ICdpbnN0aXR1dGlvbmFsIG1lbW9yeScuwqAgSWYgdGhlcmUgaXMgc29tZSBtZWNoYW5pc20sIHN1 Y2ggYXMgSSBtZW50aW9uZWQgYWJvdmUsIHRvIGFjY29tbW9kYXRlIGNoYW5nZXMgd2l0aG91dCBu ZWVlZGluZyBhbiB1cGRhdGUgdG8gdGhlIGFjZS1vYXV0aC1hdXRoeiAob3Igb3RoZXIgcHJvdG9j b2xzIHVzaW5nIHRoZXNlIGl0ZW1zKSwgdGhpcyBzaG91bGQgYmUgZXhwbGFpbmVkLlJlZ2FyZGlu ZyB0aGUgaCB2cyBiNjQgcmVwcmVzZW50YXRpb25zLCBzaW5jZSB0aGV5IGFyZSBvbmx5IGV4YW1w bGVzIChhbmQgdGhlIHN0cmluZ3MgYXJlIGVzc2VudGlhbGx5IGFyYml0cmFyeSBhcyB0aGUgYWN0 dWFsIGtleXMgYXJlbid0IGluIHRoZSBkb2N1bWVudCksIEknZCBiZSBpbmNsaW5lZCB0byBwdXQg aW4gaCByZXByZXNlbnRhdGlvbnMgdG8gYXZvaWQgbXkgcXVlc3Rpb24gYXJpc25nLsKgIMKgT3Ro ZXJ3aXNlIEkgdGhpbmsgd2UgYXJlIGRvbmUuQ2hlZXJzIGFuZCBiZXN0IHdpc2hlcyBmb3IgdGhl IEZlc3RpdmUgU2Vhc29uLEVsd3luU2VudCBmcm9tIFNhbXN1bmcgdGFibGV0LgotLS0tLS0tLSBP cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogTHVkd2lnIFNlaXR6IDxsdWR3aWdfc2VpdHpA Z214LmRlPiBEYXRlOiAxNy8xMi8yMDE5ICAxNjo1MyAgKEdNVCswMDowMCkgVG86IGVsd3luZEBk aWFsLnBpcGV4LmNvbSBDYzogbGFzdC1jYWxsQGlldGYub3JnLCBnZW4tYXJ0QGlldGYub3JnLCBh Y2VAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtHZW4tYXJ0XSBbQWNlXSBHZW5hcnQgbGFzdCBjYWxs IHJldmlldyBvZgrCoCBkcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMtMDYgSGVsbG8gRWx3eW4s dGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4gQ29tbWVudHMgaW5saW5lLi9MdWR3aWdPbiAyMDE5 LTEyLTE0IDIzOjQ2LCBFbHd5biBEYXZpZXMgdmlhIERhdGF0cmFja2VyIHdyb3RlOj4gUmV2aWV3 ZXI6IEVsd3luIERhdmllcz4gUmV2aWV3IHJlc3VsdDogTm90IFJlYWR5Pj4gSSBhbSB0aGUgYXNz aWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYT4g UmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZD4gYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLsKgIFBsZWFzZSB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0PiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPj4g Rm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdD4+IDxodHRwczovL3Ry YWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+Lj4+IERvY3VtZW50OiBkcmFmdC1p ZXRmLWFjZS1vYXV0aC1wYXJhbXMtMDY+IFJldmlld2VyOiBFbHd5biBEYXZpZXM+IFJldmlldyBE YXRlOiAyMDE5LTEyLTE0PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTEyLTEzPiBJRVNHIFRlbGVj aGF0IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQ+PiBJIGFtIHRoZSBhc3NpZ25l ZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhPiBSZXZp ZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkPiBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuwqAgUGxlYXNlIHRyZWF0IHRoZXNl IGNvbW1lbnRzIGp1c3Q+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4+PiBGb3Ig bW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0Pj4gPCI+aHR0cHM6Ly90cmFj LmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPjsuPj4gRG9jdW1lbnQ6wqBkcmFmdC1p ZXRmLWFjZS1vYXV0aC1wYXJhbXMtMDY+IFJldmlld2VyOiBFbHd5biBEYXZpZXM+IFJldmlldyBE YXRlOiAyMDE5LzEyLzE0PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE5LzIvMTM+IElFU0cgVGVsZWNo YXQgZGF0ZTogKGlmIGtub3duKSBOL0E+PiBTdW1tYXJ5OiBOb3QgcmVhZHkuwqAgSW4gcGFydGlj dWxhciB0aGVyZSBzZWVtcyB0byBiZSBzb21lIGRvdWJ0IGFzIHRvIHdoZXRoZXI+IHRoZSBkZWZp bml0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGFyZSBhY3R1YWxseSBzdGFibGUgLSBvciBhbHRlcm5h dGl2ZWx5IHRoYXQgaXQ+IGxhY2tzIGEgdmVyc2lvbmluZyBtZWNoYW5pc20gdG8gY29wZSB3aXRo IGNoYW5nZXMgdGhhdCB0aGUgbWlnaHQgYmUuPj4gTWFqb3IgaXNzdWVzOj4gRGVhbGluZyB3aXRo IHBvc3NpYmxlIHVwZGF0ZXMgdG8gaXRlbXMgZGVmaW5lZCBoZXJlOj4gSW4gczEgdGhlIGZvbGxv d2luZyBhcHBlYXJzOj4+wqDCoMKgwqDCoCBUaGVzZSBwYXJhbWV0ZXJzIGFuZCBjbGFpbXMgY2Fu IGFsc28gYmUgdXNlZCBpbiBvdGhlciBjb250ZXh0cywgYW5kIG1heT7CoMKgwqDCoMKgIG5lZWQg dG8gYmUgdXBkYXRlZCB0byBhbGlnbiB0aGVtIHdpdGggb25nb2luZyBPQXV0aCB3b3JrLiBUaGVy ZWZvcmUsIHRoZXNlPsKgwqDCoMKgwqAgcGFyYW1ldGVycyBhbmQgY2xhaW1zIGhhdmUgYmVlbiBw dXQgaW50byBhIGRlZGljYXRlZCBkb2N1bWVudCwgdG8+wqDCoMKgwqDCoCBmYWNpbGl0YXRlIHRo ZWlyIHVzZSBhbmQgYW55IHBvdGVudGlhbCB1cGRhdGVzIGluIGEgbWFubmVyIGluZGVwZW5kZW50 IG9mPsKgwqDCoMKgwqAgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0uPj4gSSBhbSB1bmNsZWFy IHdoZXRoZXIgdGhpcyBpbXBsaWVzIHRoYXQgaXQgaXMgaW50ZW5kZWQgdGhhdCB0aGVzZSBwb3Rl bnRpYWw+IHVwZGF0ZXMgd291bGQgYWx0ZXIgdGhlIGRlZmluaXRpb25zIGhlcmUgYWZ0ZXIgdGhl eSBoYXZlIGJlZW4gc3RhbmRhcmRpemVkIG9yPiBhbHRlcm5hdGl2ZWx5IHRoYXQgdGhlIHN0YW5k YXJkaXphdGlvbiBvZiB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkZWxheWVkIHVudGlsPiB0aGUg YWx0ZXJuYXRpdmUgdXNhZ2UgaXMgZGVmaW5lZC7CoCBJZiB0aGUgZmlyc3QgY2FzZSBhcHBsaWVz LCBJIGRvIG5vdCBzZWUgYW55PiB2ZXJzaW9uaW5nIG1lY2hhbmlzbSB0aGF0IHdvdWxkIGFsbG93 IGVhcmx5IGltcGxlbWVudGF0aW9ucyB0byBjb3BlIHdpdGggbGF0ZXI+IHVwZGF0ZXMgb2YgdGhl IGl0ZW1zIGRlZmluZWQgaGVyZS7CoCBJbiB0aGUgc2Vjb25kIGNhc2UsIEkgaGF2ZSB0byBhc2sg bXlzZWxmPiB3aHkgdGhpcyBkb2N1bWVudCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIHN0YW5kYXJk aXphdGlvbiBiZWZvcmUgdGhlIHVzYWdlcyBoYXZlPiBzdGFiaWxpemVkLj5UaGUgaW50ZW50aW9u IHdpdGggdGhpcyBkb2N1bWVudCB3YXMgdG8gcGxhY2UgY2VydGFpbiBwYXJhbWV0ZXJzKHJlcV9j bmYsIGNuZiwgcnNfY25mKSBuZWVkZWQgZm9yIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6IGlu dG8gYXNlcGFyYXRlIGRvY3VtZW50LCB0aGF0IGNvdWxkIGJlIHVwZGF0ZWQgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRyYWZ0c3dpdGhvdXQgb2Jzb2xldGluZyBvciB1cGRhdGluZyBkcmFmdC1pZXRm LWFjZS1vYXV0aC1hdXRoei5UaGlzIGlzIG1haW5seSBkdWUgdG8gc29tZSB3b3JrIGluIHRoZSBP QXV0aCBXRyB3aGljaCBoYXMgYmVlbiBydW5uaW5naW4gcGFyYWxsZWwsIGVzcGVjaWFsbHlodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1wb3Ata2V5LWRpc3RyaWJ1 dGlvbi5TaW5jZSB0aGlzIGlzIG5vdCBhIGhpZ2ggcHJpb3JpdHkgaXRlbSBmb3IgT0F1dGggKHRo ZSBkcmFmdCBuYW1lZCBhYm92ZWhhcyBleHBpcmVkKSwgdGhlIGZlZWxpbmcgaW4gQUNFIHdhcyAo QEFDRSBwbGVhc2UgY29ycmVjdCBtZSBpZiBJbWlzcmVwcmVzZW50KSB0aGF0IGdvaW5nIGZvcndh cmQgd2l0aCB0aGlzIGRvY3VtZW50IHdhcyBhIGdvb2Rjb21wcm9taXNlIHRvIGdldCB0aGVzZSBw YXJhbWV0ZXJzIHN0YW5kYXJkaXplZCwgd2hpbGUgY2F1c2luZyBtaW5pbWFsYnJlYWthZ2UgaWYg T0F1dGggYXQgc29tZSBsYXRlciBwb2ludCBmaW5hbGl6ZWQgdGhlIHBvcCBrZXkgZGlzdHJpYnV0 aW9ud29yay4+IE1pbm9yIGlzc3Vlczo+IHNzMy4xLCAzLjIgYW5kIDQuMTrCoCBUaGUgQ09TRV9L ZXkgdHlwZSAnRUMnIHVzZWQgaW4gc2V2ZXJhbCBrdHkgZmllbGRzIGlzIG5vdD4gZGVmaW5lZC7C oCBJIGFzc3VtZSBpdCBzaG91bGQgYmUgJ0VDMicuPkNvcnJlY3QsIHdpbGwgZml4PiBzczMuMSwg My4yIGFuZCA0LjE6wqAgRG9lcyBpdCBtYXR0ZXIgdGhhdCB0aGUgZGVmaW5pdGlvbnMgb2YgdGhl IHggYW5kIHk+IHBhcmFtZXRlcnMgaW4gYW4gRUMyIGtleSBhcmUgZ2l2ZW4gYXMgJ2gnIGVuY29k aW5ncyBpbiBSRkM4MTUyIGJ1dCBhcmUgZ2l2ZW4gYXM+ICdiNjQnIGluIHRoaXMgZG9jdW1lbnQ/ wqAgSSBhbSB2ZXJ5IG11Y2ggbm90IGFuIGV4cGVydCBoZXJlLlRoaXMgaXMganVzdCBhIG1hdHRl ciBvZiB0aGUgZGlhZ25vc3RpYyByZXByZXNlbnRhdGlvbiB1c2VkIGhlcmUgZm9yaHVtYW4gcmVh ZGFiaWxpdHkuIE9uIHRoZSB3aXJlIHRoaXMgd2lsbCBiZSB0aGUgc2FtZSBiaW5hcnkgc3RyaW5n Lk5vdGUgdGhhdCB0aGUgaGV4IGVuY29kaW5nIGgnLi4uLicgcmVuZGVycyBhIG11Y2ggbG9uZ2Vy IHN0cmluZyB0aGFuIHRoZUJhc2U2NCBlbmNvZGluZyBiNjQnLi4uJyBzbyBJIHByZWZlciBiNjQg Zm9yIHJlYWRhYmlsaXR5Lj4+IHM2OiBUaGlzIHNlY3Rpb24gc3RhcnRzIHdpdGggJ0lmIENCT1Ig aXMgdXNlZC4uLic6IFRoZSBtYWluIEFDRSBkcmFmdD4gZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0 aHogaXMgYXBwYXJlbnRseSBpbnRlbmRlZCB0byBjb3ZlciBib3RoIEpTT04gYW5kIENCT1I+IGVu Y29kaW5ncyBvZiBwYXlsb2FkcywgYWx0aG91Z2ggQ0JPUiBpcyByZWNvbW1lbmRlZC7CoCBUaGlz IGlzIG5vdCBtYWRlIGV4cGxpY2l0PiBpbiB0aGlzIGFkZGl0aW9uIHRvIHRoYXQgc3BlY2lmaWNh dGlvbiBhbmQgdGhlIHVzZSBvZiBDQk9SIGRpYWdub3N0aWM+IHJlcHJlc2VudGF0aW9uIGFuZCB0 aGUgcHJvbWluZW5jZSBvZiBDT1NFX0tleSBpdGVtcyBjb3VsZCBtYWtlIGl0IGFwcGVhciB1cD4g dW50aWwgczYgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24gaXMgaW50ZW5kZWQganVzdCBmb3IgQ0JP UiBlbmNvZGluZy7CoCBBIGZldz4gd29yZHMgYXQgdGhlIGJlZ2lubmluZyB3b3VsZCBjbGFyaWZ5 IHRoZSBkdWFsIGFsdGVybmF0aXZlcy4+SSB3aWxsIGFkZCBhIGNsYXJpZmljYXRpb24uIFRoZSBp bnRlbnRpb24gaXMgdG8gY292ZXIgYm90aCBKU09OIGFuZCBDQk9SLj4gTml0cy9lZGl0b3JpYWwg Y29tbWVudHM6V2lsbCBmaXguPiBHZW5lcmFsOiBzL2UuZy4vZS5nLiwvICgzIHBsYWNlcyk+PiBB YnN0cmFjdCwgMm5kIHNlbnRlbmNlOiBzL3doaXNoZXMvd2lzaGVzLz4+IEFic3RyYWN0OiBOZWVk IHRvIGV4cGFuZCBBUyBhbmQgUlMuPj4gczI6wqAgUlMsIEFTIGFuZCAocHJvYmFibHkpIHZhcmlv dXMgb3RoZXIgdGVybXMgYXJlIGRlZmluZWQgaW4gUkZDIDY3NDkgYW5kIG5lZWQ+IHRvIGJlIGV4 cGFuZGVkIG9uwqAgZmlyc3QgdXNlLsKgIEFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGUgcGFyYSBm cm9tPiBkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoeiB3b3VsZCBzb2x2ZSB0aGlzIChleGNlcHQg Zm9yIHRoZSBhYnN0cmFjdCkuPj7CoMKgwqDCoMKgIFRlcm1pbm9sb2d5IGZvciBlbnRpdGllcyBp biB0aGUgYXJjaGl0ZWN0dXJlIGlzIGRlZmluZWQgaW4gT0F1dGggMi4wPsKgwqDCoMKgwqAgW1JG QzY3NDldIHN1Y2ggYXMgY2xpZW50IChDKSwgcmVzb3VyY2Ugc2VydmVyIChSUyksIGFuZCBhdXRo b3JpemF0aW9uPsKgwqDCoMKgwqAgc2VydmVyIChBUykuczIsIHBhcmEgMzogTmVlZCB0byBleHBh bmQgQ29BUCBvbiBmaXJzdCB1c2UuPj4gczM6wqAgVGhpcyBzZWN0aW9uIG5lZWRzIGEgcmVmZXJl bmNlIHRvIFJGQyA4MTUyIGZvciB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGU+IENXVCBDT1NFX0tl eSBpdGVtIHRoYXQgaXMgdXNlZCBleHRlbnNpdmVseS4+PiBzMy9zNDogU29tZSBpbnRyb2R1Y3Rv cnkgdGV4dCBmb3IgZWFjaCBzZWN0aW9uIGlzIGRlc2lyYWJsZS4+PiBzMy4xLCBwYXJhIDIgKGRl ZmluaXRpb24gb2YgcmVxX2NuZik6OiBQb3NzaWJseSBhZGQgYSBub3RlIHRoYXQgdGhlPiByZWNv bW1lbmRhdGlvbiBhZ2FpbnN0IHN5bW1ldHJpYyBrZXlzIGltcGxpZXMgY3VycmVudGx5IGt0eSBi ZWluZyAnU3ltbWV0cmljJy4+IFdpbGwgaXQgZXZlciBiZSBhbnl0aGluZyBlbHNlPz4+IHMzLjE6 wqAgVGhlIHRleHQgaW4gczMuMiBvZiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vz c2lvbi0wMyBjb250YW5zPiB0aGUgZm9sbG93aW5nPj7CoMKgwqDCoCBUaGUgQ09TRV9LZXkgTVVT VCBjb250YWluIHRoZSByZXF1aXJlZCBrZXkgbWVtYmVycyBmb3IgYSBDT1NFX0tleSBvZiB0aGF0 PsKgwqDCoMKgIGtleSB0eXBlIGFuZCBNQVkgY29udGFpbiBvdGhlciBDT1NFX0tleSBtZW1iZXJz LCBpbmNsdWRpbmcgdGhlICJraWQiIChLZXk+wqDCoMKgwqAgSUQpIG1lbWJlci4+PsKgwqDCoMKg IFRoZSAiQ09TRV9LZXkiIG1lbWJlciBNQVkgYWxzbyBiZSB1c2VkIGZvciBhIENPU0VfS2V5IHJl cHJlc2VudGluZyBhPsKgwqDCoMKgIHN5bW1ldHJpYyBrZXksIHByb3ZpZGVkIHRoYXQgdGhlIENX VCBpcyBlbmNyeXB0ZWQgc28gdGhhdCB0aGUga2V5IGlzIG5vdD7CoMKgwqDCoCByZXZlYWxlZCB0 byB1bmludGVuZGVkIHBhcnRpZXMuIFRoZSBtZWFucyBvZiBlbmNyeXB0aW5nIGEgQ1dUIGlzIGV4 cGxhaW5lZD7CoMKgwqDCoCBpbiBbUkZDODM5Ml0uIElmIHRoZSBDV1QgaXMgbm90IGVuY3J5cHRl ZCwgdGhlIHN5bW1ldHJpYyBrZXkgTVVTVCBiZT7CoMKgwqDCoCBlbmNyeXB0ZWQgYXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMy4zLj4+IFRoZXNlIHJpZGVycyBwcm9iYWJseSBhcHBseSB0byBhbGwg dGhlIHN1YnNlY3RvbnMgb2YgczMgYW5kIHRvIHM0LjEgYW5kIGNvdWxkPiBiZSBpbmNsdWRlZCBp biB0aGUgY3VycmVudGx5IGVtcHR5IG1haW4gc2VjdGlvbiB0ZXh0Lj4+IHM0LjEsIHJzX2NuZiAt IERUTFMtUlBLOiBUaGlzIHRlcm0gbmVlZHMgYSByZWZlcmVuY2UgKFJGQyA3MjUwKS4gQWxzbyBh bGwgb3RoZXI+IHVzZXMgZG8gbm90IGh5cGhlbmF0ZSBhbmQgUlBLIG5lZWRzIHRvIGJlIGV4cGFu ZGVkLj7CoMKgwqDCoCBzL0RUTFMtUlBLIGhhbmRzaGFrZS9EVExTIFJhdyBQdWJsaWMgS2V5IChS UEspIGhhbmRzaGFrZSBbUkZDNzI1MF0vPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPiBBY2UgbWFpbGluZyBsaXN0PiBBY2VAaWV0Zi5vcmc+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fR2VuLWFydCBtYWlsaW5nIGxpc3RHZW4tYXJ0QGll dGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW4tYXJ0 ----_com.samsung.android.email_3746339897489100 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5IaSwgTHVkd2lnLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9 ImF1dG8iPlRoYW5rcyBmb3IgdGhlIHByb21wdCByZXNwb25zZS48L2Rpdj48ZGl2IGRpcj0iYXV0 byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5SZWdhcmRpbmcgaGUgbWFqb3IgaXNzdWUsIEkg dW5kZXJzdGFuZCB3aGF0IHRoZSBpbnRlbnRpb24gb2YgdGhlIHNwbGl0IHdhcywgYnV0IGFzIGZh ciBhcyBlYXJseSBpbXBsZW1lbnRhdGlvbnMgYXJlIGNvbmNlcm5lZCwgdGhlcmUgaXMgbm8gc3Vj aCB0aGluZyBhcyBhICdtaW5pbWFsIGJyZWFrYWdlJzsgdW5sZXNzIHRoZXJlIGlzIHNvbWUgY3Vu bmluZyBtZWNoYW5pc20gaW4gdGhlIGJhc2ljIGFjZS1vYXV0aC1hdXRoeiBwcm90b2NvbCwgY2hh bmdlcyB0byB0aGUgc3RydWN0dXJlIG9mIHRoZSBpdGVtcyBkZWZpbmVkIGhlcmUgd2lsbCBicmVh ayB0aGUgcHJvdG9jb2wuJm5ic3A7IE9uZSBwb3NzaWJpbGl0eSB0aGF0IEkgY291bGQgc2VlIGlz IHRoZSBhZGRpdGlvbiBvZiBleHRyYSBrZXlzIGluIHRoZSBDT1NFX0tleSBkaWN0aW9uYXJ5IHN0 cnVjdHVyZTogSW4gdGhpcyBjYXNlIHlvdSBjb3VsZCBhZGQgc29tZSBleHRyYSB3b3JkcyAoaW4g dGhlIGFjZS1vYXV0aC1hdXRoeiBkb2N1bWVudCkgdG8gaW5kaWNhdGUgdGhhdCB1bnJlY29nbml6 ZWQga2V5cyBzaG91bGQgYmUgaWdub3JlZC4mbmJzcDsgVGhpcyBpcyBhc3NvY2lhdGVkIHdpdGgg dGhlIGVkaXRvcmlhbCBjb21tZW50cyBJIG1hZGUgYWJvdXQgczMuMSB0aGF0IHdvdWxkIGFsbG93 IGFueSBvdGhlciBrZXlzIHRvIGJlIHByZXNlbnQgaW4gdGhlIENPU0VfS2V5IG9iamVjdCBzdHJ1 Y3R1cmUuJm5ic3A7IFNpbWlsYXJseSwgdGhlIG9iZWN0cyBkZWZpbmVkIGhlcmUgYXJlIGVmZmVj dGl2ZWx5IEpTT04vQ0JPUiBkaWN0aW9uYXJpZXMuJm5ic3A7IFRoZSBjaGFuZ2VzIGNvdWxkIGJl IGFjY29tb2RhdGVkIGJ5IGFkZGluZyBjb21tZW50cyBpbiBhY2Utb2F1dGggdGhhdCBleHRyYSBr ZXlzIGluIHRoZSBpdGVtcyBkZWZpbmVkIHdvdWxkIGJlIGlnbm9yZWQuJm5ic3A7Jm5ic3A7PC9k aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+SW4gbXkgb3Bpbmlv biwgaXQgd291bGQgYmUgYmVzdCB0byByZW1vdmUgdGhlIGNvbW1lbnRzIGFib3V0IHBvc3NpYmxl IGNoYW5nZXMgYW5kIGp1c3Qgc3RhdGUgdGhhdCB0aGV5IGhhdmUgYmVlbiBzZXBhcmF0ZWQgb3V0 IGJlY2F1c2UgdGhleSBtaWdodCBiZSB1c2VkIGluIG90aGVyIGNvbnRleHRzLiZuYnNwOyBUaGUg cG9zc2libGUgJ2NoYW5nZXMgdG8gdGhlIGRlZmluaXRpb25zJyBpc3N1ZSBpcyBqdXN0IGEgbWF0 dGVyIG9mICdpbnN0aXR1dGlvbmFsIG1lbW9yeScuJm5ic3A7IElmIHRoZXJlIGlzIHNvbWUgbWVj aGFuaXNtLCBzdWNoIGFzIEkgbWVudGlvbmVkIGFib3ZlLCB0byBhY2NvbW1vZGF0ZSBjaGFuZ2Vz IHdpdGhvdXQgbmVlZWRpbmcgYW4gdXBkYXRlIHRvIHRoZSBhY2Utb2F1dGgtYXV0aHogKG9yIG90 aGVyIHByb3RvY29scyB1c2luZyB0aGVzZSBpdGVtcyksIHRoaXMgc2hvdWxkIGJlIGV4cGxhaW5l ZC48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5SZWdhcmRp bmcgdGhlIGggdnMgYjY0IHJlcHJlc2VudGF0aW9ucywgc2luY2UgdGhleSBhcmUgb25seSBleGFt cGxlcyAoYW5kIHRoZSBzdHJpbmdzIGFyZSBlc3NlbnRpYWxseSBhcmJpdHJhcnkgYXMgdGhlIGFj dHVhbCBrZXlzIGFyZW4ndCBpbiB0aGUgZG9jdW1lbnQpLCBJJ2QgYmUgaW5jbGluZWQgdG8gcHV0 IGluIGggcmVwcmVzZW50YXRpb25zIHRvIGF2b2lkIG15IHF1ZXN0aW9uIGFyaXNuZy4mbmJzcDsg Jm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+T3Ro ZXJ3aXNlIEkgdGhpbmsgd2UgYXJlIGRvbmUuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rp dj48ZGl2IGRpcj0iYXV0byI+Q2hlZXJzIGFuZCBiZXN0IHdpc2hlcyBmb3IgdGhlIEZlc3RpdmUg U2Vhc29uLDwvZGl2PjxkaXYgZGlyPSJhdXRvIj5FbHd5bjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48 YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWdu YXR1cmUiIGRpcj0iYXV0byI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3 IiBkaXI9ImF1dG8iPlNlbnQgZnJvbSBTYW1zdW5nIHRhYmxldC48L2Rpdj48L2Rpdj48ZGl2IGRp cj0iYXV0byI+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTox MDAlO2NvbG9yOiMwMDAwMDAiIGRpcj0iYXV0byI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXpl OjEwMCU7Y29sb3I6IzAwMDAwMCIgZGlyPSJhdXRvIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6MTAwJTtjb2xvcjojMDAwMDAwIiBkaXI9ImF1dG8iPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0t PjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTog THVkd2lnIFNlaXR6ICZsdDtsdWR3aWdfc2VpdHpAZ214LmRlJmd0OyA8L2Rpdj48ZGl2PkRhdGU6 IDE3LzEyLzIwMTkgIDE2OjUzICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBlbHd5bmRAZGlh bC5waXBleC5jb20gPC9kaXY+PGRpdj5DYzogbGFzdC1jYWxsQGlldGYub3JnLCBnZW4tYXJ0QGll dGYub3JnLCBhY2VAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW0dlbi1hcnRdIFtB Y2VdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mCiZuYnNwOyBkcmFmdC1pZXRmLWFjZS1vYXV0 aC1wYXJhbXMtMDYgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+SGVsbG8gRWx3eW4sPGJyPjxi cj50aGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LiBDb21tZW50cyBpbmxpbmUuPGJyPjxicj4vTHVk d2lnPGJyPjxicj48YnI+T24gMjAxOS0xMi0xNCAyMzo0NiwgRWx3eW4gRGF2aWVzIHZpYSBEYXRh dHJhY2tlciB3cm90ZTo8YnI+Jmd0OyBSZXZpZXdlcjogRWx3eW4gRGF2aWVzPGJyPiZndDsgUmV2 aWV3IHJlc3VsdDogTm90IFJlYWR5PGJyPiZndDs8YnI+Jmd0OyBJIGFtIHRoZSBhc3NpZ25lZCBH ZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhPGJyPiZndDsg UmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZDxicj4mZ3Q7IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4mbmJzcDsgUGxl YXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Q8YnI+Jmd0OyBsaWtlIGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuPGJyPiZndDs8YnI+Jmd0OyBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgRkFRIGF0PGJyPiZndDs8YnI+Jmd0OyAmbHQ7aHR0cHM6Ly90cmFjLmlldGYu b3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxJmd0Oy48YnI+Jmd0Ozxicj4mZ3Q7IERvY3VtZW50 OiBkcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMtMDY8YnI+Jmd0OyBSZXZpZXdlcjogRWx3eW4g RGF2aWVzPGJyPiZndDsgUmV2aWV3IERhdGU6IDIwMTktMTItMTQ8YnI+Jmd0OyBJRVRGIExDIEVu ZCBEYXRlOiAyMDE5LTEyLTEzPGJyPiZndDsgSUVTRyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1 bGVkIGZvciBhIHRlbGVjaGF0PGJyPiZndDs8YnI+Jmd0OyBJIGFtIHRoZSBhc3NpZ25lZCBHZW4t QVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhPGJyPiZndDsgUmV2 aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nl c3NlZDxicj4mZ3Q7IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4mbmJzcDsgUGxlYXNl IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Q8YnI+Jmd0OyBsaWtlIGFueSBvdGhlciBsYXN0IGNh bGwgY29tbWVudHMuPGJyPiZndDs8YnI+Jmd0OyBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNl IHNlZSB0aGUgRkFRIGF0PGJyPiZndDs8YnI+Jmd0OyAmbHQ7IiZndDtodHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXEmZ3Q7Oy48YnI+Jmd0Ozxicj4mZ3Q7IERvY3Vt ZW50OiZuYnNwO2RyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wNjxicj4mZ3Q7IFJldmlld2Vy OiBFbHd5biBEYXZpZXM8YnI+Jmd0OyBSZXZpZXcgRGF0ZTogMjAxOS8xMi8xNDxicj4mZ3Q7IElF VEYgTEMgRW5kIERhdGU6IDIwMTkvMi8xMzxicj4mZ3Q7IElFU0cgVGVsZWNoYXQgZGF0ZTogKGlm IGtub3duKSBOL0E8YnI+Jmd0Ozxicj4mZ3Q7IFN1bW1hcnk6IE5vdCByZWFkeS4mbmJzcDsgSW4g cGFydGljdWxhciB0aGVyZSBzZWVtcyB0byBiZSBzb21lIGRvdWJ0IGFzIHRvIHdoZXRoZXI8YnI+ Jmd0OyB0aGUgZGVmaW5pdGlvbnMgaW4gdGhpcyBkb2N1bWVudCBhcmUgYWN0dWFsbHkgc3RhYmxl IC0gb3IgYWx0ZXJuYXRpdmVseSB0aGF0IGl0PGJyPiZndDsgbGFja3MgYSB2ZXJzaW9uaW5nIG1l Y2hhbmlzbSB0byBjb3BlIHdpdGggY2hhbmdlcyB0aGF0IHRoZSBtaWdodCBiZS48YnI+Jmd0Ozxi cj4mZ3Q7IE1ham9yIGlzc3Vlczo8YnI+Jmd0OyBEZWFsaW5nIHdpdGggcG9zc2libGUgdXBkYXRl cyB0byBpdGVtcyBkZWZpbmVkIGhlcmU6PGJyPiZndDsgSW4gczEgdGhlIGZvbGxvd2luZyBhcHBl YXJzOjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlc2Ug cGFyYW1ldGVycyBhbmQgY2xhaW1zIGNhbiBhbHNvIGJlIHVzZWQgaW4gb3RoZXIgY29udGV4dHMs IGFuZCBtYXk8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZWVkIHRvIGJl IHVwZGF0ZWQgdG8gYWxpZ24gdGhlbSB3aXRoIG9uZ29pbmcgT0F1dGggd29yay4gVGhlcmVmb3Jl LCB0aGVzZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcmFtZXRlcnMg YW5kIGNsYWltcyBoYXZlIGJlZW4gcHV0IGludG8gYSBkZWRpY2F0ZWQgZG9jdW1lbnQsIHRvPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmFjaWxpdGF0ZSB0aGVpciB1c2Ug YW5kIGFueSBwb3RlbnRpYWwgdXBkYXRlcyBpbiBhIG1hbm5lciBpbmRlcGVuZGVudCBvZjxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0 aHpdLjxicj4mZ3Q7PGJyPiZndDsgSSBhbSB1bmNsZWFyIHdoZXRoZXIgdGhpcyBpbXBsaWVzIHRo YXQgaXQgaXMgaW50ZW5kZWQgdGhhdCB0aGVzZSBwb3RlbnRpYWw8YnI+Jmd0OyB1cGRhdGVzIHdv dWxkIGFsdGVyIHRoZSBkZWZpbml0aW9ucyBoZXJlIGFmdGVyIHRoZXkgaGF2ZSBiZWVuIHN0YW5k YXJkaXplZCBvcjxicj4mZ3Q7IGFsdGVybmF0aXZlbHkgdGhhdCB0aGUgc3RhbmRhcmRpemF0aW9u IG9mIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGRlbGF5ZWQgdW50aWw8YnI+Jmd0OyB0aGUgYWx0 ZXJuYXRpdmUgdXNhZ2UgaXMgZGVmaW5lZC4mbmJzcDsgSWYgdGhlIGZpcnN0IGNhc2UgYXBwbGll cywgSSBkbyBub3Qgc2VlIGFueTxicj4mZ3Q7IHZlcnNpb25pbmcgbWVjaGFuaXNtIHRoYXQgd291 bGQgYWxsb3cgZWFybHkgaW1wbGVtZW50YXRpb25zIHRvIGNvcGUgd2l0aCBsYXRlcjxicj4mZ3Q7 IHVwZGF0ZXMgb2YgdGhlIGl0ZW1zIGRlZmluZWQgaGVyZS4mbmJzcDsgSW4gdGhlIHNlY29uZCBj YXNlLCBJIGhhdmUgdG8gYXNrIG15c2VsZjxicj4mZ3Q7IHdoeSB0aGlzIGRvY3VtZW50IGhhcyBi ZWVuIHN1Ym1pdHRlZCBmb3Igc3RhbmRhcmRpemF0aW9uIGJlZm9yZSB0aGUgdXNhZ2VzIGhhdmU8 YnI+Jmd0OyBzdGFiaWxpemVkLjxicj4mZ3Q7PGJyPjxicj5UaGUgaW50ZW50aW9uIHdpdGggdGhp cyBkb2N1bWVudCB3YXMgdG8gcGxhY2UgY2VydGFpbiBwYXJhbWV0ZXJzPGJyPihyZXFfY25mLCBj bmYsIHJzX2NuZikgbmVlZGVkIGZvciBkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoeiBpbnRvIGE8 YnI+c2VwYXJhdGUgZG9jdW1lbnQsIHRoYXQgY291bGQgYmUgdXBkYXRlZCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZHJhZnRzPGJyPndpdGhvdXQgb2Jzb2xldGluZyBvciB1cGRhdGluZyBkcmFmdC1p ZXRmLWFjZS1vYXV0aC1hdXRoei48YnI+PGJyPlRoaXMgaXMgbWFpbmx5IGR1ZSB0byBzb21lIHdv cmsgaW4gdGhlIE9BdXRoIFdHIHdoaWNoIGhhcyBiZWVuIHJ1bm5pbmc8YnI+aW4gcGFyYWxsZWws IGVzcGVjaWFsbHk8YnI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtcG9wLWtleS1kaXN0cmlidXRpb24uPGJyPjxicj5TaW5jZSB0aGlzIGlzIG5vdCBhIGhpZ2gg cHJpb3JpdHkgaXRlbSBmb3IgT0F1dGggKHRoZSBkcmFmdCBuYW1lZCBhYm92ZTxicj5oYXMgZXhw aXJlZCksIHRoZSBmZWVsaW5nIGluIEFDRSB3YXMgKEBBQ0UgcGxlYXNlIGNvcnJlY3QgbWUgaWYg STxicj5taXNyZXByZXNlbnQpIHRoYXQgZ29pbmcgZm9yd2FyZCB3aXRoIHRoaXMgZG9jdW1lbnQg d2FzIGEgZ29vZDxicj5jb21wcm9taXNlIHRvIGdldCB0aGVzZSBwYXJhbWV0ZXJzIHN0YW5kYXJk aXplZCwgd2hpbGUgY2F1c2luZyBtaW5pbWFsPGJyPmJyZWFrYWdlIGlmIE9BdXRoIGF0IHNvbWUg bGF0ZXIgcG9pbnQgZmluYWxpemVkIHRoZSBwb3Aga2V5IGRpc3RyaWJ1dGlvbjxicj53b3JrLjxi cj48YnI+PGJyPiZndDsgTWlub3IgaXNzdWVzOjxicj4mZ3Q7IHNzMy4xLCAzLjIgYW5kIDQuMTom bmJzcDsgVGhlIENPU0VfS2V5IHR5cGUgJ0VDJyB1c2VkIGluIHNldmVyYWwga3R5IGZpZWxkcyBp cyBub3Q8YnI+Jmd0OyBkZWZpbmVkLiZuYnNwOyBJIGFzc3VtZSBpdCBzaG91bGQgYmUgJ0VDMicu PGJyPiZndDs8YnI+Q29ycmVjdCwgd2lsbCBmaXg8YnI+PGJyPiZndDsgc3MzLjEsIDMuMiBhbmQg NC4xOiZuYnNwOyBEb2VzIGl0IG1hdHRlciB0aGF0IHRoZSBkZWZpbml0aW9ucyBvZiB0aGUgeCBh bmQgeTxicj4mZ3Q7IHBhcmFtZXRlcnMgaW4gYW4gRUMyIGtleSBhcmUgZ2l2ZW4gYXMgJ2gnIGVu Y29kaW5ncyBpbiBSRkM4MTUyIGJ1dCBhcmUgZ2l2ZW4gYXM8YnI+Jmd0OyAnYjY0JyBpbiB0aGlz IGRvY3VtZW50PyZuYnNwOyBJIGFtIHZlcnkgbXVjaCBub3QgYW4gZXhwZXJ0IGhlcmUuPGJyPjxi cj5UaGlzIGlzIGp1c3QgYSBtYXR0ZXIgb2YgdGhlIGRpYWdub3N0aWMgcmVwcmVzZW50YXRpb24g dXNlZCBoZXJlIGZvcjxicj5odW1hbiByZWFkYWJpbGl0eS4gT24gdGhlIHdpcmUgdGhpcyB3aWxs IGJlIHRoZSBzYW1lIGJpbmFyeSBzdHJpbmcuPGJyPjxicj5Ob3RlIHRoYXQgdGhlIGhleCBlbmNv ZGluZyBoJy4uLi4nIHJlbmRlcnMgYSBtdWNoIGxvbmdlciBzdHJpbmcgdGhhbiB0aGU8YnI+QmFz ZTY0IGVuY29kaW5nIGI2NCcuLi4nIHNvIEkgcHJlZmVyIGI2NCBmb3IgcmVhZGFiaWxpdHkuPGJy PiZndDs8YnI+Jmd0OyBzNjogVGhpcyBzZWN0aW9uIHN0YXJ0cyB3aXRoICdJZiBDQk9SIGlzIHVz ZWQuLi4nOiBUaGUgbWFpbiBBQ0UgZHJhZnQ8YnI+Jmd0OyBkcmFmdC1pZXRmLWFjZS1vYXV0aC1h dXRoeiBpcyBhcHBhcmVudGx5IGludGVuZGVkIHRvIGNvdmVyIGJvdGggSlNPTiBhbmQgQ0JPUjxi cj4mZ3Q7IGVuY29kaW5ncyBvZiBwYXlsb2FkcywgYWx0aG91Z2ggQ0JPUiBpcyByZWNvbW1lbmRl ZC4mbmJzcDsgVGhpcyBpcyBub3QgbWFkZSBleHBsaWNpdDxicj4mZ3Q7IGluIHRoaXMgYWRkaXRp b24gdG8gdGhhdCBzcGVjaWZpY2F0aW9uIGFuZCB0aGUgdXNlIG9mIENCT1IgZGlhZ25vc3RpYzxi cj4mZ3Q7IHJlcHJlc2VudGF0aW9uIGFuZCB0aGUgcHJvbWluZW5jZSBvZiBDT1NFX0tleSBpdGVt cyBjb3VsZCBtYWtlIGl0IGFwcGVhciB1cDxicj4mZ3Q7IHVudGlsIHM2IHRoYXQgdGhpcyBzcGVj aWZpY2F0aW9uIGlzIGludGVuZGVkIGp1c3QgZm9yIENCT1IgZW5jb2RpbmcuJm5ic3A7IEEgZmV3 PGJyPiZndDsgd29yZHMgYXQgdGhlIGJlZ2lubmluZyB3b3VsZCBjbGFyaWZ5IHRoZSBkdWFsIGFs dGVybmF0aXZlcy48YnI+Jmd0Ozxicj5JIHdpbGwgYWRkIGEgY2xhcmlmaWNhdGlvbi4gVGhlIGlu dGVudGlvbiBpcyB0byBjb3ZlciBib3RoIEpTT04gYW5kIENCT1IuPGJyPjxicj48YnI+Jmd0OyBO aXRzL2VkaXRvcmlhbCBjb21tZW50czo8YnI+PGJyPldpbGwgZml4Ljxicj48YnI+Jmd0OyBHZW5l cmFsOiBzL2UuZy4vZS5nLiwvICgzIHBsYWNlcyk8YnI+Jmd0Ozxicj4mZ3Q7IEFic3RyYWN0LCAy bmQgc2VudGVuY2U6IHMvd2hpc2hlcy93aXNoZXMvPGJyPiZndDs8YnI+Jmd0OyBBYnN0cmFjdDog TmVlZCB0byBleHBhbmQgQVMgYW5kIFJTLjxicj4mZ3Q7PGJyPiZndDsgczI6Jm5ic3A7IFJTLCBB UyBhbmQgKHByb2JhYmx5KSB2YXJpb3VzIG90aGVyIHRlcm1zIGFyZSBkZWZpbmVkIGluIFJGQyA2 NzQ5IGFuZCBuZWVkPGJyPiZndDsgdG8gYmUgZXhwYW5kZWQgb24mbmJzcDsgZmlyc3QgdXNlLiZu YnNwOyBBZGRpbmcgc29tZXRoaW5nIGxpa2UgdGhlIHBhcmEgZnJvbTxicj4mZ3Q7IGRyYWZ0LWll dGYtYWNlLW9hdXRoLWF1dGh6IHdvdWxkIHNvbHZlIHRoaXMgKGV4Y2VwdCBmb3IgdGhlIGFic3Ry YWN0KS48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRlcm1p bm9sb2d5IGZvciBlbnRpdGllcyBpbiB0aGUgYXJjaGl0ZWN0dXJlIGlzIGRlZmluZWQgaW4gT0F1 dGggMi4wPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1JGQzY3NDldIHN1 Y2ggYXMgY2xpZW50IChDKSwgcmVzb3VyY2Ugc2VydmVyIChSUyksIGFuZCBhdXRob3JpemF0aW9u PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VydmVyIChBUykuczIsIHBh cmEgMzogTmVlZCB0byBleHBhbmQgQ29BUCBvbiBmaXJzdCB1c2UuPGJyPiZndDs8YnI+Jmd0OyBz MzombmJzcDsgVGhpcyBzZWN0aW9uIG5lZWRzIGEgcmVmZXJlbmNlIHRvIFJGQyA4MTUyIGZvciB0 aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGU8YnI+Jmd0OyBDV1QgQ09TRV9LZXkgaXRlbSB0aGF0IGlz IHVzZWQgZXh0ZW5zaXZlbHkuPGJyPiZndDs8YnI+Jmd0OyBzMy9zNDogU29tZSBpbnRyb2R1Y3Rv cnkgdGV4dCBmb3IgZWFjaCBzZWN0aW9uIGlzIGRlc2lyYWJsZS48YnI+Jmd0Ozxicj4mZ3Q7IHMz LjEsIHBhcmEgMiAoZGVmaW5pdGlvbiBvZiByZXFfY25mKTo6IFBvc3NpYmx5IGFkZCBhIG5vdGUg dGhhdCB0aGU8YnI+Jmd0OyByZWNvbW1lbmRhdGlvbiBhZ2FpbnN0IHN5bW1ldHJpYyBrZXlzIGlt cGxpZXMgY3VycmVudGx5IGt0eSBiZWluZyAnU3ltbWV0cmljJy48YnI+Jmd0OyBXaWxsIGl0IGV2 ZXIgYmUgYW55dGhpbmcgZWxzZT88YnI+Jmd0Ozxicj4mZ3Q7IHMzLjE6Jm5ic3A7IFRoZSB0ZXh0 IGluIHMzLjIgb2YgZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24tMDMgY29u dGFuczxicj4mZ3Q7IHRoZSBmb2xsb3dpbmc8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRoZSBDT1NFX0tleSBNVVNUIGNvbnRhaW4gdGhlIHJlcXVpcmVkIGtleSBtZW1i ZXJzIGZvciBhIENPU0VfS2V5IG9mIHRoYXQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBrZXkgdHlwZSBhbmQgTUFZIGNvbnRhaW4gb3RoZXIgQ09TRV9LZXkgbWVtYmVycywgaW5jbHVk aW5nIHRoZSAia2lkIiAoS2V5PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSUQpIG1l bWJlci48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSAiQ09TRV9L ZXkiIG1lbWJlciBNQVkgYWxzbyBiZSB1c2VkIGZvciBhIENPU0VfS2V5IHJlcHJlc2VudGluZyBh PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3ltbWV0cmljIGtleSwgcHJvdmlkZWQg dGhhdCB0aGUgQ1dUIGlzIGVuY3J5cHRlZCBzbyB0aGF0IHRoZSBrZXkgaXMgbm90PGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV2ZWFsZWQgdG8gdW5pbnRlbmRlZCBwYXJ0aWVzLiBU aGUgbWVhbnMgb2YgZW5jcnlwdGluZyBhIENXVCBpcyBleHBsYWluZWQ8YnI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpbiBbUkZDODM5Ml0uIElmIHRoZSBDV1QgaXMgbm90IGVuY3J5cHRl ZCwgdGhlIHN5bW1ldHJpYyBrZXkgTVVTVCBiZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGVuY3J5cHRlZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMuPGJyPiZndDs8YnI+Jmd0 OyBUaGVzZSByaWRlcnMgcHJvYmFibHkgYXBwbHkgdG8gYWxsIHRoZSBzdWJzZWN0b25zIG9mIHMz IGFuZCB0byBzNC4xIGFuZCBjb3VsZDxicj4mZ3Q7IGJlIGluY2x1ZGVkIGluIHRoZSBjdXJyZW50 bHkgZW1wdHkgbWFpbiBzZWN0aW9uIHRleHQuPGJyPiZndDs8YnI+Jmd0OyBzNC4xLCByc19jbmYg LSBEVExTLVJQSzogVGhpcyB0ZXJtIG5lZWRzIGEgcmVmZXJlbmNlIChSRkMgNzI1MCkuIEFsc28g YWxsIG90aGVyPGJyPiZndDsgdXNlcyBkbyBub3QgaHlwaGVuYXRlIGFuZCBSUEsgbmVlZHMgdG8g YmUgZXhwYW5kZWQuPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcy9EVExTLVJQSyBo YW5kc2hha2UvRFRMUyBSYXcgUHVibGljIEtleSAoUlBLKSBoYW5kc2hha2UgW1JGQzcyNTBdLzxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4mZ3Q7IEFjZSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBBY2VAaWV0Zi5v cmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTxicj4m Z3Q7PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj5HZW4tYXJ0IG1haWxpbmcgbGlzdDxicj5HZW4tYXJ0QGlldGYub3JnPGJyPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFydDxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_3746339897489100-- From nobody Thu Dec 19 14:30:29 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B7B1201DC for ; Thu, 19 Dec 2019 14:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3H9tgdCWIYCC for ; Thu, 19 Dec 2019 14:30:24 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D029E1200CC for ; Thu, 19 Dec 2019 14:30:23 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBJMUGXq018904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Dec 2019 17:30:18 -0500 Date: Thu, 19 Dec 2019 14:30:15 -0800 From: Benjamin Kaduk To: Cigdem Sengul Cc: Francesca Palombini , Ace Wg Message-ID: <20191219223015.GO81833@kduck.mit.edu> References: <75220EAA-9455-4691-9E99-3E16401D1309@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Review for draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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: Thu, 19 Dec 2019 22:30:27 -0000 On Wed, Dec 18, 2019 at 03:47:04PM +0000, Cigdem Sengul wrote: > Dear Francesca, > > Thank you for your responses to my comments. > My comments are inline. > > > > > > > In the following, I list a few things reading the draft made me think, > > especially in its applicability to MQTT: > > > > (1) What is planned to make this document a generic pubsub solution? Will > > there a generic architecture section, and specific descriptions for each of > > the protocols? > > > > > > > > FP: Yes, I am planning to make some updates to the text to make this > > generic. In general, I think the structure of the draft will be the same, > > but each section would either have a sentence or (if longer text is needed) > > a subsection talking about the different alternatives. For example, Section > > 2 would remove current specific text about CoAP pubsub (only talk about > > general pubsub) and would replace that text with an additional paragraph > > mentioning that the pubsub protocol can be CoAP or MQTT. Section 3 would > > have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, etc. > > > > > > > > CS: YEs, sounds good. > > > > For instance, if an MQTT client implements this, the client would talk to > > AS1 to get a token based on the way we describe in the mqtt-tls profile, > > and then get keying material for topics from AS2. > > > > I expect the MQTT client would use a different profile name like > > mqtt_tls_app to signal to AS1 that it is supporting the application layer > > security. This is because the draft hints that there should be a policy > > agreement between AS1 and AS2: “Note that AS1 and AS2 might either be > > co-resident or be 2 separate physical entities, in which case access > > control policies must be exchanged between AS1 and AS2, so that they agree > > on rights fo joining nodes about specific topics.” > > > > > > > > FP: That is all correct. Moreover, we can also discuss details such as > > what communication protocol the Client uses to talk to AS2. Right now > > ace-key-groupcomm is only defined for CoAP, but if MQTT prefers to use > > HTTP, that is very easy to define. > > > > > > > > > > (2) If we keep AS1 as the mqtt-tls profile AS, then for consistency sake, > > the MQTT client would expect to talk to HTTPS to AS2, but the coap-pubsub > > draft describes these, expectedly, in CoAP. Will there be support for HTTPS? > > > > > > > > FP: I promise I did not read this question before answering the text above > > :) Yes. This is really easy to specify, we already do this with CBOR/JSON, > > in ace-key-groupcomm: > > > > > > > > The ACE framework is based > > > > on CBOR [RFC7049], so CBOR is the format used in this specification. > > > > However, using JSON [RFC8259] instead of CBOR is possible, using the > > > > conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. > > > > > > > > We would add CoAP/HTTP in the same way ("CoAP is default, but HTTP works > > the same way"). Then the pubsub-profile could specify which protocol is > > used in the different profiles. > > > > CS: Cool. Because, I imagine a client or its AS would follow the same > protocol, HTTPS, to talk to the ASes, and then talk to MQTT to RS. > > > > (3) In the mqtt_tls profile, the AS grants tokens that identify both > > “publish” and “subscribe” rights and the topics by adding scopes in the > > format, e.g. “publish_topic1” “subscribe_topic2/#”.. This format allows > > representing all publish/subscribe permissions concisely for the client > > which may be acting both as a publisher and a subscriber. > > > > In the coap-pubsub, this is separated between AS1 and AS2. “AS1 hosts the > > policies about the Broker: what endpoints are allowed to Publish on the > > Broker.” “The AS2 hosts the policies about the topic: what endpoints are > > allowed to access what topic. “ > > > > The coap-pubsub also permits that AS1 can host policies about what > > endpoints are allowed to Subscribe to the Broker. > > > > > > > > However, wouldn’t this separation between AS1 and AS2 have the following > > issue: Publisher P, having the permission to publish to topic1 and hence, > > successfully getting an access token from AS1, then goes ahead and sends a > > PUBLISH on topic 2, which it doesn’t have a right to publish. > > > > Wouldn't the broker would pass this message to subscribers, and the > > subscribers would discard the message because the publisher does not belong > > to their “publishers list” (subscribers have all the public keys of all > > publishers). Have I missed something, does the draft protect against this > > at the broker? > > > > > > > > FP: No, the broker would not accept this message. In fact, during the ACE > > exchange between Publisher, AS1, and Broker, the Publisher would post a > > token to the Broker that contains the resource it is allowed to publish to, > > namely in this case topic 1. If it does have rights to publish to topic 2 > > as well, that would be included in the token. That is covered by the > > transport profile used, as you mentioned (MQTTL-TLS/CoAP OSCORE). > > Orthogonally to this, when getting the keys from AS2 to protect the > > publication, if the Publisher has tried to publish to topic 2 without > > having the correct content encryption keying material, the decryption of > > the publication at the subscriber would fail even before signature > > verification. But the Subscriber would not get the publication if the > > Publisher is not authorized to publish on that topic. Note that if the > > owner wants to protect topic 1 and topic 2 with the same keying material, > > that is possible, but then the case above would not be an attack but an > > acceptable scenario (Publisher allowed to post to both topics, publication > > protected with the same key). > > > > CS: OK, it wasn't clear to me what the scope of the token for the publish > permission the Publisher P got from the AS1. It read as it got a token that > just said Publish, without constraining the resource. Your explanation now > clarifies this, and maybe it should be put in the text as well how publish > tokens are scoped. > > > > > Differently, with the current way mqtt_tls scopes are described, AS1 would > > need to know not only who can publish or subscribe, but also the policies > > on topics. > > > > > > > > FP: By policies on AS1 I mean exactly that: "what endpoints are allowed to > > publish on what topics". If one wants to control who can subscribe, that > > would also be part of the so-called policies. > > > > CS: Yes, this is more clear now. > > > > > > > > (4) That brings me to another point regarding this note in coap-pubsub > > profile. The profile says: “How the policies are exchanged [between AS1 and > > AS2] is out of scope for this specification.” I wonder whether the token > > the client gets from AS1 should also be usable towards AS2, and AS2 is > > replaced with an RS for retrieving the keying material for topics (more on > > this later), i.e., AS2 does not need to host/manage/coordinate policies > > with AS1. > > > > > > > > FP: That is a possibility. Right now this is not the case because I > > thought it would be better to keep the two ("authorization to publish on > > one or more topics on Broker" and "authorization to get encryption keys for > > one or more topics") independent. The reason for that was that the same key > > could be used for several topics, i.e. Publisher P could be allowed to > > publish on topic 1 but not on topic 2, even though topic 1 and 2 use the > > same encryption key. Yes, that could be a way to do it, but I am not sure > > about the advantage, apart from the obvious policies synchronization (i.e.. > > in this way there would be no need for synchronizing since in practice AS1 > > would know both what topic Publisher P can publish to and what content > > encryption key it can retrieve). But I'd be happy to discuss that further.. > > > > > CS: I could not understand the reason for two ASes: "Publisher P could be > allowed to publish on topic 1 but not on topic 2, even though topic 1 and 2 > use the same encryption key." > In my head, AS1 would grant a token that would tell Client C what > publish/subscribe permissions they have. > Client C submits the token to AS2, which returns the encryption keys for > these topics. > Client C submits the token to RS, which checks what publish/subscribe > permissions the Client has - it would not allow client C to publish to > topic 2, if it doesn't have permission. > But client C can subscribe (if the token says it can) to topic 2 and use > the same encryption key as topic 1 to read the messages. > > A JWT/CWT can have multiple audiences as an array, so the token can be used > for both. > To me, the advantage of not having to synchronise policies in two > different ASes would be considerable. > > > > > > > In MQTT token scopes, we also accepted that a publisher represents its > > PUBLISH rights with topic filters (note a PUBLISH message cannot be sent to > > a filter, but the topic filters are useful in summarising permissions). > > > > Let’s assume there is a publisher with scope > > “publish_sport/tennis/+/rankings“? > > > > > > > > FP: The first question I have is if it is even possible to indicate scope > > like this in ACE. I do not think so (and please correct me if I am wrong), > > and in this case the scope would have to be expressed as the union of the > > following URIs: publish_sport/tennis/player1/rankings and > > publish_sport/tennis/player2/rankings > > > > CS: This is possible in the mqtt_tls profile because MQTT accepts topic > filters. And, we defined our scopes such as publish_topic1/# > subscribe_+/topic2 etc. > > > > > > Then being a part of all groups (player 1 and player2) is too general as > > this publisher cannot publish to everything but only to “rankings”. > > > > > > > > FP: But once the scope is expressed for "rankings" only, then the doc > > should cover this case too. Then it is up to the topic owner (and reflected > > on the AS2) to decide if the keying material is the same for rankings and > > for the upper-topics (? as opposed to sub-topic) player1 and player2. And > > similarly, it will be up to the broker to verify that the authorization for > > publishing to rankings is separate from publishing to player1 and player2.. > > It is also a valid case to make it so sub-topics inherit authorizations, > > but that would be up to the application to decide. Anyway, these are all > > valid considerations that need to be made in the document. > > > > CS: I see that I wasn't clear in my thinking before and mixed up things. I > was trying to understand how groups map to topics and the topic hierarchy; > and how group maintenance scales with the increasing number of topics, > publisher and subscribers. Said another way, who creates groups, and > creates/updates keys for these groups to be maintained in the KDC? > > I agree topic hierarchies require more thought. Here is my second attempt > at explaining my thinking, which is by no means complete: > In MQTT, it is possible to publish to all levels in a topic hierarchy e.g., > if you have sport/tennis/player1/rankings, it is possible to publish to the > sport, sport/tennis, sport/player1, sport/player1/rankings... > One option is to have as many keys as the nodes on the hierarchy > independent of actual publishers and subscribers to them. (Assuming this > hierarchy is pre-built, and AS2 maintains a complete topic-key database). > So, if publisher P1 comes with rights to publish to sport/tennis - he gets > the keys for that. But, if he comes with the right to publish to > sport/tennis/#, he gets multiple keys, one each for every node under > tennis. Having to always send all the keys would get frustrating (and/or expensive in terms of bytes!), but the "other option" below feels quite messy with respect to having to push out updates when membership/number of groups changes. I suppose the right balance depends on actual usage patterns, but I would mostly expect a flow where permissions on a hierarchy grant the ability to get any (per-topic) key from the hierarchy, but you still have to explicitly request the individual key for the individual topics you are going to post to, to be of most generic applicability. Am I forgetting a reason why that's not possible? Thanks, Ben > The other option is creating groups dynamically and subtopics inherit > authorisations (as captured by the wildcards), i.e., publisher and > subscribers that have an exact match in their topic filters form a group. > Going back to the previous example, assuming AS2 is generating the keys > (need to read the groupcomm in detail to understand how the KDC and its > endpoints work in general), I imagine something like this may work: > Publisher P1 - publish_sport/tennis/# -> AS2 checks if a matching group > exists, doesn't find one, generates the key, and hands it out to P1, stores > the mapping. > Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching group > exists, find one, gives out the key to P2. > Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching group > exists, find one, gives out the key to S1. Until now, assumed no rekeying > when the new members join an existing group, as this would work well with > MQTT RETAIN option, which enables the publisher to indicate > to the Broker that it should store the most > recent message for the associated topic. Hence, the new subscribers > can receive > the last sent message from the publisher of that particular topic > without waiting > for the next PUBLISH message. > Subscriber S2 - publish_sport/tennis/+/rankings - AS2 checks if a matching > group exists, does not find an exact match -> generates new key, but then > needs to update P1, P2, S1 as well as publish_sport/tennis/+/rankings will > be sent encrypted with the new key, and the rest will be with the old key. > When they are rekeyed, the publishers may send RETAINED messages again with > the new key. > > i.e., > P1-P2-S1 are one group > P1-P2-S1-S2 would be another group > Two groups - two keys. > > Do not know what is best, or there is a third option. > > Another thing to consider would be rekeying policies of course. > > > > > > Another approach could be each publisher creating its group. This way the > > number of groups scales with the number of publishers (and the COSE keys is > > per publisher). > > > > > > > > FP: I don't think this scales well, but yes, an application could also do > > this. > > > > CS: Yes, scratch that - that actually wouldn't work. > > Thanks, > --Cigdem > > > > > > > > > Kind regards, > > > > --Cigdem > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Dec 19 16:47:42 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F7E12008C; Thu, 19 Dec 2019 16:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 WKrz3AD_Hzgi; Thu, 19 Dec 2019 16:47:39 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BA6120044; Thu, 19 Dec 2019 16:47:39 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBK0lSMZ021069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Dec 2019 19:47:30 -0500 Date: Thu, 19 Dec 2019 16:47:28 -0800 From: Benjamin Kaduk To: Alexey Melnikov Cc: The IESG , draft-ietf-ace-coap-est@ietf.org, ietf@augustcellars.com, ace-chairs@ietf.org, ace@ietf.org Message-ID: <20191220004728.GF35479@kduck.mit.edu> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 00:47:41 -0000 On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ace-coap-est-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this well written document. I have a couple of small DISCUSS > points and a few minor comments/questions that I would like to discuss. > > DISCUSS: > > 5.4. Message Bindings > > o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- > Format, Block1, Block2, and Accept. These CoAP Options are used > to communicate the HTTP fields specified in the EST REST messages. > The Uri-host and Uri-Port Options can be omitted from the COAP > message sent on the wire. > > The statement above > > When omitted, they are logically > assumed to be the transport protocol destination address and port > respectively. Explicit Uri-Host and Uri-Port Options are > typically used when an endpoint hosts multiple virtual servers and > uses the Options to route the requests accordingly. > > and the last quoted statement: How can the sender know whether or not it is Ok > to omit Uri-Host/Uri-Port? How do you know when you need to send SNI to a TLS server? "If you try without and get a strange certificate back." I think that a similar situation is possible here, though of course you may just know from out-of-band configuration. > 7. Parameters > > It is recommended, based on experiments, > to follow the default CoAP configuration parameters ([RFC7252]). > However, depending on the implementation scenario, retransmissions > and timeouts can also occur on other networking layers, governed by > other configuration parameters. When a change in a server parameter > has taken place, the parameter values in the communicating endpoints > MUST be adjusted as necessary. > > The last sentence: use of MUST with passive voice is really unhelpful here. > Adjusted by whom? How can this MUST be satisfied? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Comment: > > 5.1. Discovery and URIs > > Clients and servers MUST support the short resource EST-coaps URIs. > > Just to clarify: the original EST URIs are prohibited in COAP-EST? My understanding is that the servers also have to support the original (long) EST paths. -Ben > In 5.8: > > In the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key which is encrypted by the client-defined (in the CSR) > > I would break up this sentence into 2 to make it clearer, as I initially read > this as 2 encryption operations applying to the generated private key itself. > So I suggest something like: > > In the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key. The symmetric key itself is encrypted by the client-defined > (in the CSR) > > asymmetric public key and is carried in an encryptedKey attribute in > a KeyTransRecipientInfo structure. > > Finally, if the asymmetric > encryption key is suitable for key agreement, the generated private > key is encrypted with a symmetric key which is encrypted by the > client defined (in the CSR) asymmetric public key and is carried in > an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. > > As above. > > From nobody Thu Dec 19 17:16:57 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9BC1200F8; Thu, 19 Dec 2019 17:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DpWu6-wRUcZz; Thu, 19 Dec 2019 17:16:49 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2C0120044; Thu, 19 Dec 2019 17:16:48 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 19 Dec 2019 17:16:42 -0800 From: Jim Schaad To: 'Benjamin Kaduk' , 'Alexey Melnikov' CC: 'The IESG' , , , References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> In-Reply-To: <20191220004728.GF35479@kduck.mit.edu> Date: Thu, 19 Dec 2019 17:16:38 -0800 Message-ID: <019a01d5b6d3$23aef180$6b0cd480$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLcvhTHaO8I83/53/XdTkaf/jyT9AHpD1bbpaTcYFA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 01:16:51 -0000 -----Original Message----- From: Benjamin Kaduk Sent: Thursday, December 19, 2019 4:47 PM To: Alexey Melnikov Cc: The IESG ; draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: Re: Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ace-coap-est-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this well written document. I have a couple of small > DISCUSS points and a few minor comments/questions that I would like to discuss. > > DISCUSS: > > 5.4. Message Bindings > > o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- > Format, Block1, Block2, and Accept. These CoAP Options are used > to communicate the HTTP fields specified in the EST REST messages. > The Uri-host and Uri-Port Options can be omitted from the COAP > message sent on the wire. > > The statement above > > When omitted, they are logically > assumed to be the transport protocol destination address and port > respectively. Explicit Uri-Host and Uri-Port Options are > typically used when an endpoint hosts multiple virtual servers and > uses the Options to route the requests accordingly. > > and the last quoted statement: How can the sender know whether or not > it is Ok to omit Uri-Host/Uri-Port? How do you know when you need to send SNI to a TLS server? "If you try without and get a strange certificate back." I think that a similar situation is possible here, though of course you may just know from out-of-band configuration. [JLS] That is the exact case that I was about to bring up. Of course you can always send the SNI for TLS because there is lots of "space" in the TCP connection to hold it. This is targeted at the case where you have multiple CoAP servers sitting on the same address/port pair. I think this is going to be a very rare case as the use of an additional port or address is fairly simple and the savings on the wire of not including the host and port options can be significant. > 7. Parameters > > It is recommended, based on experiments, > to follow the default CoAP configuration parameters ([RFC7252]). > However, depending on the implementation scenario, retransmissions > and timeouts can also occur on other networking layers, governed by > other configuration parameters. When a change in a server parameter > has taken place, the parameter values in the communicating endpoints > MUST be adjusted as necessary. > > The last sentence: use of MUST with passive voice is really unhelpful here. > Adjusted by whom? How can this MUST be satisfied? [JLS] My assumption is that is this going to be done either by a congestion protocol, a couple have been looked at in the CoRE working group. It could also be done by a provisioning agent or by a firmware update. Lots of options but no specific one is required. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Comment: > > 5.1. Discovery and URIs > > Clients and servers MUST support the short resource EST-coaps URIs. > > Just to clarify: the original EST URIs are prohibited in COAP-EST? My understanding is that the servers also have to support the original (long) EST paths. [JLS] My understanding is that the short names MUST be supported. Support for the long names is optional and would probably be implemented as aliases on the server side. I would not expect clients to use the long names as they consume more network bandwidth (hence the short names). A server is very likely to support both the long and short names if it is supporting both EST and COAP-EST. jim -Ben > In 5.8: > > In the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key which is encrypted by the client-defined (in the > CSR) > > I would break up this sentence into 2 to make it clearer, as I > initially read this as 2 encryption operations applying to the generated private key itself. > So I suggest something like: > > In the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key. The symmetric key itself is encrypted by the > client-defined (in the CSR) > > asymmetric public key and is carried in an encryptedKey attribute in > a KeyTransRecipientInfo structure. > > Finally, if the asymmetric > encryption key is suitable for key agreement, the generated private > key is encrypted with a symmetric key which is encrypted by the > client defined (in the CSR) asymmetric public key and is carried in > an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. > > As above. > > From nobody Thu Dec 19 17:32:42 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39B812008C; Thu, 19 Dec 2019 17:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 urpFX7m8Vm-K; Thu, 19 Dec 2019 17:32:38 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F01120044; Thu, 19 Dec 2019 17:32:38 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 19 Dec 2019 17:32:31 -0800 From: Jim Schaad To: 'Roman Danyliw' , 'The IESG' CC: , , References: <157653372668.24465.13819182999807823012.idtracker@ietfa.amsl.com> In-Reply-To: <157653372668.24465.13819182999807823012.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2019 17:32:29 -0800 Message-ID: <019b01d5b6d5$59ada860$0d08f920$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL6ES2/zSF2Y3SLlxht7KTHZFYyzqV5hUzw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 01:32:41 -0000 A couple of comments below. See [JLS] -----Original Message----- From: Roman Danyliw via Datatracker =20 Sent: Monday, December 16, 2019 2:02 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; Jim Schaad = ; ace-chairs@ietf.org; ietf@augustcellars.com; = ace@ietf.org Subject: Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: = (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 4. Per =E2=80=9Cthe DTLS connections SHOULD only be kept = alive for EST messages that are relatively close to each other=E2=80=9D, = I think the text means that some EST messages are more likely to occur = one after another. It would be worth being clearer what these would be. * Section 5.1. Per =E2=80=9CThese URIs are shorter than the ones in = [RFC7030]=E2=80=9D, does Table 1 imply that when using EST-coaps the = =E2=80=9Clonger names=E2=80=9D from RFC7030 wouldn=E2=80=99t be valid? [JLS] This is being addressed via Alexey's discuss I think. * Section 5.2 Per =E2=80=9CThe latter ones are deemed to expensive = =E2=80=A6=E2=80=9D, was difficult to parse as the sentence prior has = three things (instead of two). Is this sentence referring to the = =E2=80=9Cnot specified functions=E2=80=9D only? * Section 5.3, Per =E2=80=9C30% smaller payload for DER-encoded = ASN.1=E2=80=9D, if you can cite this metric, please do. [JLS] Do you really need a metric on the difference between the size of = raw binary vs base6 encoded binary? It is just 3 bytes vs 4 bytes (i.e = 4/3) * Section 5.8. Per =E2=80=9CIn summary, the symmetrically encrypted key = is included in the encryptedKey attribute in a KEKRecipientInfo = structure=E2=80=9D, if this is done in a server-side key generation = scenario, where is the client getting the key to decrypt the server = computed key material? Should the DecryptKeyIdentifier/ = AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per = Sections 4.4.1.1/4.4.1.2 of RFC7030? [JLS] That would be the discussion of these attributes in paragraph 3 = (about the middle)? Or are you looking for something more? * Section 10.1. Per =E2=80=9CWhen server-side key generation is used, = the constrained device depends on the server to generate the private key = randomly, but it still needs locally generated random numbers for use in = security protocols, as explained in Section 12 of [RFC7925].=E2=80=9D, = is the =E2=80=9Csecurity protocols=E2=80=9D referenced here anything = beyond DTLS? * Section 10.1. Per =E2=80=9CIn such occasions, checking the = certificate revocation status or authorizing the client using another = method is important for the server to ensure that the client is to be = trusted.=E2=80=9D -- does this text suggest that expired+revoked certificates should not = be used? [JLS] Yes, a revoked certificate would most likely not be used. = However, my personal expectation is that this would map more directly to = a database associated with the CA as it is possible that the = manufacturer could have gone under and not be doing CRLs in any event. Jim Schaad -- to word-smith: s/for the server to ensure that the client is to be trusted/for the = server to raise its confidence that the client can be trusted/ * Section 10.1. Per =E2=80=9CMore information about recommendations of = TLS and DTLS are included in [BCP195]=E2=80=9D, thanks for referencing BCP195. = Could you please clarify with normative language if these recommendations SHOULD/MUST be = followed? * Editorial - Section 4. Per =E2=80=9CAuthenticating and negotiating DTLS keys = requires resources on low- end endpoints and consumes valuable = bandwidth=E2=80=9D, I=E2=80=99m not sure this sentence is needed. = Technically, =E2=80=9Cauthenticating and negotiating DTLS keys requires = resources=E2=80=9D on any endpoint. - Section 4. OLD: Given that after a successful enrollment, it is more likely that a = new EST transaction will take place after a significant amount of time, = NEW: Given that after a successful enrollment, it is more likely that a = new EST transaction will not take place for a significant amount of = time, - Section 5.5. Typo. s/successfull/successful/ - Section 5.8. s/Such scenarios could be when it is =E2=80=A6/Such = scenarios apply when it is =E2=80=A6/ - Section 5.8. s/ client, or when the resources/client, when the = resources/ - Section 5.8. s/Then the private key/The private key/ From nobody Thu Dec 19 20:50:21 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC1F12012A; Thu, 19 Dec 2019 20:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=B/n52XOm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=X+nmdQqp 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 U5bW3hWF58L0; Thu, 19 Dec 2019 20:50:16 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A461200D6; Thu, 19 Dec 2019 20:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2866; q=dns/txt; s=iport; t=1576817416; x=1578027016; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zVOegjdJ1VRdrz1MadJGoenQ2rsnHJH52QCr4AMtv+s=; b=B/n52XOmfZeC9oqWPUQsXn+hFR0LjJWbv/ccqA3gUyTsMxmAzrZzOC1i rfCyfk9DeIWLUeo3vbmVc4oKJ8t38kkKRT0dQq/o6B4ttJeMxyaeGb6ws hLGjSp9vb2g9kB7mAtDdEqt3+gELwKQapk9fH4QNYr1mIVBzwvMmcIliK g=; IronPort-PHdr: =?us-ascii?q?9a23=3AbBQg+h9QBCiCI/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaGAEjjJfjjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUBQCRUvxd/4sNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBTSQsBWxYIAQLKodNA4p0gl+YCIFCgRADVAkBAQEMAQEYCwo?= =?us-ascii?q?CAQGEQAKCHCQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBECgGAQEsCwE?= =?us-ascii?q?LBAIBCBEEAQEeARAnCx0IAgQBDQUIGoMBgkYDLgECDKAMAoE4iGGCJ4J+AQE?= =?us-ascii?q?FgUlBgxMYggwDBoE2jBkagUE/gRFHgkw+gmQBAQECAYEsARIBCRgwgxCCLI0?= =?us-ascii?q?iJKFJCoI0hzKPAYJDh3mQFY5RiFKRfwIEAgQFAg4BAQWBaSJEI1gRCHAVO4J?= =?us-ascii?q?sUBgNjRI4gzuFFIU/dAGBJ41lgjIBAQ?= X-IronPort-AV: E=Sophos;i="5.69,334,1571702400"; d="scan'208";a="688388418" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Dec 2019 04:50:15 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xBK4oFpS023097 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Dec 2019 04:50:15 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 22:50:14 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 22:50:14 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Dec 2019 23:50:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aWaqppXkIJ9lDgdCxgfuyrL6hkTY924rSpgJFjnVzI5WztaM3OiJzAvMX7TJO0oozrDZRoYMfn8GRywalFJO6xstZ7ElHEBav9FhXOVXhJW2PfbWyzWgxUxxaIG1LLYCWQYHQ7l/t8VFjbSzhDkYiuJCzu4wL8Ap1Ajob0PgArA0ZEkgKeOQHLfFm1rDaeAEWBQX5p4z2LkXt+XU7fUc8UTYlHj1XmGm6c9xghdlQt9n5y4sPK8+HDYma5CEV5kIAXq6d1iM1rjTI1w/lKK67CnwW+skNLAn/cHz8t1QeMdcWBtYjutWnsM+Grpokxx+e6KxNbVxKXGjHMUvXlscRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/1DbhiZsfLhaqU9ITCZiu4jp14BfCi1k8m9Y1SsZH+Q=; b=icj9TsHQwyubMHbmVPKfYpJXdTdrE08Kmkp9uZ32XstK6kwgz4hhSuEv5ta98eFdHo2/SM+h+LPJH4YOdXpLjf0BLmMQ5MRif6R3SudNp7ku7R/NBpqjFMcilO2mEerelTuKtyZDBvXZqSTkHKynNYlAKN0RZHM8WF3ihdbsx9BQ1+QGKqeceyJsbRYgOSgY/mQ8DjcNRD377x82w+iVJ4rK6H9krRTfD3ahzFS1NhVxnt7IsvWVdsF7ILFOr0FuzHA9P3tvjYsX35l8LdU8c1fnuTYAMyzcipnuSswExQX3AGqhpcKLNy/LuTULKFSsTSLbpR8v78/Sj3lRhmwQRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/1DbhiZsfLhaqU9ITCZiu4jp14BfCi1k8m9Y1SsZH+Q=; b=X+nmdQqppACzpi949gusOfHZXmaeVvHZDz8H3G5gzH5QPqsN3FyP7BHn1L+rQjj71ZxZp9Vt5VfGti0dUHFh/7C9Navw6uiF+LsaKOmHnNnA83SCApybCtkJ2EDy5LZ2HwcGom1nfT3eZP3gaN71O5gEz2Zk/ybpStUg1uSC/eA= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2707.namprd11.prod.outlook.com (52.135.254.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.17; Fri, 20 Dec 2019 04:50:13 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.016; Fri, 20 Dec 2019 04:50:13 +0000 From: "Panos Kampanakis (pkampana)" To: Alissa Cooper , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Thread-Index: AQHVtREze2mzYAiIIU2GJp/gU3IOXqfCdYQQ Date: Fri, 20 Dec 2019 04:50:12 +0000 Message-ID: References: <157661132422.26387.11388034337323397614.idtracker@ietfa.amsl.com> In-Reply-To: <157661132422.26387.11388034337323397614.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::1c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff1401c8-e772-46fb-82c5-08d785081982 x-ms-traffictypediagnostic: BN7PR11MB2707: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(376002)(136003)(346002)(13464003)(189003)(199004)(55016002)(9686003)(64756008)(81166006)(71200400001)(81156014)(86362001)(8936002)(8676002)(52536014)(5660300002)(966005)(4326008)(478600001)(7696005)(316002)(54906003)(110136005)(33656002)(2906002)(66946007)(66446008)(66476007)(186003)(76116006)(66556008)(6506007)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2707; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EKUv0ipKVG4NBQBPQRdTA3SoJe8ghLT/+UBaqoj0zIwELQVmg4sPyrILF/sGVPq5bWevW38AUpeX5stC6tFFUVyFFn2Uk8jfkWjdwn5abzJYGq+GALtWANI4LnbPaCA5VsRe8qcCffShXSAD+ye8edauaEj/Nx62wFJtk1D2MykY/0fb1COp75kMiVGZeALJZr6w1lpbJ6IWojqltzdUxJjYsWFDogRqYvdv3k4NVIl9SzyUhStbAs90J+Gu79l9jPiLNuPkTrbeRmvIC6UcQFULUE/075rtCj9x1nbaC7w/WE3M07aF3eNmCHv2N6AVhXxkvqwEo0Cj7DQ1Ebp7JUHFzYYRGNzyvXO3e1d30laZZIR+PIQRmThy0w4f4Hr5TpxP5Kvl/7I9gUgydGwpKSMpV+SrIcqbOWmd/BCoA92ZfMFiCQtqq9ED7/XUMdxoeOICn7XLKIivQFWeTsy0SYfJ7X/3rmXrOEb7EjRy0za2zLpY96IS3BWiO6NcdVd/UFsMfR/38vnUdbKjlUXH4Gx4hjVoW/gmeLTj5sd/VGc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ff1401c8-e772-46fb-82c5-08d785081982 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 04:50:12.7992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PgDkGa24qg9FDODNso2kVLZlgNySuSkOeK1cuix6GJNM84SBV0xiLTemAQss+MXq/b9OCYSgVohP0Ogy15739A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2707 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 04:50:19 -0000 Hi Alissa,=20 Thank you for the feedback.=20 > "It is also RECOMMENDED that the Implicit Trust Anchor database used > for EST server authentication is carefully managed to reduce the > chance of a third-party CA with poor certification practices > jeopardizing authentication." >=20 > This strikes me as a slightly odd use of normative language (what are the= exception cases when the trust anchor database should not be carefully man= aged?). >=20 The blurb is directly from RFC7030. We reiterate it here to point it out as= a best practice and then we present a potential deviation from it for cons= trained environments.=20 To avoid this confusion we can rephrase it as=20 As discussed in Section 6 of [RFC7030], it is=20 "RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication. Disabling the Implicit Trust Anchor database after successfully receiving the Distribution of CA certificates response (Section 4.1.3 of [RFC7030]) limits any risk to the first DTLS exchange." [...] Rgs,=20 Panos -----Original Message----- From: Ace On Behalf Of Alissa Cooper via Datatracker Sent: Tuesday, December 17, 2019 2:35 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ie= tf.org; ace@ietf.org Subject: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: = (with COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 10.1: "It is also RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication." This strikes me as a slightly odd use of normative language (what are the e= xception cases when the trust anchor database should not be carefully manag= ed?). _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Dec 19 21:01:26 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C30120124; Thu, 19 Dec 2019 21:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Kp4PUhok; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LdsxpKkj 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 QQdkqnuEx-Y4; Thu, 19 Dec 2019 21:01:17 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37053120045; Thu, 19 Dec 2019 21:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2345; q=dns/txt; s=iport; t=1576818077; x=1578027677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h9dMZdGzzFJcI0o4UcWxoH0ldavaF6a8CdRal7XFPW0=; b=Kp4PUhokBtOTPzcUTYUn93XbjtKD4jyuN37JejG/lU4R+XEdxsAl2Dd6 GA1JXJeHc7RpsNM2vbDscqmkhCnsJnXTzXRPNu42st+Ztl1WipO14qFYC dwYGIEsPOHvKXTjUYhXb6ZY376h6hOipejHdfD8WANDc/oIU+1Vos3Zdx 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AvShc2RZykXsgHu+y15LfgEv/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUBQDhVPxd/4gNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBTVAFbFggBAsqh00DinOCX5gIgUKBEANUCQEBAQwBARgLCgI?= =?us-ascii?q?BAYRAAoIcJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQEBECgGAQEsCwE?= =?us-ascii?q?EBwQCAQgRBAEBHxAnCx0IAgQBDQUIGoMBgkYDDiABAgyfdgKBOIhhgieCfgE?= =?us-ascii?q?BBYFJQYMTGIIMAwaBNowZGoFBP4ERR4JMPoJkAQEBAgGBLAESASEwgxCCLI1?= =?us-ascii?q?GoUkKgjSHMo8BgkOHeZAVjlGIUpF/AgQCBAUCDgEBBYFpImdYEQhwFTuCbFA?= =?us-ascii?q?YDY0SOIM7hRSFP3QBgSeNZYIyAQE?= X-IronPort-AV: E=Sophos;i="5.69,334,1571702400"; d="scan'208";a="386233030" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Dec 2019 05:01:15 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xBK51FW4009546 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Dec 2019 05:01:15 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 23:01:14 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 23:01:14 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 20 Dec 2019 00:01:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OrMRP7RcSiID4qV9Dn+LANcnXYAMhuoik7SNqzjegVIFvs3wZpEsNdsjHo+j5QRJHHE4iQSzQ0Ih9C1Fz85sgS7StxtaH0vUed7PJHtfiwyXAeNYgQHuNqT2ZBjYIDN4ueXDS6nrtCueDeBuzZZAXlE7j79ag6cLBEJx0Weg70RwjWEoxyxkVf5KvdihZyy0N3SQmkhAxj24Mx9UCnhbdU4ub67gYjHvKZErXLpZi8H6R2//CDs73iQGAG4kHG3y6rxuF+X/S8tp0kQHKXQ4Q78t1R94WWRZD6TiDI5Sn/4AL7NEbp4sPUBbSHPSh5WAk4Mcdx2hsWdZn3BscIHeRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I2lblS4F43f+FBzTsihZROZnvkjzK6kIMzpQd7wXNJ0=; b=GmK0osUyTbEelh8xnt9eccaXzWteMFdYZsXhgjv/Q6vOwWHXGd+f8poBOUOnbUKYXMbjZYCxf4ciW1EapXdE0jb9HvnG7NuGUR5iemVWoi9qXCsf+AIVc3lVHKxfaSWqKD7F9xg9Pfx082lA5owqqIHFblKgc2UHlIXxWMITMbr3jzrB60CK3Awc1pMhxomv1nvU7wf1AsBNd2K3sHRpb4tA3hB+63FsAdHfEEzy8JpKH4Bw8ZW+FxT5DVBgI6cJTmKxpTyjmeIRwJcs0H14CYB84bJA2CD42bU3Yv8px3riAs//xLiTHbQBH9F8jQPW4+2ZtkkaJszHYIvuzqjI+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I2lblS4F43f+FBzTsihZROZnvkjzK6kIMzpQd7wXNJ0=; b=LdsxpKkjjsnAMSO7Zdllziz0d7MMLtqdIMVRPR2jMLbRLQ/qazX1JfYi4m2MPelibQy1wgOq8J52w1HUZQg292TulrwfyWSIK3xQ4A1qwJQh5jgvtmUSi7U3jUvUBB3ZWzznoD1LK/ZTIEs1tB6q/qxvJIMVRbnJxvkjexlg/U8= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2657.namprd11.prod.outlook.com (52.135.244.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.15; Fri, 20 Dec 2019 05:01:13 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.016; Fri, 20 Dec 2019 05:01:13 +0000 From: "Panos Kampanakis (pkampana)" To: Magnus Westerlund , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Thread-Index: AQHVtmteNYW1qV2WE0en9EAnACcqDKfCd2Yg Date: Fri, 20 Dec 2019 05:01:13 +0000 Message-ID: References: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> In-Reply-To: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::1c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d39e931-e3fd-433d-77d2-08d78509a307 x-ms-traffictypediagnostic: BN7PR11MB2657: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(366004)(396003)(189003)(199004)(13464003)(55016002)(66476007)(71200400001)(66946007)(53546011)(33656002)(66446008)(64756008)(52536014)(9686003)(81156014)(81166006)(8676002)(8936002)(86362001)(66556008)(186003)(6506007)(76116006)(2906002)(7696005)(110136005)(316002)(54906003)(478600001)(966005)(5660300002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2657; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FA1aO7gVMJZCeyJd6oWuHeupLj1mKRmt5rN4ad371JzQ8tNCLY7CYwcfj6hrLpfwwK65XkcpKcbc0a71bIml1J9ECWtp9xxdrf1WKC3j718H7pvxHXiwFWuF6JGDpNF9jbQweUYrMFHnLg+TH8kKWV8jgVHivTQdFVAkExmtdsF7dWNgoyqbTnDxu+YC60q1RKWG7WtJpG0JpkVmWYi4OCBf/X0r/ISrLXtQEMnWYtqEjH88HdGCIDZuVfHn8Z26VB844nd7dJyZqWcxly99EbUxcDeec0rOFo3fiM1Hs0Gu/XCQ+GdMfFxONSDZu10TWURvrWpDEb69Xkj0KdYa1Qa7fSW+/6R2IHAeiWHeyUzIYGYKUm1hijzJE2UUXuN0gBTLGO7uLXDQz05Nkegx5dqQR5QMM2k5/k3mxMoXDpw/IXUvwUG0Cx800swerpHusEHQpJsYMyEUXQyGfbOwQkxQptNG9nd05TNVWf/UUL1TZlb+yYIFr9t9b4l++x8wk1EmBUryogYMn7sCbNR/VdjDVSjXDvzoq/EMwYSqWSk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5d39e931-e3fd-433d-77d2-08d78509a307 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 05:01:13.1100 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2XH/KKpxhdjix9LbY0XaVr/oJEHnT7Gr4dQXBjc3dl58QurI99UTn/I8iKvj7hyyAXef3kye5eDrbj8I6em7zw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2657 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 05:01:19 -0000 Thanks Magnus.=20 > The EST-coaps client MUST support > Block1 only if it sends EST-coaps requests with an IP packet size > that exceeds the Path MTU. >=20 > I think the requirement for when Block1 is required to be supported in th= e > above sentence is unclear. Is the intention to say: An EST-coaps MUST sup= port > block1 to be capable to send requests that would otherwise result in the > reliance on IP level fragmentation? Yes, that was the intention. We will rephrase it to say [...] The EST-coaps client MUST support Block1 only if it sends large EST-coaps requests that would=20 otherwise result to IP layer fragmentation. Rgs, Panos -----Original Message----- From: Ace On Behalf Of Magnus Westerlund via Datatra= cker Sent: Thursday, December 19, 2019 7:54 AM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ie= tf.org; ace@ietf.org Subject: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (= with DISCUSS) Magnus Westerlund has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 5.6: The EST-coaps client MUST support Block1 only if it sends EST-coaps requests with an IP packet size that exceeds the Path MTU. I think the requirement for when Block1 is required to be supported in the = above sentence is unclear. Is the intention to say: An EST-coaps MUST suppo= rt block1 to be capable to send requests that would otherwise result in the re= liance on IP level fragmentation? _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Dec 19 23:06:42 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31CF120129; Thu, 19 Dec 2019 23:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RCHeB-H-OCRh; Thu, 19 Dec 2019 23:06:38 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FA0120090; Thu, 19 Dec 2019 23:06:38 -0800 (PST) Received: from client-0160.vpn.uni-bremen.de (client-0160.vpn.uni-bremen.de [134.102.107.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47fKY81L87z16rB; Fri, 20 Dec 2019 08:06:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20191220004728.GF35479@kduck.mit.edu> Date: Fri, 20 Dec 2019 08:06:35 +0100 Cc: Alexey Melnikov , draft-ietf-ace-coap-est@ietf.org, ietf@augustcellars.com, ace-chairs@ietf.org, The IESG , ace@ietf.org X-Mao-Original-Outgoing-Id: 598518393.52324-fef29e08be5cb7cc6fc3919841a5ae54 Content-Transfer-Encoding: quoted-printable Message-Id: <954E92C2-647A-49B3-B204-22EFB61BF46B@tzi.org> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 07:06:41 -0000 On Dec 20, 2019, at 01:47, Benjamin Kaduk wrote: >=20 >> The statement above >>=20 >> When omitted, they are logically >> assumed to be the transport protocol destination address and = port >> respectively. Explicit Uri-Host and Uri-Port Options are >> typically used when an endpoint hosts multiple virtual servers = and >> uses the Options to route the requests accordingly. >>=20 >> and the last quoted statement: How can the sender know whether or not = it is Ok >> to omit Uri-Host/Uri-Port? >=20 > How do you know when you need to send SNI to a TLS server? "If you = try > without and get a strange certificate back." I think that a similar > situation is possible here, though of course you may just know from > out-of-band configuration. RFC 7252 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. So there is a clear rule: If the URI has the IP address and port number = (possibly defaulted), respectively, the options can be omitted. This = means you can almost always omit Uri-Port, and can omit Uri-Host if the = URI had an IP address literal. The latter is not unlikely if that URI = came from a resource directory. If the URI had a DNS name and you omit = Uri-Host anyway, you are gambling that the server offers the same = resource under the IP address the DNS name resolves to. Not unlikely = either, but still gambling, unless you have out-of-band information. = Now you might have verified the identity of the server already using a = security protocol, in which case you could have more reason to believe = you are addressing the right resource. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 20 00:29:34 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC31D120041; Fri, 20 Dec 2019 00:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl 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 qd1HwHRiZZaI; Fri, 20 Dec 2019 00:29:31 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC818120018; Fri, 20 Dec 2019 00:29:30 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id 8D00A100E7B43; Fri, 20 Dec 2019 08:29:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=/4h5eoP/QEbbuZjndk FHcgjdvsZS9AGLN26svl8liDY=; b=SbmSFASFIFbKo2Bjk4uqlTyHAtHjdmOubu AR2XvtVREeZndx1dxBV33zSs0aSqCsP6w9DX/4Iy2k2KY6HGPrFCnX2DM2i3U1DV 0KLWqERDRr/si1jyhX2l44FsP4hXVu5MOCDYI1Km6tmtnQ7kYjH1bfKtvFuP2x5o spbU2YjmA= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -8, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2553:2561:2564:2682:2685:2691:2827:2859:2892:2894:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4118:4250:4321:4860:5007:6119:6248:6261:6657:6659:6678:6757:7974:8570:8603:8985:9010:9025:9177:10010:10376:10400:10848:11232:11658:11783:11914:12043:12109:12114:12291:12379:12438:12683:12740:12895:13095:13139:13255:13846:13848:13891:14095:14096:14149:14181:14721:21080:21433:21451:21627:21990:30003:30029:30034:30054:30060:30062:30075:30083:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:1: X-HE-Tag: elbow39_52ccb840d7f46 X-Filterd-Recvd-Size: 7386 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Fri, 20 Dec 2019 08:29:28 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9795a5176b54bd7ef5d0b2820d010139" Date: Fri, 20 Dec 2019 09:29:28 +0100 From: Peter van der Stok To: Carsten Bormann Cc: Benjamin Kaduk , ace-chairs@ietf.org, Alexey Melnikov , ietf@augustcellars.com, The IESG , ace@ietf.org, draft-ietf-ace-coap-est@ietf.org Reply-To: consultancy@vanderstok.org In-Reply-To: <954E92C2-647A-49B3-B204-22EFB61BF46B@tzi.org> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <954E92C2-647A-49B3-B204-22EFB61BF46B@tzi.org> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 08:29:33 -0000 --=_9795a5176b54bd7ef5d0b2820d010139 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed It is probably enough to add to the text of est-coaps: (see section 5.10.1 of RFC7252) Peter Carsten Bormann schreef op 2019-12-20 08:06: > On Dec 20, 2019, at 01:47, Benjamin Kaduk wrote: > The statement above > > When omitted, they are logically > assumed to be the transport protocol destination address and port > respectively. Explicit Uri-Host and Uri-Port Options are > typically used when an endpoint hosts multiple virtual servers and > uses the Options to route the requests accordingly. > > and the last quoted statement: How can the sender know whether or not it is Ok > to omit Uri-Host/Uri-Port? > How do you know when you need to send SNI to a TLS server? "If you try > without and get a strange certificate back." I think that a similar > situation is possible here, though of course you may just know from > out-of-band configuration. RFC 7252 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. So there is a clear rule: If the URI has the IP address and port number (possibly defaulted), respectively, the options can be omitted. This means you can almost always omit Uri-Port, and can omit Uri-Host if the URI had an IP address literal. The latter is not unlikely if that URI came from a resource directory. If the URI had a DNS name and you omit Uri-Host anyway, you are gambling that the server offers the same resource under the IP address the DNS name resolves to. Not unlikely either, but still gambling, unless you have out-of-band information. Now you might have verified the identity of the server already using a security protocol, in which case you could have more reason to believe you are addressing the right resource. Grüße, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --=_9795a5176b54bd7ef5d0b2820d010139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 It is probably enough to add to the text of est-coaps:
(see section 5= =2E10.1 of RFC7252)

Peter

Carsten Bormann schreef op 2019-12-20 08:06:

= On Dec 20, 2019, at 01:47, Benjamin Kaduk <kaduk@mit.edu> wrote:

The statement above

    = ; When omitted, they are logically
     = assumed to be the transport protocol destination address and port
&nbs= p;    respectively.  Explicit Uri-Host and Uri-Por= t Options are
     typically used when an end= point hosts multiple virtual servers and
     = ;uses the Options to route the requests accordingly.

and the las= t quoted statement: How can the sender know whether or not it is Ok
to= omit Uri-Host/Uri-Port?

How do you know when you need to send SNI to a TLS server?  "If = you try
without and get a strange certificate back."  I think tha= t a similar
situation is possible here, though of course you may just = know from
out-of-band configuration.

RFC 7252 says:

   The default value of the = Uri-Host Option is the IP literal
   representing the d= estination IP address of the request message.
   Likewi= se, the default value of the Uri-Port Option is the destination
 =   UDP port.  The default values for the Uri-Host and Uri-Por= t Options
   are sufficient for requests to most server= s.  Explicit Uri-Host and
   Uri-Port Options are = typically used when an endpoint hosts multiple
   virtu= al servers.

So there is a clear rule: If the URI has the IP addr= ess and port number (possibly defaulted), respectively, the options can be = omitted.  This means you can almost always omit Uri-Port, and can omit= Uri-Host if the URI had an IP address literal.  The latter is not unl= ikely if that URI came from a resource directory.  If the URI had a DN= S name and you omit Uri-Host anyway, you are gambling that the server offer= s the same resource under the IP address the DNS name resolves to.  No= t unlikely either, but still gambling, unless you have out-of-band informat= ion.  Now you might have verified the identity of the server already u= sing a security protocol, in which case you could have more reason to belie= ve you are addressing the right resource.

Grüße, Cars= ten

_______________________________________________
Ace mai= ling list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--=_9795a5176b54bd7ef5d0b2820d010139-- From nobody Fri Dec 20 01:33:39 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CD1120820; Fri, 20 Dec 2019 01:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 FNymVp0TFIh7; Fri, 20 Dec 2019 01:33:34 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00068.outbound.protection.outlook.com [40.107.0.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA34120806; Fri, 20 Dec 2019 01:33:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nkYG1b9r2WxmX5up1ySpSeDLt7xpSq+4ATdqSqVRAS+vCE7fEZ80BvFeFSiXjRILH6rRKDUyam2r1gA0tfTCbUUclT2Qs9RyOMRbPJ5NhzG0aCFpts7Qhj+OQIwqUDK0XTCEq/ccEVZ6V7U6TN4GV9tpkm+EXjXbJxTfL5M7Mqb+Wt9d4d/YfpvXGkkDN/7yQ62q/qAV9ipPHahflFzobbwWxdnkUBCNlo+XoL1YI8DWMbi2saPnRxVBvxT7H7EnRXV25C9f4+BpuBK+Sh7TCPgNVT/YAxs3FpF2wEgH59Fl+weCRvMcAgWHxSPTegJGAa9j+UVg9KW1NU/21F6YUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3Lhhjg5s7GUVWyC7ETHDly9kUKW5ldsUnLd7gRr4uX4=; b=XEoLBUc+Km1Ow4BqFHi+zCjenLENYqUZZscKmvDdpWIHIE2RWLHSh0cL+6NI5ei00tKoJlzrHkJluNyb1hZMl0Xi6hn48ofZG+iy29xC7S0hSh2JKv6jgKa6tUooXCJwh0X+6qS3/C5+RsO8ff8ZPmxImq9XRV9oA6IXaSZ8JQOOu6M+S06n//K0idhyEpBKHdZ4nZCYnv9PEPsa7DDJog/bfeIFSQlGlF4lPzbMfX0DbeqfpTPfLVTOnJoMQqwlWvu5GoydyBAY9u00hdYnFBFjcRp0fj4LgD7j9AW0MyPZPiGW6NHaZkUIFo6dII1JpD5lRrt/5F6Sp2VdWwXaBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3Lhhjg5s7GUVWyC7ETHDly9kUKW5ldsUnLd7gRr4uX4=; b=PZQTNaLPoVLRCL7uAsohQuWNevSJYoJlR7jAPh0Plq5HtoB0jRL/EiM08bMPrlkK2sHleSkBQX3R7iqJOaXOx1CJwuo4gLhpR420r5MaDcqIuzcAIQrOuElqzGx0lqvqO31W0Qkqev65tVHxtt7eEgDaQMmfGaKWlcLZ/3LjYKk= Received: from VI1PR07MB5310.eurprd07.prod.outlook.com (20.178.12.13) by VI1PR07MB4479.eurprd07.prod.outlook.com (20.177.53.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.13; Fri, 20 Dec 2019 09:33:30 +0000 Received: from VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64]) by VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64%4]) with mapi id 15.20.2581.007; Fri, 20 Dec 2019 09:33:30 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "pkampana@cisco.com" CC: "ietf@augustcellars.com" , "draft-ietf-ace-coap-est@ietf.org" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Thread-Index: AQHVtmtdqfoUtzXK1U2FXXdGCVFXHqfCeCqA//80zwA= Date: Fri, 20 Dec 2019 09:33:30 +0000 Message-ID: References: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 96d4b61c-b523-4dbd-aa69-08d7852facf5 x-ms-traffictypediagnostic: VI1PR07MB4479: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(366004)(376002)(136003)(346002)(199004)(189003)(86362001)(4326008)(2616005)(5660300002)(4001150100001)(478600001)(81166006)(6506007)(186003)(26005)(316002)(71200400001)(66556008)(44832011)(76116006)(54906003)(110136005)(64756008)(66446008)(66946007)(66616009)(66476007)(91956017)(6486002)(8676002)(36756003)(81156014)(8936002)(6512007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4479; H:VI1PR07MB5310.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KlfKKcu0lX2k7v6j2PfV87d9DYgyF8nszLLdzc7dysLKzEnPZPFcas8x1wO1KtvaDMmdcjRir0U3Bzk1udN//EU8e8AtBfLHJpIdtMz5y2Gj/uZpiAe5gR3128mXGVV9V+qOHhBenuezWS3Ze5XTD0vDsY9aFA8jKzjCEz07jrXHLoWKJO3FPcM3de+bAOZQdNxsmmxX9x/WlXoAYBhpJvV14N2H3aBazuo2KJ9wZ2xOYuNvVzimt5i3nu/QNiiSyV9kOZ9rhpCH3XgpXKYGF0vdp4N8vUajXuz2KBizyb63m9UIMjVaUemFP+e70e6q48c9CjxD9CmoElD76GK7lVQl9oYjhfE6QuQBdMWanmBA9X2K+jEEmJA92NoylNu+P8rc2VPbAx2a82hYuMb2Qv9rslKSv1kXwP8vtdzLtxJ7uwLuCrmPfPdUGepTBApB x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-a6wKM9BZE35ZmHQapU0C" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96d4b61c-b523-4dbd-aa69-08d7852facf5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 09:33:30.6353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7NotTVnckDv154tQFgkXzQhjbdUlL6WYPXUffApfSodrLr1DgaoEAGf09Sf/PSqJ2675G8NtS+/6eMXLCwuuJEPBkMWhR3FYO0aqo4qde9M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4479 Archived-At: Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 09:33:37 -0000 --=-a6wKM9BZE35ZmHQapU0C Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Fri, 2019-12-20 at 05:01 +0000, Panos Kampanakis (pkampana) wrote: > Thanks Magnus.=20 >=20 > > The EST-coaps client MUST support > > Block1 only if it sends EST-coaps requests with an IP packet size > > that exceeds the Path MTU. > >=20 > > I think the requirement for when Block1 is required to be supported in = the > > above sentence is unclear. Is the intention to say: An EST-coaps MUST > > support > > block1 to be capable to send requests that would otherwise result in th= e > > reliance on IP level fragmentation? >=20 > Yes, that was the intention. We will rephrase it to say >=20 > [...] The EST-coaps client MUST support > Block1 only if it sends large EST-coaps requests that would=20 > otherwise result to IP layer fragmentation. >=20 Is it support or use block1 when the request is to big? I think the combina= tion of support and only results in uncertainty towards what the implementor. Ba= sed on this reformulation I have the impression you want to make the implementa= tion optional if the expected EST-coaps request size is less than what the IP MT= U can send without fragmentation. However, that leads me to ask what is the behav= ior of a node that suddenly are faced with a request that is larger. Refuse to = send it with an error or still rely on IP fragmentation? There is always the potential for a request being to large unless implementation support of blo= ck1 is mandated.=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-a6wKM9BZE35ZmHQapU0C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTIxOTE2NTM1OFowLwYJKoZIhvcN AQkEMSIEICxcByWU4PinQ+OpF/Np9gzmllEe9gf3Z8+s3BGLQaJDMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAAWNHvcSOXaLb An0kvii4R+gyCm0O3ps67o5haAUD2v1cCMlR01nY63m6lQB3gA8gv6lxHA7G+gebMNQxS2+MJtdT H+br5h2jhk3jRe9hpq6R6Q8p0wEoGWxqZj5W9Xf1Lo7vlcgL5F9TSczWLaQH7HlbETD74+15iuhS LOiwdnlJe5AGiu7/w6WFUyAXN/HZC8rH8XIkUswA3RjMeB3OsxMR506O21nwjAcxADEmvjLw8lOk EW21vAnj07siBJBU5z2rehoXe0lqZM2f0vota/YcFtzz1rg3DfsOP7hO663K59Dj5K1ROK3MTgkV P1Fa70gFpqV7fpztrw7FOB/YbgAAAAAAAA== --=-a6wKM9BZE35ZmHQapU0C-- From nobody Fri Dec 20 04:03:34 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD08120024 for ; Fri, 20 Dec 2019 04:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 34iT5c8HWvxf for ; Fri, 20 Dec 2019 04:03:29 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 F009B1200B4 for ; Fri, 20 Dec 2019 04:03:16 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id x1so7372379qkl.12 for ; Fri, 20 Dec 2019 04:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RS1DLn6SozrA348tw7mXpK3WV59xo/3LlifALRCiueM=; b=CEdoKGn5NzOmgGDnoa4qb8Z3kBg4l1kCyzNO5aqNI4MUg8bh0qrGvSK6XB2Sig/sYP Hkc4I0IKPp5Ycovts7mM+1SOsRJ2ztu5W04sDUMOWYFrNgu/cw7Z4NqQoc5fwfixf4FW uKMxRFuNR0KMnkmYXL4gtlXMr1qB1qNhC0HNM7g/7jH8g3Bfrqe35BClZJF1k0Qgr29u ccCyyPLiuL7xgERJmHgupnp9nEYPCtWWAcXVRBN8ipVHAMHvVA4759xcRhlfx5IZ0OoQ cX+jq0P8iEDREw24pGsU2RZzVxEb34Qr6sT8uzhY8KDpx6WQBKQwObfn832AfTUWLVVh B74w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RS1DLn6SozrA348tw7mXpK3WV59xo/3LlifALRCiueM=; b=Gku23/th8+eAm7hboxIiLzwsx9fedjqiwLHe0Gj4ulV+2VSMjrwDOrEcnZNcTYfWJc SmEogFk05g7PbaWmf6UahYEjxoExIFGcvvhPl307P1R5kREYkcbx8/zJ5dN2OUThVFO1 y94ToLaE6B1lnQ929ihhGuSu4kWdnlBU/IR7FglOvs3u6p0xKgl3Nle72MNwH3ZqZlVD RJcgJ4wT3/iybYqw1Se7FgEma5Zh9gXa6h91Pq0cWt6vSJSQuEPYri/0N0vsjSiCGizf LAOQ6xh5Y4ab8DQ4RKPAAvndm81+GTnrg6BHKcM8v4mPsFPk7p7ipMLdqs39okWrduBc x73A== X-Gm-Message-State: APjAAAVLQ5cSHjK8+Cx1MehNyveJhoBu/a6cDnDtuM4q5px1vv78Av7F GJFOB6vwy2wkAhXXam0WFitYMEyOcFkjy9PV+oM= X-Google-Smtp-Source: APXvYqxey1OLUMzrmASdro111Z/YEBT3mWlxpi+1+/ewngigCPhsWhlqA6SnnzFs8+kQetE2WqNdzbUhLzCvt1W5A/U= X-Received: by 2002:a05:620a:150e:: with SMTP id i14mr12866871qkk.273.1576843395889; Fri, 20 Dec 2019 04:03:15 -0800 (PST) MIME-Version: 1.0 References: <75220EAA-9455-4691-9E99-3E16401D1309@ericsson.com> <20191219223015.GO81833@kduck.mit.edu> In-Reply-To: <20191219223015.GO81833@kduck.mit.edu> From: Cigdem Sengul Date: Fri, 20 Dec 2019 12:03:04 +0000 Message-ID: To: Benjamin Kaduk Cc: Francesca Palombini , Ace Wg Content-Type: multipart/alternative; boundary="0000000000007a7f57059a217640" Archived-At: Subject: Re: [Ace] Review for draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 12:03:33 -0000 --0000000000007a7f57059a217640 Content-Type: text/plain; charset="UTF-8" Hello Ben, Response below. > > > > > > > CS: I see that I wasn't clear in my thinking before and mixed up things. > I > > was trying to understand how groups map to topics and the topic > hierarchy; > > and how group maintenance scales with the increasing number of topics, > > publisher and subscribers. Said another way, who creates groups, and > > creates/updates keys for these groups to be maintained in the KDC? > > > > I agree topic hierarchies require more thought. Here is my second attempt > > at explaining my thinking, which is by no means complete: > > In MQTT, it is possible to publish to all levels in a topic hierarchy > e.g., > > if you have sport/tennis/player1/rankings, it is possible to publish to > the > > sport, sport/tennis, sport/player1, sport/player1/rankings... > > One option is to have as many keys as the nodes on the hierarchy > > independent of actual publishers and subscribers to them. (Assuming this > > hierarchy is pre-built, and AS2 maintains a complete topic-key database). > > So, if publisher P1 comes with rights to publish to sport/tennis - he > gets > > the keys for that. But, if he comes with the right to publish to > > sport/tennis/#, he gets multiple keys, one each for every node under > > tennis. > > Having to always send all the keys would get frustrating (and/or expensive > in terms of bytes!), but the "other option" below feels quite messy with > respect to having to push out updates when membership/number of groups > changes. I suppose the right balance depends on actual usage patterns, but > I would mostly expect a flow where permissions on a hierarchy grant the > ability to get any (per-topic) key from the hierarchy, but you still have > to explicitly request the individual key for the individual topics you are > going to post to, to be of most generic applicability. Am I forgetting a > reason why that's not possible? > > Thanks, > > Yes, both have problems - mainly used them to talk about the differences between (semi-)static grouping (topics define groups) and dynamic grouping (active publisher/subscribers and their topic permissions determine groups). Yes, a token with scopes that use the wildcard will give you the right to get any key from the hierarchy. In the "first approach," you would need the get the specific one for the individual topic because any number of publisher/subscribers may be on that topic (but not on others). If I understand correctly, you suggest that the client asks for the right key just-in-time before a publish/subscribe message? This is a good solution if the client can connect to AS2 at all times, but in ACE, I thought, we did not assume ASes are always reachable by clients. Therefore, I was always thinking of a scenario where the client is provisioned with the right keys beforehand (determined by their permissions). But the "second option", where the same encryption key may be used across different topics, has the same connectivity requirements due to rekeying expected as groups change. I hinted this in my previous e-mail by having to consider rekeying policies, as I haven't seen it mentioned in coap-pub-sub. Need to also consider rekeying as a separate problem that needs to be addressed regardless of what approach is taken: ace-key-groupcomm refers to [RFC2093], [RFC2094] and [RFC2627] for rekeying mechanisms and I am not exactly sure how to use them for client-broker communication. ace-key-groupcomm also states: If the application requires forward security, the KDC MUST generate new group keying material and securely distribute it to all the current group members but the leaving node, using the message format of the Key Distribution Response" If it is the AS2 (KDC) that needs to rekey groups, then AS2 should be able to connect to the clients and push this information? Am I missing something here? (In MQTT, things were easier when tokens expire. The Broker knows a token expired and disconnects the client, which forces the client to get a new token. But, the Broker here has no idea of rekeying. So, the trigger for that needs to come from AS2. ) Regards, --Cigdem > Ben > > > > The other option is creating groups dynamically and subtopics inherit > > authorisations (as captured by the wildcards), i.e., publisher and > > subscribers that have an exact match in their topic filters form a group. > > Going back to the previous example, assuming AS2 is generating the keys > > (need to read the groupcomm in detail to understand how the KDC and its > > endpoints work in general), I imagine something like this may work: > > Publisher P1 - publish_sport/tennis/# -> AS2 checks if a matching group > > exists, doesn't find one, generates the key, and hands it out to P1, > stores > > the mapping. > > Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching group > > exists, find one, gives out the key to P2. > > Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching group > > exists, find one, gives out the key to S1. Until now, assumed no rekeying > > when the new members join an existing group, as this would work well with > > MQTT RETAIN option, which enables the publisher to indicate > > to the Broker that it should store the most > > recent message for the associated topic. Hence, the new subscribers > > can receive > > the last sent message from the publisher of that particular topic > > without waiting > > for the next PUBLISH message. > > Subscriber S2 - publish_sport/tennis/+/rankings - AS2 checks if a > matching > > group exists, does not find an exact match -> generates new key, but then > > needs to update P1, P2, S1 as well as publish_sport/tennis/+/rankings > will > > be sent encrypted with the new key, and the rest will be with the old > key. > > When they are rekeyed, the publishers may send RETAINED messages again > with > > the new key. > > > > i.e., > > P1-P2-S1 are one group > > P1-P2-S1-S2 would be another group > > Two groups - two keys. > > > > Do not know what is best, or there is a third option. > > > > Another thing to consider would be rekeying policies of course. > > > > > > > > > > Another approach could be each publisher creating its group. This way > the > > > number of groups scales with the number of publishers (and the COSE > keys is > > > per publisher). > > > > > > > > > > > > FP: I don't think this scales well, but yes, an application could also > do > > > this. > > > > > > > CS: Yes, scratch that - that actually wouldn't work. > > > > Thanks, > > --Cigdem > > > > > > > > > > > > > > > Kind regards, > > > > > > --Cigdem > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > --0000000000007a7f57059a217640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ben,=C2=A0
Response below.=C2=A0=C2=A0
=C2=A0>
>

> CS: I see that I wasn't clear in my thinking before and mixed up t= hings. I
> was trying to understand how groups map to topics and the topic hierar= chy;
> and how group maintenance scales with the increasing number of topics,=
> publisher and subscribers. Said another way, who creates groups, and > creates/updates keys for these groups to be maintained in the KDC?
>
> I agree topic hierarchies require more thought. Here is my second atte= mpt
> at explaining my thinking, which is by no means complete:
> In MQTT, it is possible to publish to all levels in a topic hierarchy = e.g.,
> if you have sport/tennis/player1/rankings, it is possible to publish t= o the
> sport, sport/tennis, sport/player1, sport/player1/rankings...
> One option is to have as many keys as the nodes on the hierarchy
> independent of actual publishers and subscribers to them.=C2=A0 (Assum= ing this
> hierarchy is pre-built, and AS2 maintains a complete topic-key databas= e).
> So, if publisher P1 comes with rights to publish to sport/tennis - he = gets
> the keys for that. But, if he comes with the right to publish to
> sport/tennis/#, he gets multiple keys, one each for every node under > tennis.

Having to always send all the keys would get frustrating (and/or expensive<= br> in terms of bytes!), but the "other option" below feels quite mes= sy with
respect to having to push out updates when membership/number of groups
changes.=C2=A0 I suppose the right balance depends on actual usage patterns= , but
I would mostly expect a flow where permissions on a hierarchy grant the
ability to get any (per-topic) key from the hierarchy, but you still have to explicitly request the individual key for the individual topics you are<= br> going to post to, to be of most generic applicability.=C2=A0 Am I forgettin= g a
reason why that's not possible?

Thanks,


Yes, both have problems - mainly used = them to talk about the differences between (semi-)static grouping (topics d= efine groups) and dynamic grouping (active publisher/subscribers and their = topic permissions determine groups).

Yes, a token = with scopes that use the wildcard will give you the right to get any key fr= om the hierarchy. In the "first approach," you would need the get= the specific one for the individual topic because any number of publisher/= subscribers may be on that topic (but not on others).=C2=A0
If I = understand correctly, you suggest that the client asks for the right key ju= st-in-time before a publish/subscribe message?=C2=A0
This is a go= od solution if the client can connect to AS2 at all times, but in ACE, I th= ought, we did not assume ASes are always reachable by clients.
Th= erefore, I was always thinking of a scenario where the client is provisione= d with the right keys beforehand (determined by their permissions).=C2=A0

But the "second option", where the same e= ncryption key may be used across different topics,=C2=A0 has the same conne= ctivity requirements due to rekeying expected as groups change.=C2=A0
=

I hinted this in my previous e-mail by having to consid= er rekeying policies, as I haven't seen it mentioned in coap-pub-sub.= =C2=A0

Need to also consider rekeying as a separat= e problem that needs to be addressed regardless of what approach is taken: = ace-key-groupcomm refers to=C2=A0 [RFC2093], [RFC2094] and [RFC2627] for re= keying mechanisms and=C2=A0I am not exactly sure how to use them for client= -broker communication.=C2=A0

=C2=A0ace-key-groupcomm also states: If the application requires for= ward security, the KDC MUST generate new group keying material and securely= distribute it to all the current group members but the leaving node, using= the message format of the Key Distribution Response"=C2=A0
If it is the AS2 (KDC) that needs to rekey groups, th= en AS2 should be able to connect to the clients and push this information? = Am I missing something here?

(In MQTT, things were easier when tokens expire. The= Broker knows a token expired and disconnects the client, which forces the = client to get a new token. But, the Broker here has no idea of rekeying.=C2= =A0 So, the trigger for that needs to come from AS2. )

Regards,
--Cigdem=C2=A0
=C2=A0=
Ben




<= /div>

=C2=A0

> The other option is creating groups dynamically and subtopics inherit<= br> > authorisations (as captured by the wildcards), i.e., publisher and
> subscribers that have an exact match in their topic filters form a gro= up.
> Going back to the previous example, assuming AS2 is generating the key= s
> (need to read the groupcomm in detail to understand how the KDC and it= s
> endpoints work in general), I imagine something like this may work: > Publisher P1 - publish_sport/tennis/#=C2=A0 -> AS2 checks if a matc= hing group
> exists, doesn't find one, generates the key, and hands it out to P= 1, stores
> the mapping.
> Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching g= roup
> exists, find one, gives out the key to P2.
> Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching = group
> exists, find one, gives out the key to S1. Until now, assumed no rekey= ing
> when the new members join an existing group, as this would work well w= ith
> MQTT RETAIN option, which enables the publisher to indicate
> to the Broker that it should store the most
>=C2=A0 recent message for the associated topic.=C2=A0 Hence, the new su= bscribers
> can receive
> the last sent message from the publisher of that particular topic
> without waiting
> for the next PUBLISH message.
> Subscriber S2 - publish_sport/tennis/+/rankings - AS2 checks if a matc= hing
> group exists, does not find an exact match -> generates new key, bu= t then
> needs to update P1, P2, S1 as well as publish_sport/tennis/+/rankings = will
> be sent encrypted with the new key, and the rest will be with the old = key.
> When they are rekeyed, the publishers may send RETAINED messages again= with
> the new key.
>
> i.e.,
> P1-P2-S1 are one group
> P1-P2-S1-S2 would be another group
> Two groups - two keys.
>
> Do not know what is best, or there is a third option.
>
> Another thing to consider would be rekeying policies of course.
>
>
> >
> > Another approach could be each publisher creating its group. This= way the
> > number of groups scales with the number of publishers (and the CO= SE keys is
> > per publisher).
> >
> >
> >
> > FP: I don't think this scales well, but yes, an application c= ould also do
> > this.
> >
>
> CS: Yes, scratch that - that actually wouldn't work.
>
> Thanks,
> --Cigdem
>
>
>
> >
> >
> > Kind regards,
> >
> > --Cigdem
> >

> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

--0000000000007a7f57059a217640-- From nobody Fri Dec 20 05:47:21 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6941200B9; Fri, 20 Dec 2019 05:47:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157684963578.27425.17203136718588760303@ietfa.amsl.com> Date: Fri, 20 Dec 2019 05:47:15 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-03.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 13:47:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : MQTT-TLS profile of ACE Authors : Cigdem Sengul Anthony Kirby Paul Fremantle Filename : draft-ietf-ace-mqtt-tls-profile-03.txt Pages : 27 Date : 2019-12-20 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-03 https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 20 06:22:48 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB397120045 for ; Fri, 20 Dec 2019 06:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NYGqufK7IjcU for ; Fri, 20 Dec 2019 06:22:45 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 0908912004A for ; Fri, 20 Dec 2019 06:22:45 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id i11so9515845ioi.12 for ; Fri, 20 Dec 2019 06:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bRarJsesXY79irzUMYBqLb4NxEAdLEXwFbSigDnL4hk=; b=HuvQowFoybSVwHYElgpWs3Wg2PGxakRiCkM/HbSmRJOxhCXYOGvxYtqaNQwhMjiC4q WWNVv9p2HgTUVbhrOFPivlNLWExY6omfoOimV+DMB8YFIjdvZ/7UlcmJpwOrnI9AyHiC +Qm0R6M76zcBpz57wYyA/H06tMUNDKXjgFEhplHIrToo51ACwaZ2FpHBKKGASQ/5l0Od a9hf9OSqupt32QXkVkrUl5UBZAwQv1ZUqERPMYDVovO2e5WS2RazzvynglkZhxwRIOON jhXv+lrWn3n8Z7ay4hSgfBdUE1QE8NPKItyIXbAZXglSdGKAVD00LST6DVM5nkLoAGwB lcsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=bRarJsesXY79irzUMYBqLb4NxEAdLEXwFbSigDnL4hk=; b=a+EPBLWby7xLxTe+ldyxL9iskWNsrUUHg9Xmml3Rhd7jZCaIZrqE0R+WLN9t2/RhG5 znwCJ2ImVztxZTtLqSnQ/ennsyiucFkp53nakPQ7aBrwYk8kaqAIV/HwdVGgqcZON08r ognJ7YZIgUqFpcECgfPFv/L+cNh42lp570Dk62R8HH3jQUik3avOU6WTTGt8AXP2Nr0n C0YgKTa59ZDIt+YXmTKUQhT5crfxaOP/MLcitGPKEm6CLSQiO22gFolDo2ZluaX4gYTO S7M57RkC1Rw4cGkcVf1VyYtdoddvGtq85LNvueOClvOhWiMZMBDx8dUxwxtdV6fDvRa3 rfBQ== X-Gm-Message-State: APjAAAU1Qb/37RXwppP6JpKbk/eXUGgftVrwA0TI/uDdWFuRK3wdrRVV M8AKI/T17To4l/40PAq8yeweV++VGcd04EiHV6BW6AGx1i0= X-Google-Smtp-Source: APXvYqzKcPkKzgbrdN/Y5a8RJAGomWLd5LogYCM2B8bxEYRYwjKA8hkpfHWmNIuKLF+8P59E3JvRPZ99g1Nk8vRTJfU= X-Received: by 2002:ae9:f442:: with SMTP id z2mr13691395qkl.130.1576849829608; Fri, 20 Dec 2019 05:50:29 -0800 (PST) MIME-Version: 1.0 References: <157684963590.27425.18418389491676219942.idtracker@ietfa.amsl.com> In-Reply-To: <157684963590.27425.18418389491676219942.idtracker@ietfa.amsl.com> From: Cigdem Sengul Date: Fri, 20 Dec 2019 13:50:18 +0000 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="000000000000f541c2059a22f58a" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-mqtt-tls-profile-03.txt X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 14:22:47 -0000 --000000000000f541c2059a22f58a Content-Type: text/plain; charset="UTF-8" Hello, I've submitted a new version to update my e-mail address, as my affiliation is going to change in the next year. The v03 does have other changes, as I outlined in my previous email, which still needs to be discussed. The main changes are: Version 02 to 03: 1) Added the option of Broker certificate thumbprint in the 'rs_cnf' sent to the Client. 2) Clarified the use of a random nonce from the TLS Exporter for PoP, added to the IANA requirements that the label should be registered. 3) Added a client nonce, when Challenge/Response Authentication is used between Client and Broker. 4) Clarified the use of the "authz-info" topic and the error response if token validation fails. 5) Added clarification on wildcard use in scopes for publish/subscribe permissions 6) Reorganised sections so that token authorisation for publish/subscribe messages are better placed. 7) Clarified protection of Application Message payload as out of scope, and cited draft-palombini-ace-coap-pubsub-profile for a potential solution Thanks, --Cigdem ---------- Forwarded message --------- From: Date: Fri, Dec 20, 2019 at 1:47 PM Subject: New Version Notification for draft-ietf-ace-mqtt-tls-profile-03.txt To: Paul Fremantle , Cigdem Sengul < csengul@acm.org>, Anthony Kirby A new version of I-D, draft-ietf-ace-mqtt-tls-profile-03.txt has been successfully submitted by Cigdem Sengul and posted to the IETF repository. Name: draft-ietf-ace-mqtt-tls-profile Revision: 03 Title: MQTT-TLS profile of ACE Document date: 2019-12-20 Group: ace Pages: 27 URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-tls-profile-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-03 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in an MQTT-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and server authentication. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000f541c2059a22f58a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've submitted a new version= to update my e-mail address, as my affiliation is going to change in the n= ext year.=C2=A0

The v03 does have other changes, a= s I outlined in my=C2=A0previous email, which still needs to be discussed.= =C2=A0

The main changes are:
=C2=A0= Version 02 to 03:
=C2=A01) Added the option of Broker certificate thumbp= rint in the 'rs_cnf' sent to the Client.
=C2=A02) Clarified the = use of a random nonce from the TLS Exporter for PoP, added to the IANA requ= irements that the label should be registered.
=C2=A03) Added a client no= nce, when Challenge/Response Authentication is used between Client and Brok= er.
=C2=A04) Clarified the use of the "authz-info" topic and t= he error response if token validation fails.
=C2=A05) Added clarificatio= n on wildcard use in scopes for publish/subscribe permissions
=C2=A06) R= eorganised sections so that token authorisation for publish/subscribe messa= ges are better placed.
7) Clarified protection of Application Mes= sage payload as out of scope, and cited draft-palombini-ace-coap-pubsub-pro= file for=C2=A0a potential solution

Thanks,
--Cigdem=C2=A0

---------- Forwarded message ---------
Fro= m: <internet-drafts@ietf.org>
Date: Fri, Dec 20, = 2019 at 1:47 PM
Subject: New Version Notification for draft-ietf-ace-mqt= t-tls-profile-03.txt
To: Paul Fremantle <paul.fremantle@port.ac.uk>, Cigde= m Sengul <csengul@a= cm.org>, Anthony Kirby <anthony@anthony.org>



A new version of I-D, draft-ietf-ace-mqtt-tls-profile-03.txt
has been successfully submitted by Cigdem Sengul and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ace-mqtt-tls-profi= le
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE
Document date:=C2=A0 2019-12-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ace
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 27
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-ace-mq= tt-tls-profile-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile<= /a>
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-mqtt-tls= -profile-03

Abstract:
=C2=A0 =C2=A0This document specifies a profile for the ACE (Authentication = and
=C2=A0 =C2=A0Authorization for Constrained Environments) framework to enabl= e
=C2=A0 =C2=A0authorization in an MQTT-based publish-subscribe messaging sys= tem.
=C2=A0 =C2=A0Proof-of-possession keys, bound to OAuth2.0 access tokens, are= used
=C2=A0 =C2=A0to authenticate and authorize MQTT Clients.=C2=A0 The protocol= relies on
=C2=A0 =C2=A0TLS for confidentiality and server authentication.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000f541c2059a22f58a-- From nobody Fri Dec 20 07:47:27 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399D9120106; Fri, 20 Dec 2019 07:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=syO/vlUe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LPm+pN4U 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 QiZ_mPErdMEp; Fri, 20 Dec 2019 07:47:17 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E190212088F; Fri, 20 Dec 2019 07:47:12 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 55978221B6; Fri, 20 Dec 2019 10:47:12 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Fri, 20 Dec 2019 10:47:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=cqsLz0TePuvX6U473mq9JFXhpfcT0Ek XYJjdwIggGaQ=; b=syO/vlUepPdOIScSZ3xycHAMs3ujSoQY18PNZm7uBJ3Ty3w EiMZ79/7XJtvCKd+6atmyGo8Rva1gb/C9QhyYPqvo2NJYo01qUXQ42d+PQ3I0+9K cTBAiaswlZ0S/07fJUknWRhPOBtvtsszfkvZvrNDu22KHNB80OF/yEs0jnyMXw5M 968lrLDq/T9bUMN/Ci38XPDgyZjYOrd9kzvDWurezJOPu7M6MKkO3r7SQ5uhKAz9 KADzzkrsyFZhP8C6t5R39ZDTpRr6qBnrsRMluBIizCv8RLP7iL2FQaj4DNTmUJFC Yva+rdv880fidV49XutSC5gDEgXCV4F7Cn17REw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cqsLz0 TePuvX6U473mq9JFXhpfcT0EkXYJjdwIggGaQ=; b=LPm+pN4UuBO48tTk8b5N6h IouHAe+e0W409nuFkrH2GSqM2YY61h6+QfvuST4FDj7fOuyoONOOaqmQsSbpkpTh 4BVp+i8IvJwUmZaq2vFahw/SgisOXOZtGw0K5P2jP23dJdjheuaiORzI8vVagqxa E8Qu0YOfNPs+sPw1FwnRuVdMwLRjbEiKbHO+0OUTgv7Cq4iNEc0hAxXGVWWtVYem eu/w1ILgQVkn7FnOhp8WDC8STncxMD81AMcf9QVYR9WUUZsGpqu+uhfQeEklYNoP O+RcWeMx89w2guW6UqVQ8FheW8H06pXtaEy4cHYZRuttzxZwltgPSWkuiWrXdfQg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddufedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 89449C200A4; Fri, 20 Dec 2019 10:47:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <019a01d5b6d3$23aef180$6b0cd480$@augustcellars.com> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <019a01d5b6d3$23aef180$6b0cd480$@augustcellars.com> Date: Fri, 20 Dec 2019 15:45:48 +0000 From: "Alexey Melnikov" To: "Jim Schaad" , "Benjamin Kaduk" Cc: "'The IESG'" , draft-ietf-ace-coap-est@ietf.org, ace-chairs@ietf.org, ace@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Ace] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-ace-co?= =?utf-8?q?ap-est-17=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 15:47:20 -0000 Hi Jim, On Fri, Dec 20, 2019, at 1:16 AM, Jim Schaad wrote: > > > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, December 19, 2019 4:47 PM > To: Alexey Melnikov > Cc: The IESG ; draft-ietf-ace-coap-est@ietf.org; > ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org > Subject: Re: Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with > DISCUSS and COMMENT) > > On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- (snip) > > 7. Parameters > > > > It is recommended, based on experiments, > > to follow the default CoAP configuration parameters ([RFC7252]). > > However, depending on the implementation scenario, retransmissions > > and timeouts can also occur on other networking layers, governed by > > other configuration parameters. When a change in a server parameter > > has taken place, the parameter values in the communicating endpoints > > MUST be adjusted as necessary. > > > > The last sentence: use of MUST with passive voice is really unhelpful > here. > > Adjusted by whom? How can this MUST be satisfied? > > [JLS] My assumption is that is this going to be done either by a congestion > protocol, a couple have been looked at in the CoRE working group. It could > also be done by a provisioning agent or by a firmware update. Lots of > options but no specific one is required. I think the text needs clarifying, as it is not clear on that. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Comment: > > > > 5.1. Discovery and URIs > > > > Clients and servers MUST support the short resource EST-coaps URIs. > > > > Just to clarify: the original EST URIs are prohibited in COAP-EST? > > My understanding is that the servers also have to support the original > (long) EST paths. > > [JLS] My understanding is that the short names MUST be supported. Support > for the long names is optional and would probably be implemented as aliases > on the server side. I don't think this is clear, so it should be clarified in the document. > I would not expect clients to use the long names as > they consume more network bandwidth (hence the short names). A server is > very likely to support both the long and short names if it is supporting > both EST and COAP-EST. > > jim > > -Ben > > > In 5.8: > > > > In the case where the asymmetric encryption key is suitable for > > transport key operations the generated private key is encrypted with > > a symmetric key which is encrypted by the client-defined (in the > > CSR) > > > > I would break up this sentence into 2 to make it clearer, as I > > initially read this as 2 encryption operations applying to the generated > private key itself. > > So I suggest something like: > > > > In the case where the asymmetric encryption key is suitable for > > transport key operations the generated private key is encrypted with > > a symmetric key. The symmetric key itself is encrypted by the > > client-defined (in the CSR) > > > > asymmetric public key and is carried in an encryptedKey attribute in > > a KeyTransRecipientInfo structure. > > > > Finally, if the asymmetric > > encryption key is suitable for key agreement, the generated private > > key is encrypted with a symmetric key which is encrypted by the > > client defined (in the CSR) asymmetric public key and is carried in > > an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. > > > > As above. > > > > > > From nobody Fri Dec 20 07:53:05 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1130C1200CC; Fri, 20 Dec 2019 07:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=MD5TxWaJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TYtnff7e 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 ClztuKXtpwuv; Fri, 20 Dec 2019 07:53:01 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3E8120098; Fri, 20 Dec 2019 07:53:01 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AE902223B8; Fri, 20 Dec 2019 10:53:00 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Fri, 20 Dec 2019 10:53:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=mtYNOERUJO0fC/5LXzzuyJdIrRbgr74 qI9yBhCzkLsk=; b=MD5TxWaJ65VMjnCCLwTSR5IRPnreqh2GsY4tzw7S3bMCpUz 15c9iU42naJlmgLkcQRs1iQqxsuAy2F7JpcynWhhToA9afrMlJSHWXPSILFUFpEQ TF0FMVpSixdKpIppcL1MM3Do4HniI6/sbfIJbuLPAw42qpZxD9Ys13ETyx1wW8Cq xmWdAf/U/KXNcxOuVSUZgPt4rtlP88ekdTG7cW8cbdSXZWXEkF88VUpLstibUY4v sfkmtNbuSNF+DIrK9006m+ZqhJuTo2mHijotTGNmpH/bAyOclMP+wink/Rb6bN9t gb4TTSKxLQ2Wyf/em/7f8HPmrv2JTnuthgls7fA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mtYNOE RUJO0fC/5LXzzuyJdIrRbgr74qI9yBhCzkLsk=; b=TYtnff7emT0B7lhwWATVdb T+9YGRJ1ghjRQE2/g1x6LfQLdUro87km4goYO9AT+mZ/3BznrPmAqzRq60IC83+g /OFlYEkY8fNIqB/oHlIr/UVGkj8SlOs6gIIL4GefsE3msa2CKulRLYj/UjRudOwH 2c1QzSdrOWocgD7mpg73URiIcEEPEP1NY6BH1pvDQdJnK/Hd6X4n+svdFr+SWQkg xjTjR3k4rAS+o7iGzitJ7F89i6NMLJnO4EK8fs3c4O+YDcVlurIB3HHom2Wtd/2i zeBK9yEGwV4erUTkZaB3jxx3QrUhr67hr5Zi9P0TLmEbHwqGJh2mHk+S4+aylasA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddufedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 72603C200A4; Fri, 20 Dec 2019 10:53:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <20191220004728.GF35479@kduck.mit.edu> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> Date: Fri, 20 Dec 2019 15:51:38 +0000 From: "Alexey Melnikov" To: "Benjamin Kaduk" Cc: "The IESG" , draft-ietf-ace-coap-est@ietf.org, "Jim Schaad" , ace-chairs@ietf.org, ace@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Ace] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-ace-co?= =?utf-8?q?ap-est-17=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 15:53:03 -0000 Hi Ben, On Fri, Dec 20, 2019, at 12:47 AM, Benjamin Kaduk wrote: > On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker wrote: > > DISCUSS: > > > > 5.4. Message Bindings > > > > o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- > > Format, Block1, Block2, and Accept. These CoAP Options are used > > to communicate the HTTP fields specified in the EST REST messages. > > The Uri-host and Uri-Port Options can be omitted from the COAP > > message sent on the wire. > > > > The statement above > > > > When omitted, they are logically > > assumed to be the transport protocol destination address and port > > respectively. Explicit Uri-Host and Uri-Port Options are > > typically used when an endpoint hosts multiple virtual servers and > > uses the Options to route the requests accordingly. > > > > and the last quoted statement: How can the sender know whether or not it is Ok > > to omit Uri-Host/Uri-Port? > > How do you know when you need to send SNI to a TLS server? "If you try > without and get a strange certificate back." I don't think this is similar. The answer for SNI is that you always include it, unless you don't care. > I think that a similar > situation is possible here, though of course you may just know from > out-of-band configuration. I don't think this kind of attitude is friendly to implementors ;-). Are you really suggesting that implementations should try not to include these options and then retry if that doesn't work? I am tempted to suggest that the text should be change to "SHOULD include Uri-Host and Uri-Port". Basically, if an implementation knows for sure that it is not needed, the SHOULD can be violated, but the recommended default is safe for all cases. Best Regards, Alexey From nobody Fri Dec 20 08:35:21 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD85120859; Fri, 20 Dec 2019 08:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7ceKyZL1FtH4; Fri, 20 Dec 2019 08:35:12 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 41D3A120856; Fri, 20 Dec 2019 08:35:11 -0800 (PST) Received: from mail-qt1-f170.google.com ([209.85.160.170]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iiLF5-0002DW-Ep; Fri, 20 Dec 2019 17:35:07 +0100 Received: by mail-qt1-f170.google.com with SMTP id j5so8657147qtq.9; Fri, 20 Dec 2019 08:35:07 -0800 (PST) X-Gm-Message-State: APjAAAXIfly114+93YUt+ap2tcYP4xQQM18eUrpt3CpW6hWLbk++8dnY UxacY1n+veUViYD8JYlknN4XEeJdEjjvBM91Mrk= X-Google-Smtp-Source: APXvYqx/ZIp4ex0XyQnXMQdjcklao/LvtNM2P7YgDktj6MsZT5sF6gplnxF6Hz5vOQeY10Yu8dBQG1z6ohDV+O62twc= X-Received: by 2002:ac8:1496:: with SMTP id l22mr8353011qtj.38.1576859706386; Fri, 20 Dec 2019 08:35:06 -0800 (PST) MIME-Version: 1.0 References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> In-Reply-To: From: Klaus Hartke Date: Fri, 20 Dec 2019 17:34:30 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Alexey Melnikov Cc: Benjamin Kaduk , draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, The IESG , Ace Wg Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1576859712; 79f84883; X-HE-SMSGID: 1iiLF5-0002DW-Ep Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 16:35:14 -0000 Alexey Melnikov wrote: > I am tempted to suggest that the text should be change to "SHOULD include Uri-Host and Uri-Port". Basically, if an implementation knows for sure that it is not needed, the SHOULD can be violated, but the recommended default is safe for all cases. I would prefer if draft-ietf-ace-coap-est didn't say anything here, since the Uri-Host and Uri-Port options and whether they should be omitted or not is entirely specified by CoAP [RFC7252].* At most, draft-ietf-ace-coap-est can give some implementation guidance. I don't really see why that's necessary, though, since the implementation of Uri-Host and Uri-Port is the same for all CoAP-based applications and not specific to EST. Klaus *(In short, RFC 7252 specifies that Uri-Host and Uri-Port are omitted if and only if their respective default values are desired.) From nobody Fri Dec 20 09:16:45 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E51120856; Fri, 20 Dec 2019 09:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zeKOq0fCBUtC; Fri, 20 Dec 2019 09:16:37 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBF212084D; Fri, 20 Dec 2019 09:16:36 -0800 (PST) Received: from client-0217.vpn.uni-bremen.de (client-0217.vpn.uni-bremen.de [134.102.107.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47fb4y5wV6zyg7; Fri, 20 Dec 2019 18:16:34 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 20 Dec 2019 18:16:34 +0100 Cc: Alexey Melnikov , ace-chairs@ietf.org, Jim Schaad , Benjamin Kaduk , Ace Wg , draft-ietf-ace-coap-est@ietf.org, The IESG X-Mao-Original-Outgoing-Id: 598554992.0074691-622427a0318bbcc9521cfa7353f2f505 Content-Transfer-Encoding: quoted-printable Message-Id: <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> To: Klaus Hartke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 17:16:39 -0000 On Dec 20, 2019, at 17:34, Klaus Hartke wrote: >=20 > I would prefer if draft-ietf-ace-coap-est didn't say anything here, > since the Uri-Host and Uri-Port options and whether they should be > omitted or not is entirely specified by CoAP [RFC7252].* Klaus has an important point here. We need to be **much more** vigilant about specifications messing with = their normative references. Saying how they are used, yes, but re-stating (or, worse, = re-interpreting) normative material from those references is prone to = creating dialects that no longer interoperate with their unadulterated = originals. Unless these are hopelessly broken(*) and this is the only = way to fix them, this is a MUST NOT. Gr=C3=BC=C3=9Fe, Carsten (*) the normative reference EST has an example for that case: The use of = content-transfer-encoding with HTTP, which is explicitly ruled out in = Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was = a count of RFC 7030 messing with a normative reference, and in turn = **needed** to be messed with in CoAP-EST (and eventually needs to be = fixed in the parent specification, too). From nobody Fri Dec 20 09:18:52 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EF2120875; Fri, 20 Dec 2019 09:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KlP5YQDY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=k8rUeJFg 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 ZFyClXDemLqg; Fri, 20 Dec 2019 09:18:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CF8120882; Fri, 20 Dec 2019 09:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4594; q=dns/txt; s=iport; t=1576862325; x=1578071925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=expOafzG4ySvb8SnnC3y8kh5Rt+bK6ZrnTkl7O2Iv88=; b=KlP5YQDY//TD5RhfoisPS1aFJtfrGU98515cBLMq8tMSghBVh0ZAS+VN rXX1zY4F6gR8gxs2AnYfRY5n5lHosedKCZpO9DyVyShm9cpIueVFQBE7w DGrIIZnQouzcD98HNb4f8D6LInqLXoHGIzvC0Sm33UaCLjo8iohLcCt7i Y=; IronPort-PHdr: =?us-ascii?q?9a23=3ARZKkdR3arZsDrax5smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEU7yKebjaSUSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAQCeAf1d/5hdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBfIFNJCwFgUQgBAsqCoN9g0YDinOCX5gIglIDVAkBAQE?= =?us-ascii?q?MAQEtAgEBhEACF4IFJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDEhERDAE?= =?us-ascii?q?BNwELAgICAQgRBAEBAQICIwMCAgIZFxQBCAgCBAENBQgahUcDLgECoHcCgTi?= =?us-ascii?q?IYXWBMoJ+AQEFhRsYggwJBYEJKIwZGoFBP4ERR4JMPoQzGBWCeTKCLI1HgnG?= =?us-ascii?q?eWQqCNJYzmlWOUZpUAgQCBAUCDgEBBYFpIiqBLnAVgydQGA2NEjiDO4pTdIE?= =?us-ascii?q?okSoBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,336,1571702400"; d="scan'208";a="674427903" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Dec 2019 17:18:44 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xBKHIifg019585 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Dec 2019 17:18:44 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Dec 2019 11:18:43 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Dec 2019 12:18:42 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 20 Dec 2019 12:18:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T3RRziGa1z6z0cUrRHRe3apHKgx0QCkmsUSgBW9RVApWYmunBGI2wZJm4nXPa5Ha258NCCDmUaisjEPjZsDJrZBXX/QVcW7SnFjBbRLXl+m+qEXPbm2iMOo5WI5rBo7B5oqfQS9WLJxU+ptRZ0Nt2x4dKe81kBcmSfIHjgOnIObu/P700QfEOVCrZQx75xijod9etPwUTcin4JlkDEDavx7HnMkhdSWUiNtvINYjqDsuKXMAAt0BOS+9fn6Des8jwgmHYTos+dTpK5qEi6BP9vVFstP31/KQrco3ocrnJmckH3Vd+UaF+PdxoP4+H4L9BU+Kre+ezZxJI4seDUbvqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=expOafzG4ySvb8SnnC3y8kh5Rt+bK6ZrnTkl7O2Iv88=; b=KNSts9ESRfn/FFbK/z2R2tjQb+F1+QTFGw63tuEnQUdT1dNmSNFH12+zAyXqvaXkBDNpcHzhrEJc0hWSaqdmj83GR63zMN/ggoM5U2bfHqvuu8U6aYZkkMDzFjRelQg92GtN0fI5M/4X7ozwyF/P7z6zhm567pnKxFhlwu1efm79E7z2f69NTZJ2DXmHjeL+ulBl8gd8+o+e8aC7MlA2HSqdUIWCCyQO3yK2NojySbCZaQWtjYDgHdxfcpO7QehRe8hEaZBSRC2Dh0bJAVEVhFpgm9wM1ugVRVjX1PjhKCtegZ/DCkcX99RtkLmoHs9Ysk5y5YliKy1nu7fcwOSanw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=expOafzG4ySvb8SnnC3y8kh5Rt+bK6ZrnTkl7O2Iv88=; b=k8rUeJFgkqtWk+ocrYnuVKc/XTfAt5T4bqmkr3c+sbFtO/RvVXIGOVR1SXsC8zTFPFRfyf3vp2uLNj/dzpb/cRa1+emWr8UnA6xANFahdS7QXTK/rvN+k4+s1nYa0qIEx+jCXZvs+wCAhUL86Xt6lWZbXNkMI39J0qc/nBW20e4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2689.namprd11.prod.outlook.com (52.135.245.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.15; Fri, 20 Dec 2019 17:18:42 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.016; Fri, 20 Dec 2019 17:18:41 +0000 From: "Panos Kampanakis (pkampana)" To: Magnus Westerlund , "iesg@ietf.org" CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Thread-Index: AQHVtmteNYW1qV2WE0en9EAnACcqDKfCd2YggABM1wCAAHy84A== Date: Fri, 20 Dec 2019 17:18:41 +0000 Message-ID: References: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3157bd1a-80f4-44ef-6a08-08d78570a950 x-ms-traffictypediagnostic: BN7PR11MB2689: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(346002)(39860400002)(396003)(189003)(199004)(13464003)(2906002)(53546011)(5660300002)(7696005)(186003)(4001150100001)(26005)(9686003)(110136005)(81156014)(33656002)(81166006)(55016002)(316002)(66946007)(64756008)(478600001)(71200400001)(66556008)(66446008)(66476007)(4326008)(8676002)(86362001)(76116006)(54906003)(8936002)(6506007)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2689; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9+pvWZAYMB5Vl5UGemq4r5GEExMxSrhe6EbUUae9BhuBx6xcROO+fmE68oQ5qXGOQRutVnxYb29D7bNPJhNypsubkO99Nl0vFutYQjarWWKN7Kfd5CrtiAje8XQ6weBTEhK/jwdNE9x7O9CMhIOLQsZ6lBMYs0AM4cl90rZzVhRxOuNhmTOfRt3gslSGHvHb30nP/iLQZFSnaQQNf0ykJ2D5Njjxcs837Y1jB2adDZaskzWoFsv8PXQSzekXVOA+hh11qr/hWYTQVMIyoGvesiVdfpWvzbVIsu+YxgCxMs48B4CVL+jJhTmErp3BfsOxsQsFpB2p0q2scy+tw9tWgXhYZ/xiLJsen6NPuWpxxRSvhZLbHR1RWbIpEbf7byajb7dk0Dg6IQkJbQrOoTkQANEA1gjn9QjQgXC3I14JeBXVqnl8YGS5HYyUyLI8wtT2IA9PLEb7Emdjp5MrXEM/MOehogP3GyIsSAd1kcvD25A0GIwlEuswF0J/YqXbU528 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: 3157bd1a-80f4-44ef-6a08-08d78570a950 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 17:18:41.8086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OsYZcTqgFFLyeabPDPv0BpvbLwKJ5xuF9uCu+4brM31fZO3GvEvgJsSkzrdX5SeJ+/fUzbB62imPdGXJTdxz3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2689 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) X-BeenThere: ace@ietf.org 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: Fri, 20 Dec 2019 17:18:49 -0000 SGkgTWFnbnVzLA0KDQpJIHNlZSB5b3VyIHBvaW50IGFib3V0IHRoZSBjb25mdXNpb24gdGhlIHdv cmQgInN1cHBvcnQiIGNvdWxkIGNhdXNlLiBPdXIgaW50ZW50aW9uIHdhcyB0byBtYWtlIEJsb2Nr MSBhbmQgQmxvY2syIE1USSBmb3IgdGhlIHNlcnZlciwgQmxvY2syIE1USSBmb3IgdGhlIGNsaWVu dCBhbmQgQmxvY2sxIG9wdGlvbmFsIHRvIGltcGxlbWVudCBmb3IgdGhlIGNsaWVudCBvbmx5IGlm IGl0IG5lZWRzIGl0LiBSRkM3OTU5IHNheXMgIiBJbXBsZW1lbnRhdGlvbiBvZiBlaXRoZXIgQmxv Y2sgb3B0aW9uIGlzIGludGVuZGVkIHRvIGJlIG9wdGlvbmFsLiAiLiBTbywgSSB0aGluayBpdCBt YWtlcyBtb3JlIHNlbnNlIHRvIHJlcGxpY2F0ZSB0aGlzIGxhbmd1YWdlIGluc3RlYWQgb2Ygc3Vw cG9ydC4gV2Ugd2lsbCB1c2UgImltcGxlbWVudCIgaW4gcGxhY2Ugb2YgInN1cHBvcnQiIGluIG91 ciBkcmFmdC4NCg0KUmVnYXJkaW5nIHdoYXQgaGFwcGVucyBpZiBhIGNsaWVudCB3YW50cyB0byBz ZW5kIGEgbGFyZ2UgcmVxdWVzdCBhbmQgaXQgaGFzIG5vdCBpbXBsZW1lbnRlZCBCbG9jayAxLCBJ IGRvbid0IHRoaW5rIHdlIHNob3VsZCBkZWZpbmUgdGhhdCBpbiBvdXIgZHJhZnQuIFJGQzc5NTkg c2F5cyB3aGVuIHlvdSBzZWUgYSBCbG9jayBtZXNzYWdlIHlvdSBNVVNUIHByb2Nlc3MgaXQgb3Ig cmVqZWN0IHRoZSBtZXNzYWdlLiBJdCBkb2VzIG5vdCBtYW5kYXRlIHdoYXQgdGhlIHNlbmRlciBh cHBsaWNhdGlvbiBkb2VzIGlmIGl0IGhhcyBhIGxhcmdlIG1lc3NhZ2UgYW5kIGRvZXMgbm90IGhh dmUgQ09BUCBCbG9ja3MgaW1wbGVtZW50ZWQuIFRoZSByaWdodCBiZWhhdmlvciBpbiB0aGlzIGNh c2UgaXMgdG8gZGVwZW5kIG9uIHRoZSBsb3dlciBsYXllciBwcm90b2NvbC4gU28gaWYgQ09BUCBk b2VzIG5vdCBzdXBwb3J0IGl0LCB0aGVuIElQLiBJIGRvIG5vdCB0aGluayB3ZSBzaG91bGQgaW50 ZXJmZXJlIHdpdGggdGhhdCBpbiBvdXIgZHJhZnQsIGl0IGZhbGxzIGluIGdlbmVyYWwgVENQL0lQ IGxheWVyaW5nLg0KDQpEb2VzIHRoZSBhYm92ZSBzb3VuZCByZWFzb25hYmxlPw0KDQpQYW5vcw0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgTWFnbnVzIFdlc3Rlcmx1bmQNClNlbnQ6IEZyaWRheSwgRGVj ZW1iZXIgMjAsIDIwMTkgNDozNCBBTQ0KVG86IGllc2dAaWV0Zi5vcmc7IFBhbm9zIEthbXBhbmFr aXMgKHBrYW1wYW5hKSA8cGthbXBhbmFAY2lzY28uY29tPg0KQ2M6IGRyYWZ0LWlldGYtYWNlLWNv YXAtZXN0QGlldGYub3JnOyBpZXRmQGF1Z3VzdGNlbGxhcnMuY29tOyBhY2UtY2hhaXJzQGlldGYu b3JnOyBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBNYWdudXMgV2VzdGVybHVuZCdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1hY2UtY29hcC1lc3QtMTc6ICh3aXRoIERJU0NVU1MpDQoN CkhpLA0KDQoNCk9uIEZyaSwgMjAxOS0xMi0yMCBhdCAwNTowMSArMDAwMCwgUGFub3MgS2FtcGFu YWtpcyAocGthbXBhbmEpIHdyb3RlOg0KPiBUaGFua3MgTWFnbnVzLg0KPg0KPiA+IFRoZSBFU1Qt Y29hcHMgY2xpZW50IE1VU1Qgc3VwcG9ydA0KPiA+IEJsb2NrMSBvbmx5IGlmIGl0IHNlbmRzIEVT VC1jb2FwcyByZXF1ZXN0cyB3aXRoIGFuIElQIHBhY2tldCBzaXplDQo+ID4gdGhhdCBleGNlZWRz IHRoZSBQYXRoIE1UVS4NCj4gPg0KPiA+IEkgdGhpbmsgdGhlIHJlcXVpcmVtZW50IGZvciB3aGVu IEJsb2NrMSBpcyByZXF1aXJlZCB0byBiZSBzdXBwb3J0ZWQNCj4gPiBpbiB0aGUgYWJvdmUgc2Vu dGVuY2UgaXMgdW5jbGVhci4gSXMgdGhlIGludGVudGlvbiB0byBzYXk6IEFuDQo+ID4gRVNULWNv YXBzIE1VU1Qgc3VwcG9ydA0KPiA+IGJsb2NrMSB0byBiZSBjYXBhYmxlIHRvIHNlbmQgcmVxdWVz dHMgdGhhdCB3b3VsZCBvdGhlcndpc2UgcmVzdWx0IGluDQo+ID4gdGhlIHJlbGlhbmNlIG9uIElQ IGxldmVsIGZyYWdtZW50YXRpb24/DQo+DQo+IFllcywgdGhhdCB3YXMgdGhlIGludGVudGlvbi4g V2Ugd2lsbCByZXBocmFzZSBpdCB0byBzYXkNCj4NCj4gICAgWy4uLl0gVGhlIEVTVC1jb2FwcyBj bGllbnQgTVVTVCBzdXBwb3J0DQo+ICAgIEJsb2NrMSBvbmx5IGlmIGl0IHNlbmRzIGxhcmdlIEVT VC1jb2FwcyByZXF1ZXN0cyB0aGF0IHdvdWxkDQo+ICAgIG90aGVyd2lzZSByZXN1bHQgdG8gSVAg bGF5ZXIgZnJhZ21lbnRhdGlvbi4NCj4NCg0KSXMgaXQgc3VwcG9ydCBvciB1c2UgYmxvY2sxIHdo ZW4gdGhlIHJlcXVlc3QgaXMgdG8gYmlnPyBJIHRoaW5rIHRoZSBjb21iaW5hdGlvbiBvZiBzdXBw b3J0IGFuZCBvbmx5IHJlc3VsdHMgaW4gdW5jZXJ0YWludHkgdG93YXJkcyB3aGF0IHRoZSBpbXBs ZW1lbnRvci4gQmFzZWQgb24gdGhpcyByZWZvcm11bGF0aW9uIEkgaGF2ZSB0aGUgaW1wcmVzc2lv biB5b3Ugd2FudCB0byBtYWtlIHRoZSBpbXBsZW1lbnRhdGlvbiBvcHRpb25hbCBpZiB0aGUgZXhw ZWN0ZWQgRVNULWNvYXBzIHJlcXVlc3Qgc2l6ZSBpcyBsZXNzIHRoYW4gd2hhdCB0aGUgSVAgTVRV IGNhbiBzZW5kIHdpdGhvdXQgZnJhZ21lbnRhdGlvbi4gSG93ZXZlciwgdGhhdCBsZWFkcyBtZSB0 byBhc2sgd2hhdCBpcyB0aGUgYmVoYXZpb3Igb2YgYSBub2RlIHRoYXQgc3VkZGVubHkgYXJlIGZh Y2VkIHdpdGggYSByZXF1ZXN0IHRoYXQgaXMgbGFyZ2VyLiBSZWZ1c2UgdG8gc2VuZCBpdCB3aXRo IGFuIGVycm9yIG9yIHN0aWxsIHJlbHkgb24gSVAgZnJhZ21lbnRhdGlvbj8gVGhlcmUgaXMgYWx3 YXlzIHRoZSBwb3RlbnRpYWwgZm9yIGEgcmVxdWVzdCBiZWluZyB0byBsYXJnZSB1bmxlc3MgaW1w bGVtZW50YXRpb24gc3VwcG9ydCBvZiBibG9jazEgaXMgbWFuZGF0ZWQuDQoNCg0KQ2hlZXJzDQoN Ck1hZ251cyBXZXN0ZXJsdW5kDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTmV0d29ya3MsIEVyaWNzc29u IFJlc2VhcmNoDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQ aG9uZSAgKzQ2IDEwIDcxNDgyODcNClRvcnNoYW1uc2dhdGFuIDIzICAgICAgICAgICB8IE1vYmls ZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= From nobody Fri Dec 20 19:44:16 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2E4120A0B; Fri, 20 Dec 2019 19:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hovucj0C; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=yU4XKrMb 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 xovTF6qHRpQn; Fri, 20 Dec 2019 19:44:12 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356F91209B8; Fri, 20 Dec 2019 19:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10611; q=dns/txt; s=iport; t=1576899852; x=1578109452; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QHsgRj9qlWYu2LkM/Q65Y5yPWfsjxLp5CoJpEKc876A=; b=hovucj0Cz69+Mt1+ikiogrNy/w3GQiD45hen4e18FYfvF871vhTpOfWw KGXYBOG4+RK4ETP1gA6A/STgGyzmRWZvpAm/eokNl3qta/5pRh+PzZTfI SlCxG7OPxfR/c+FwMeuVg5sRbaZvBXxCZTu57ATiuXQercoTZ96mk6r5d Q=; X-Files: smime.p7s : 4004 IronPort-PHdr: =?us-ascii?q?9a23=3AIwgPyxKu8KEH9lqLk9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DECQDtk/1d/4sNJK1lHgELHINJJCw?= =?us-ascii?q?FbCstIAQLKodNA4p1gl+YCIFCgRADVAIHAQEBCQMBARgLCgIBAYRAAoIcJDg?= =?us-ascii?q?TAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDAQEQLgEBJQcLAQsEAgEIDgMEAQE?= =?us-ascii?q?vAiULHQgCBAENBQgGFIMBgXlNAx8PAQIMoFgCgTiIYYIngn4BAQWBNQETQYM?= =?us-ascii?q?MGIIFBwMGgTaBU4opHRqBQT+BEUeCTD6CZAEBAQIBgSwBEgEJGINAgiyNRwe?= =?us-ascii?q?JRohcjyEKgjSDYII3gRuPAYJEh3uEQYtVjlGIUpICAgQCBAUCDgEBBYFpImd?= =?us-ascii?q?YEQhwFTuCbFAYDY0SOIM7hRSFP3QBgSePUYIyAQE?= X-IronPort-AV: E=Sophos;i="5.69,338,1571702400"; d="p7s'?scan'208";a="387410581" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Dec 2019 03:44:10 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xBL3iAQL016501 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 21 Dec 2019 03:44:10 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Dec 2019 21:44:09 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Dec 2019 21:44:09 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 20 Dec 2019 21:44:09 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mc+AThm4j61RSatluDmKDOgYaeiBVX6Ze3WtuLkMSEi83/jOBap5p87LLSSO0OJzIReOJva5Pe5Z0hoQQ89UuaAArDgQvVhD65GoIwWdokTv+0HluWHiEmqyc2X9VVGRTuCCGQvMRhXD89Jxvb3TmXNtT7PbyimOh8nk5zuQSQYY0YlC5gf8ZHP1UwUSkfBdn7Ct7q+6w30KkD2c+jnsLlMV3C+qOnEYyE2VlDspSV0kconwPMtIRrfyVAhx0f48DogIHPi17NDI8t62ZRHVoWdYVO2a+CVj5ltf/BngRdF4s1C/c9qJu6GWHiZnBLmjwvMEMOgzbvQ784fi40w+bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1qoMZ3EzQi9H8x4gtls+tDdq86CyKUL7ln/euo+SbQM=; b=D1ad4cMSvJtHJ7Nv0gYR7X9HjLZlDRUutV09xvDaDBjJODQYtG00A1KclZ3LCZrfP96p68xtQzKGvLGGl6KR4jX2sPFqdxZqOucuQw77GdOV0UeYKDcwwDEeNnJyMX2oHL8UdNm1tm9DPyd2v2yCU5g7cCycoavoX6Nq57BYVV9aae95DeOCtzXTl6h5nFMP0GwXQa1jAdqF8hnrBG9gqtc+qr8AnYDhv91hTGV7TADaZNNT7rE4iCWnr6h3aeKTJ8tjLVzmhy68T+kpnqbbtcYz6UqIDz94fEZA90mekzOc4uBRxE/LVbQvuEbGg6XPErtT9CsPjJ/o1v9YPZnRcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1qoMZ3EzQi9H8x4gtls+tDdq86CyKUL7ln/euo+SbQM=; b=yU4XKrMb9UCFo9V/ac06Mvspg5jItL4s0rd5qCeYFAzby0hGYKvvVIfOFiX2MTvjXBMznrlPLcyKzUjAyRoLxOX+ZaohNECTvR5Do8si0WOmV7JGNRbJo/drwjBEa38mLtSHmecoZMG+fi+mb2OlQ0hxes+p/yNG3YAZPArRhT8= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2737.namprd11.prod.outlook.com (52.135.244.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.15; Sat, 21 Dec 2019 03:44:08 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.016; Sat, 21 Dec 2019 03:44:08 +0000 From: "Panos Kampanakis (pkampana)" To: Alexey Melnikov , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Thread-Index: AQHVtablCsJ9xDNyJECls9msub14xqfD9IYQ Date: Sat, 21 Dec 2019 03:44:08 +0000 Message-ID: References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> In-Reply-To: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1002::12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba0fd399-52af-4342-f52e-08d785c808d7 x-ms-traffictypediagnostic: BN7PR11MB2737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(136003)(396003)(346002)(376002)(39860400002)(366004)(199004)(51914003)(189003)(13464003)(8936002)(2906002)(71200400001)(86362001)(81156014)(66476007)(81166006)(54906003)(66446008)(33656002)(186003)(64756008)(76116006)(8676002)(5660300002)(52536014)(4326008)(66556008)(316002)(966005)(66616009)(66946007)(9686003)(7696005)(53546011)(6506007)(110136005)(55016002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2737; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P93vHrvjuSapJJ26r0mjQ+npOe07PcNvayGOo8eE9fpmMA/rfCvepLSxrJNXeAbx8GK7L2Dq0PDrq6yHEDT37Uf7vJ89/qSS1fI5zIr5TV16HD9L4hUj7lxIexQMS2NMWBcEJeJ6K3QnIVQGSIHzKh5r7j84IoEY3ervPY5jE8l7Id89S8j5R7KhYatyPvAp5wNPfhSVnRf/oyJqFmxmlNDbAZwVaPSwf3SIp3ugDZxIOkQ5FJAnUiFIahuE2y9yq0FwRZVpOtWmxXgMjv2ZYQ6u8m/OHrHK1bgAdbZ2cfKikmaAgUOHmptYtkq54Z00u18EgXn501hKN4fKQ6B5PNkefErZwpuclrOY71Q8uhYvscPBW48dLgjk7OIOYQt88U9buQFV9hfvTLZA8IkE15yRsSHhYsBVBYy/vS7hESitd9SX3aMHk0oNZe/G94Hk3csxB+VlVuSh24BXWwBD8ezOb1Av1WBOaSxljXHGKHh5Eu0Xzl1C5nxuc8CRtBnRmVTWiGZoksbBVuC+EFVZnGNL4S7RAZXew0goNtb1Hx5XfYwnj6qGtJ8iB77fz/2KfYIAz47fzrNNGqCXMmNrBWeLUuQnAFtfkc8lbzV7vflL/k4T5l8TQ7iP/jUfWUBs x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0013_01D5B786.FCC6DF10" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ba0fd399-52af-4342-f52e-08d785c808d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2019 03:44:08.3409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PIH0zulbWCNNE7IoHcMd2YKK/WUwpyjErUuWS9H1yG39KupQV0c8i38t+l5I5k2Z3FdMt0s/xDFUhTx4o+X5tQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2737 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 03:44:15 -0000 ------=_NextPart_000_0013_01D5B786.FCC6DF10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alexey, Thanks for the feedback. We are tracking all your 4 comments and discussion points in a git issue in https://github.com/SanKumar2015/EST-coaps/issues/155 There are 4 comments in the issue, one for each of your points. The comments include all exchanged information in this thread with Ben K, Jim S., Carsten, and Peter. At the end of each comments in the git issue you will see the change we intend to make in the draft to address the feedback. Let us know if any of them does not make sense. Rgs, Panos -----Original Message----- From: Ace On Behalf Of Alexey Melnikov via Datatracker Sent: Wednesday, December 18, 2019 8:27 AM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this well written document. I have a couple of small DISCUSS points and a few minor comments/questions that I would like to discuss. DISCUSS: 5.4. Message Bindings o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- Format, Block1, Block2, and Accept. These CoAP Options are used to communicate the HTTP fields specified in the EST REST messages. The Uri-host and Uri-Port Options can be omitted from the COAP message sent on the wire. The statement above When omitted, they are logically assumed to be the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. and the last quoted statement: How can the sender know whether or not it is Ok to omit Uri-Host/Uri-Port? 7. Parameters It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). However, depending on the implementation scenario, retransmissions and timeouts can also occur on other networking layers, governed by other configuration parameters. When a change in a server parameter has taken place, the parameter values in the communicating endpoints MUST be adjusted as necessary. The last sentence: use of MUST with passive voice is really unhelpful here. Adjusted by whom? How can this MUST be satisfied? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Comment: 5.1. Discovery and URIs Clients and servers MUST support the short resource EST-coaps URIs. Just to clarify: the original EST URIs are prohibited in COAP-EST? In 5.8: In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client-defined (in the CSR) I would break up this sentence into 2 to make it clearer, as I initially read this as 2 encryption operations applying to the generated private key itself. So I suggest something like: In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key. The symmetric key itself is encrypted by the client-defined (in the CSR) asymmetric public key and is carried in an encryptedKey attribute in a KeyTransRecipientInfo structure. Finally, if the asymmetric encryption key is suitable for key agreement, the generated private key is encrypted with a symmetric key which is encrypted by the client defined (in the CSR) asymmetric public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. As above. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0013_01D5B786.FCC6DF10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMaTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBKwwggOUoAMCAQICCgGGESJBPOq6 K1UwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MTIyMDE5NDkwMloXDTIxMTIxOTE5NTkwMlowgZ8xJDAiBgNVBAMTG1Bhbm9z IEthbXBhbmFraXMgKHBrYW1wYW5hKTEUMBIGA1UECxMLQ2lzY28gVXNlcnMxEjAQBgNVBAsTCUVt cGxveWVlczETMBEGCgmSJomT8ixkARkTA2NvbTEVMBMGCgmSJomT8ixkARkTBWNpc2NvMSEwHwYJ KoZIhvcNAQkBDBJwa2FtcGFuYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCYgdMsjOgCe4xSIczHxX48X0mkBwHvOs0c5jVWPVHVXHu3Lub3Kj0b33VPafvMejhTMXq2 cH03HNA4oJjniio/kqNUZg48+j6pn7avHUYAHN0pQXgvBRQo5N/25cC2+y8hFRzkn9yxKFONxQi+ 1WaIDNZdZF8xhKGMFgFW3H+Hx8OoCp8UDN3ocbRNx2w38FFv2TpARbVp8eM8qVFRoNEQvKOcUYll 3Y6xQnv9oox0WZAV3YIAljOy7AtiN6omy4Y3MFz+TqbNA9/oVbXufPXsbjUpF5TRR1l/bJmO+KaT AJD/JbxJVM5wYE/5mT4urkRgQZAy7Wq00r/3ttcxzmS7AgMBAAGjggFaMIIBVjAOBgNVHQ8BAf8E BAMCBPAwDAYDVR0TAQH/BAIwADB6BggrBgEFBQcBAQRuMGwwPAYIKwYBBQUHMAKGMGh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jZXJ0cy9jZWNhLmNlcjAsBggrBgEFBQcwAYYgaHR0 cDovL3BraWN2cy5jaXNjby5jb20vcGtpL29jc3AwHwYDVR0jBBgwFoAUn5U2tI5d1UvDCsGnKZND UQb9iVEwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Npc2NvY2VydHMuY2lzY28uY29tL2ZpbGUv Y2VjYS5jcmwwHQYDVR0RBBYwFIEScGthbXBhbmFAY2lzY28uY29tMB0GA1UdDgQWBBSOuXvoyut3 DdlgWJOlkF22tSbk/jAfBgNVHSUEGDAWBgorBgEEAYI3CgMMBggrBgEFBQcDBDANBgkqhkiG9w0B AQsFAAOCAQEAyFHrEJPKC7ryWmmNZ5tdNdjOeLHn3rWFybCIlGQ+1QgZDklDBfILCr8m66rJzl5t 6r1xAQ7mKrLGKT9QBDfkGWYpvtI0uLvlG0UT8AhmtGwSNNSg7YS0IxA4Qxx6dZrZcTx8QgMGTDOt 4p5o5yEJsN3gv0+8oWG3qcMMW1vpVl1aziiu34neIV6KVV/egjkxJWL6quhZoUucthNAZOeoSNYA 18rDdFEEAx2g8Jn43h5+0CTVNZVLTyc6w+gpZe0ipfrLRk+z8RmMFKTnu/VM8uliESpgZcigYmUi /MgB9g2hSDzI/y2gblPvH7uFHPQwxQZZwIOxL08wXEfpKetRIzGCAv0wggL5AgEBMDowLDEOMAwG A1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBAgoBhhEiQTzquitVMAkGBSsO AwIaBQCgggGYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTIy MTAzNDQwN1owIwYJKoZIhvcNAQkEMRYEFOLutjoAlGXVeoB6BI6oz/5EQW1pMEkGCSsGAQQBgjcQ BDE8MDowLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBAgoBhhEi QTzquitVMEsGCyqGSIb3DQEJEAILMTygOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwgaAGCSqGSIb3DQEJDzGBkjCBjzALBglghkgBZQME ASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJKoZIhvcNAQEKMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAI8p0PEQlagOsDah00vjgOEF2NT/ hEdVJmGkIg/ehfJRd1e08FiwQQPxAzcKffaB+OKg1QRn/zfATubQvUreGhBgg+m/nApTA4BF851E 1m0XrPnFHxYEHLfQq2mSrllb0u8BWZA8MhTB0Z6uqHwcMuBPxwf8ZhY14LZydAnjzZfvHmxsGqkj WbKXkbRtY/lfcUY+cdj0eIyVtrAHJiEoindTu7J6HxIQSk2qTsSPOIXcWFhTyCv/8feY4CAA5eyb XO3XAWtn+qj/DvTxvJFZLbvMK8Hb557g1vUTNKETLNozBmvbuQCO0+aC0SirbXbD9Ch9PM5EB7Yk FQkU0TUXnaIAAAAAAAA= ------=_NextPart_000_0013_01D5B786.FCC6DF10-- From nobody Sat Dec 21 03:11:47 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF524120A32; Sat, 21 Dec 2019 03:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 kwte6wwJNpuX; Sat, 21 Dec 2019 03:11:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 D2A08120A3A; Sat, 21 Dec 2019 03:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576926657; bh=CQ+8eqcWZWMqJsvN3Z1c3rBARkW7RJYeLeGT5HU8mLs=; h=X-UI-Sender-Class:To:Cc:From:Subject:Date; b=Ux0M9+sEGP6b0qxsUd6jhXB/zgEMPSDTC3nNBXkYc45sHT6jEdDv2aOMkFdhrqYG/ 2ln4zAYrq+8H5Iw0kT0OpDDDbJqrDkZIX/+Qhqq21jHL3Jyvk7/vKRV99bWzfhCvTR W8x2NPfBFdUgNz56FarlCZKROF+CxR+oBlYxvcoQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIx3I-1iPIYl2FH0-00KPLq; Sat, 21 Dec 2019 12:10:57 +0100 To: jwt-reg-review@ietf.org Cc: Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , 'The IESG' , 'Roman Danyliw' , drafts-lastcall@iana.org From: Ludwig Seitz Message-ID: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> Date: Sat, 21 Dec 2019 12:10:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:4hpu1f/MQYyXyVTLRI8SR+oMtDCf4R2wlTOQKv1yc30dJAPIk+U X6n3vJo5zkY+/yMnrlXqvXF+Y4OD3JanQ12xgSvpb9lIpjQ/2Qd4YhfOn3AIwpI7f/J3BAu 2r0l0BUCqOp6YpmSfNZrSAtnLIDvEBo3GY/CW3a8dxSglEQKfu1EaY6idqLuE00CbLSNHTn OwgeBGPlBaOeg8b0faesQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:CR9Gw1XCvIE=:hcRaXbwPEuYBdfsxnD7JQB 3JxR8NiOJxqvBbM+4WrsVPAn4/O8fVBIlaQcaEPMw92UfGeU60CzWxfZLrm6gldkloLGphE7p ODhFFSLRwkzz7p3KgGQXI9O0TglOoTz+NzT5I2FbAcFIHcV3mnaybMcQCrHy/OKyCezdzvrsw fHbUq0kns9Vg3fDDFrfJnwUrPm9EYHaIyNq+m0vRsJf+nbtzCtznXqzh5oLNNKvdic86tdNoj XyQEEmhA6i9IxbD3mb1xni+olG5nhpViu0cK0NQeZtSNIIoZx8y8z4cRmiMy6qoqjBpLx8bia ei0dnF2pWLClr+jCe1PguMWmc7FeJ+TZnCgDSiI8S555kLg6SpdwChoHaToMnv+gRtW2I7+Co /e/tumQ615V47chzz5BQBTyl5XiDf9uNs7Tst0tRTE8x52ImJqTIRJBUeItI3ZoveUo6WAt/v GokkPr271+EFfEjO2Wvaen9Lhf9g1n8DGbbwXqgWaJAdZC8It25/yxeE04ELGr8ZniXw/05KO qqv2mGerryKaKmxS8qMDopScXEhn3ML4xj2mQAZRXezWr6aFHxrOFtaHkw/lWpMwijTCJEHJ/ jJHuoxUKEoIFnXJEfxA5dwmukK0Hgl2Dvt7NyDuLG2HDwB9m6CiZ98DHTGENbsb/96JdXFy3H nljUBFdRQWRU3nE01znOGz0/HmNnheWiAskcKo1cERov1w+lOUUtWJNVEUeZi5irYwck5WWJh iCWm3qaZIwtNXbDf7r2eGN3EnU9XozWIefaErhUvwAfklaxQGRL0Zb6C84m0jXgORVwF3gC5t asa69UKN3JnyUU9MC5vtXoH9cGUl6LONV/Ygd62m6hBDwi83NKMTMA3QPa+g8A/XIbDtlALHx 8zehpMX1fgGahq1NaXVHRaVTv65zP/Pjz13erTCmGkvYQG8FgHpeNxW8zePz10pWQR8CJnnqE Qp7QSifpNJ4Pqy9WgxAVacj6uYBYqY2sicpMPL2qsCi0gTWiLrKhNxALxGxKiwx94hdYkJh+T 4D1metTv1JTtYrTscyWY6BqztmN4xh5yT/i32h3jOB8PmtnwOxdPbaBZTU0/pUBfD3BP2+dmH 4CwNhWt1d2b7A3SNM0etHLTq0SHgPKP9OZ9ryTSjR8ldjIg+RVDzbd2qWziBn5p2F8cW/JpwX usFgOwxoolmEZg9Pv/BOsMu/fl3Y5wcku6PeXlXuVfvx1vr8GumEPCMHMVHTRAjHtFcOd9g+U BylmLlGFtOMjxRw7tsRQu268B00VO/b8S5sXP/bM12UWL4j6LvcPKN8jloSA= Archived-At: Subject: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 11:11:47 -0000 Hello JWT registry reviewers, the IESG-designated experts for the JWT claims registry have asked me to send a review request to you about the "rs_cnf" claim registered here: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.1 Thank you in advance for you review comments. Regards, Ludwig From nobody Sat Dec 21 03:14:51 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47BF120A3A; Sat, 21 Dec 2019 03:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 gJ6tADRrD42j; Sat, 21 Dec 2019 03:14:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 DEBCB120A32; Sat, 21 Dec 2019 03:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576926850; bh=ieeOySy61Le6smQZjqP3/Cp2SoxNTULrT1BvcYdFQE8=; h=X-UI-Sender-Class:To:Cc:From:Subject:Date; b=HI2OYQJHObbbgeYohWXsDHXNDM0B1DHy0010h3RHEiGH2X7yIVKksav4mzYJPsv06 A3OnE7BwHVhyUeGFKQIkSEOBVwtbD/igFgO5Av6ceBuy5BWcRbfLTABdbfqWbNpob9 7ixeUoLLEyHY81yg9eEmr8Jm3ropryZRKbJUWfd0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4hvR-1hhxLi3qPX-011fRW; Sat, 21 Dec 2019 12:14:10 +0100 To: cwt-reg-review@ietf.org Cc: Jim Schaad , 'Daniel Migault' , "ace@ietf.org" , 'The IESG' , 'Roman Danyliw' , drafts-lastcall@iana.org, Benjamin Kaduk From: Ludwig Seitz Message-ID: <03f0f73f-4c82-9089-0a81-471a5fb54ba8@gmx.de> Date: Sat, 21 Dec 2019 12:14:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:uX4q0uawMC0URqezBKQwjHNU4EHXq9HqDsQjT+WBdBK28a3WfVu QR4FPpGgXOYKHygw+u0g1jcSX0QYISnBl8PxfEkCLTg5GOVZ8gu2R1Xzc/31/MbVNRt9nL4 wQJ91WVuOZa8mgkkk4x/QZob+raR1GgOwhvn23gsbSvIWlfIPnB8NxTz9BGdQQ38pNkFzwo Ns/L7npYK4YP7K3JeLqfg== X-UI-Out-Filterresults: notjunk:1;V03:K0:wuKfZVDj4qY=:KK7bhrC5ea6NW7H9oL1X/k gNV5Hgio6BGMLxcplHtmzdkCiZtTk7zWwcLXjRy8s4vjAKXrwurrIQRosj0LdI4FOeGXL6HCG YXCwnOYJE04WRLjjletNxK9fiUuiBUoGIMBtf0IoUzPJPI7YVTxgKuSLNKkOT3ZeRKJY/qKim MJRR0fX0Jn+X3icmgMjnacxMMwa1Ne7iTnaaALVq1aEKomir+WkoK7tHij8iR6mztKAVAe2SC S7s1NmLBEkpswLsMdBw5qY+pKYHTcYXOssC1NH9p+cOmxMg66T/JkMDV5XGaJW01GozaTPw/Y JepxJEQ7ezJwUaTCLt4QKzxONdjHovmykjbkUMmt1Uf1sS62YceVIzez3IXrjL65ZaTsyj6aA Yi2J8W/ApZ8KoL9/2zRbOhLdAkFL0ML3QHillQL73rySxR+rxvUGgnjsfU/dEIxLi4WJjYscy O0lW3QmYvcT9Zs02z+tVNl9MMApFEc1SEcP3iPqnuuYycloRlOChyfoHFzJxwq2uac11Qf0av S7xH2X/Cf74V8K/7yTwd6SJLn1Vhxny86fbmaOJDJvg524+hzW4QuKDBTSmy8YNGa6frzlc+s 7nhyc+Q8/eNjOmpMd5AWidMWTfq5yWncp81dBTQnc183xqjffiET27VPQdtqxmHw/a5B4WvJF 0BpBE+jCuGMItw9KtIW2JCU29zj4gU2Ya0EUvD4o1lQkYhwv3ggYOBIHl02ZD9AvxmCSmE/Ld MoXdf8+8dR5I1FID4dSJLjhVOAm7ftY0GtTnVtN8FHAypcue1wQm1iLLIs2+s5c9t9EF4Ji6n gUDfIbnfeW1FWBlQuIjiIoxudmV2uNPuiMy94WVz6erCELUv4Bm/Bikehl6Qm6Ue9ttuRLZaE MJyst1wgTcAbRRXjeRElvL1K0GTtZkyhmIc7wik5aLBjG2nC6F6XAkwp24p0UPP2X4btLFQnL Q3gNAUbfcPd/EGTK5rOf3CxDmoD5bSOpMDOKgsgKRCWMag2e2bNXlN1SGi/ZWmaAk5YpntADR IbajqJ5ESTBitj8CmLEFLJtG2m920ZyZQhwXBAsS1SsdwCu2E6xrmANoXB87xQ+MUX9VL2cNA Y8F+u6How5ODXSKEfzu5ulZ/weGiAfxS9lSiGUIeLp3MAJDPdOCt2jHOOGGou4x437uIEXn0F 69Niwad/R8sWTqUWgwU7M0GkjN6/YlAiah8qfFb+cwyTw1QfXZA5gOxDiM0+n/rlqwItu/OY7 x8ZzZI+QdLG42sdrDDYDiTRwzpDaVVyKYtP/C2A4G2y5cSuOCdRpkOiXBwJY= Archived-At: Subject: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 11:14:51 -0000 Hello CWT registry reviewers, the IESG-designated experts for the CWT claims registry have asked me to send a review request to you about the "rs_cnf" claim registered here: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.2 Thank you in advance for you review comments. Regards, Ludwig From nobody Sat Dec 21 03:19:23 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580BD120A41; Sat, 21 Dec 2019 03:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 DGAQwooynS0q; Sat, 21 Dec 2019 03:19:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 4C17B120A32; Sat, 21 Dec 2019 03:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576927125; bh=e4a6NQiRG+u8G2Y/eCwvIqfPkCZDKIWH5t4ExCuXxq4=; h=X-UI-Sender-Class:To:Cc:From:Subject:Date; b=fq4muNBTPdw0DddNgOkUaslvEFzDvTSUAiw3OrYuBFRF5LghazVJXPGvvDWv2hEj9 75p4pHTG4Ro5bJsuW8W86xS/KbZZJ84jP0ItON+6jEo0Su3aQtQWrUAIvszFd9r5cV TUJBYMGBczSLSIqTQy3TxPMyfvvTwwE+izHrd+FE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M5wLZ-1icGr81TB5-007YBg; Sat, 21 Dec 2019 12:18:45 +0100 To: oauth-ext-review@ietf.org Cc: "ace@ietf.org" , Jim Schaad , 'Daniel Migault' , Benjamin Kaduk , 'Roman Danyliw' , drafts-lastcall@iana.org From: Ludwig Seitz Message-ID: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> Date: Sat, 21 Dec 2019 12:18:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:f/23d8kHpLuA7pBx+1pzyYiYtoeiXeuHbE8nksg1UvzD5rPGNEP ttOYSy5YQyZABXkjyGlrSDrLOJcShvoGhUNLasKltA33OCVMUAG1RlPWdKWTUO+Nl+uVvt6 vyVtCMn29t4MRhXHYlDoy2HDiG9SPfYxn+YuttUhS87NgpriScKkYLNakWDv0j83ADgVKsx sxYWNwTMCbn979TuHpBlg== X-UI-Out-Filterresults: notjunk:1;V03:K0:gyx+Q1Oi3Ro=:aqMnmxD18ePTHnp3xKhKwU YFfX2PAgNNXg15j3pF/iA1Rx2CERb1jIk0XUernMBCkb1y2cxeGGQnr1bPBX5ejXAWDgmLFAF PFoI2Tx79BZuFoNNXNbNLyF+OPysPfeMeJ5FYvjsQ4H5qJ8+u3qzeRx3PXeoAbqf8KHw1mrNz 7nqHQvhaGm8bxmxIFBwuzsnaa7KcybE183VD/NJs9mKCH4BZXUFsKu9Gcn0B4Ecbb9t0uVRPR tBV2RC99jaUlDIzh3q0K685wmFP3u4A1ZyEW7izsP6JcyWHUWG5t9cDlHN7taVbV+3qg/3S2d f+zh8LMwkekj++3KEUYK8TGBMDbZZZXfHr6r+M0ma9NlFaeuKQQRz6ui/vmNXpvDynmZ8OQH5 WATQffV1L7/hhsQPZycRzZrp7sYFTULQIUsQ/Av0RsW7p8XHA8MnUlln/gVFn0zjDuj9yHTLB kXKaW+MN/HPqxpPlNKxe8y7N2oGKHhHk/1WUh0+EX3NHmOZp0rSAS03Rx0WdgUPfEBK/f77fh irH0Tk38y7QIXND3E/gVwOEgUDQXqhb9TG/hDx7whklKBPPRAq4j6XESSMMhd44qQeBDHjNr8 PMJbKHTZyhCBqUdNAIB5L4LmeNV7VgmW25PT7v5R3WCiwiJEp7yjSihE+6FBw1M4w1QYTsg6H a7zK2y+PvKbtA1OEaVE/RFeDvyDYBzQ21ZA/vB06F63DA656Dix/re/eRzJhHl+ncz5Tc9Mqv cM4clSHaorTgx3RwG4gzJdQv09JEW4NLxL9zlTeL6zY6RcFAENEfhigy6A+39J76WT1phy8C/ Pz5qIutmOIloZ7szpBLpnsR6a+eDZcklcSQ1W29YhQi3aY/UjHwmzNG8j3Cp671UvkOdmBH19 53aT6twJ+Gnp/DhmasrPzeMX/A1vKeORsiWXFZEnWFKER0hNRuqnva8RCZIXf1E477shh0Js6 lXiTS911SPdEtXToPgt+kdksvgvjEFFGX0oZ5RU2H6Hpgn4aiU5h+MFC3HcsHf8Z1bhAcCv/8 ETfhp1e20pZ2HaXZsQFf70AZK6BjoFmHBbvSFSSDkJ5rCRYHQbm2EjyS3fpbcsvCX/6Juh+Eo TMQMpuVEVI+2GL2vQFqaSS3KRIKkpinbZqkVATPbooMFL2kERVTqy/6Zy2x1H5dpeuRbw+KVt C49sx2qN086CNkNs0qq1KOAhnr4xCYV+tA0FelewfRrlXM/MjxJYCogZXT13G6XVcKxr4HqSz uBUp/QH7y6pYy+9rt+8bejMwud78O8SwtzRwFglFqkOH3n9Qmm4oCWLd18LM= Archived-At: Subject: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 11:19:21 -0000 Hello OAuth registry reviewers, the IESG-designated experts for the OAuth parameters registry have asked me to send a review request to you about the OAuth parameters registered here: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.3 and the OAuth introspection response parameters registered here: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4 Thank you in advance for you review comments. Regards, Ludwig From nobody Sat Dec 21 03:26:04 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40159120A42 for ; Sat, 21 Dec 2019 03:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 N3irT9FM_lyS for ; Sat, 21 Dec 2019 03:26:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 8F45E120A32 for ; Sat, 21 Dec 2019 03:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576927544; bh=0Ja7ZSVNpGCdaGjRZIPBu8Jj3SKqobVHtSGtG4V34gE=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=Rz/yXgUJo14Tb5/75pBdGhnY8E7VqVk24T/cWw29CNbeSFZv+qePGFemHPkp3L7UC 8RtCS1w2D1D7GVwzFDtvUCU3Oq8E5qqWyHEAioZbIOKF7U+Cit/RndcnbG6nuXYP19 X09vdgR3qhJCPBySNHo83i04mH8kSTUxlH8NLMJ8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mnpns-1htgCQ1h8c-00pNX3; Sat, 21 Dec 2019 12:25:44 +0100 To: Jim Schaad , 'Daniel Migault' References: <157508633572.4770.7120325133415529789.idtracker@ietfa.amsl.com> <000901d5b201$0ff47c90$2fdd75b0$@augustcellars.com> Cc: "ace@ietf.org" , Benjamin Kaduk , 'Roman Danyliw' From: Ludwig Seitz Message-ID: <42f75b3b-9d85-5483-401b-d23b167dd038@gmx.de> Date: Sat, 21 Dec 2019 12:25:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <000901d5b201$0ff47c90$2fdd75b0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:iqbvpSXJFyY/9bWDCnQAR6gu2qhjPSCzMm9Gpg580BjegIfTWoM Xw7+WHPaIX+pfMjdBDs2sRGfNeHJYU1PkVgNMTeOGm/tHavL91oWsyaSOh7BTeFYmYb6c8P O9PYnf2IVu56L3AxPzpI6zDdEvD4jpck28abCkShhSg+o7cOmu0Hp/Du2tUeHnXjkD6cLcL cIY2CiaSKfGRWcwzHWf7g== X-UI-Out-Filterresults: notjunk:1;V03:K0:IEOSvilgAAU=:86D4VJ7xR4H8hzgQfiZyaZ RJBbY4Etqwekn/bZHn4MeLPhY4eLl0ZaYNkl0qFdDt4yF97wweOAnVBTbueu/OdhXKArDjXSn YocqYcqLzazmsRwwTh6T4JimEBMyiH2c6O/n4MOeC/iFBNTnjJ6b9lGVUz3HjQQUQXt8OQFZ5 JS5agE/fH3KO6EzTUm9zxgSBeAHxLmlNuP3KIfeHerFTjWjNMzC2OcZKPMkZaLweCb890L1sl V7lDzR1do0nlN4MeBCgXcGyaoQeYQSsA97dcST0XDMWhNIfIh279ih5frdQ1UG6VHi8zGfip7 GJ0T8cI5ywZbsu8eooPA0AX6Abtv1HI3KAd+VylcET70UV9BKCrbcILe562yOTn8Acv9IL/Zb 87h4x0hIYkkIDtNWqloXjuRYcfbG3yKR4Qj83z5haXifrseStcL+vDVWUq/j50LuNwBCRAiwH 0u2qzymWiQpsEVY8POUdh/qOJ0L8Uv/I6v4Mhv5GlSFSkTYmgHrsSHmnUlXAtyLKle2Sj/0sZ o9oeFh93+rln7Jc8YwsQx4pELtdR/cTuiZxCHMBlT6VYDl3ljWCqH0+jNCCxxnDsFE6GTEE66 ONvfTerM66NSoPN0bxfgpQlkgoOuZ1Z1ta4ATMUx2f0zXDxEEEQWDtuO7LlGIqi9GVicYmTg8 eDEia6oMTfK0FAqKfmsRc9TLzabU99mZ5/WIa9yfyRhm3c6hSmjCczk03LqjAX1cmvxrQgk3t NN5j5ngw1wZsfQwlP6/HdWSVI89BYexGRBleMzhVGZRMfpy/ja0tc6ocy9qFCtET/RIBv5w43 yX+FJZNjHS5y+wo5uWMT0iD/4vVMPWmudWQABG1/vFFG201HEZPav/lm92jjoxPFWk2609FfD BCV4W31xtav9PDau/qdfss3bwtKvnpa0xWbhwPqNSfrqYVIIilWbIugSFlxt7L0ncsgfGIJns 5goaIZWzOocfJyaYTaG24KakQdijRTvawUzcg7kNNMVZssKQIjmLVFpLn1Y9x5+LxgqlhrICk opMkARsmHdnv8vIMacO9dKz0Wo8mHu1tGX9igj0caewTDqch1Ku8qQrUsiBFgB2D3/LDVmcrG jXumNtNIRtHJJUCScJ9F/Ggd/N1tsQJZxc9sUlOE3SPmN/6QELByGwZbZuzn2Y5eORfvQgmoc QO6Y7299AKQAQoJ33Jw+hlo7S5YVvdeXfuoK44ffRRmquSyHfDQ3o5mzDgajeYpFXfhAYij0i 6wo+RXC2xr0w4dwVzzk+Wd1wIhKpidn0LBaG5ubJbraHhZCMe6i1rTWGkBRk= Archived-At: Subject: Re: [Ace] FW: [IANA #1157486] Last Call: (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed Standard X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 11:26:03 -0000 > From: Sabrina Tanamal via RT > Subject: [IANA #1157486] Last Call: = (Authentication and Authorization for Constrained Environments (ACE) using= the OAuth 2.0 Framework (ACE-OAuth)) to Proposed Standard > > (BEGIN IANA COMMENTS) > > IESG/Authors/WG Chairs: > > The IANA Functions Operator has completed its review of draft-ietf-ace-o= auth-authz-27. If any part of this review is inaccurate, please let us kno= w. > > The IANA Functions Operator has a question about one of the actions requ= ested in the IANA Considerations section of this document. > > The IANA Functions Operator understands that, upon approval of this docu= ment, there are fifteen actions which we must complete. > > NOTE: We=E2=80=99re asking the ADs how to handle the registrations for w= hich Hannes is the only reviewer. > > IANA Question --> Several sections of the current draft propose to creat= e new registries (Sections 8.1, 8.3, 8.4, 8.6, 8.7, 8.9, and 8.11). For ea= ch of these requests, IANA asks the authors where the new registries are t= o be located. Should they be added to an existing registry page? If not, d= o they belong in an existing category at http://www.iana.org/protocols? Fo= r each of the new registries, it is not clear from the context of the requ= est where the new registries should be established. > Hello WG chairs (WG and ADs in cc), I am in need of some guidance here due to my lack of experience in IANA matters. Do we want to establish a new protocol page for ACE in the IANA registries= ? Alternatively we could add them to the OAuth pages under a specific ACE section. Regards, Ludwig From nobody Sat Dec 21 03:33:40 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389D8120A42; Sat, 21 Dec 2019 03:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 Xidz9GcFAoY5; Sat, 21 Dec 2019 03:33:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 55C65120A32; Sat, 21 Dec 2019 03:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576927976; bh=PlbIRS91vDUu2B0efoV7BODeO9p4r+YzBYtXuShJOCQ=; h=X-UI-Sender-Class:To:Cc:From:Subject:Date; b=AVczpgILYhn7bw96FcAKOCFYKQrGkhssG9Cq2BIchaOfBGExoKVEzPIHkiMHxnnWY MudgIW1Z2cAbrxD+DdmRdzhh3JfFsF8US1g5t+sDRoYanCWnj/rpr4omw6UeksVAIQ q4ZM3JdP/AG4uKL3FUh/2DwKLJ4J5ui0gVS71CiE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGQjH-1iSTAr0QFp-00Gr8R; Sat, 21 Dec 2019 12:32:56 +0100 To: oauth-ext-review@ietf.org Cc: "ace@ietf.org" , Jim Schaad , 'Daniel Migault' , 'Roman Danyliw' , Benjamin Kaduk , drafts-lastcall@iana.org From: Ludwig Seitz Message-ID: Date: Sat, 21 Dec 2019 12:32:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Nx4cde7Fr2036PuG6rjc9omsP4R1AKV0DCCCnVacnnRk6RM6Al2 wJzUXGt5VZwOEUqUd9aBqG5hBORTiBO+cJD42eBGw3DswdJv69viqeAyY8FcGyqMP0VF/e7 OVjGuhM+L/cm5MPdSmekHqw6SexshGcguUKC9oBWdDnl79ku2CbwSLI3p+kx2aMlI6xFwSO z5spyDGrdjLAOTck4Ln3g== X-UI-Out-Filterresults: notjunk:1;V03:K0:mifz2x1K5ro=:SPeW/jM+zwqoMl0F6ZsZMB s2YYLwRDOv/Y3MAP4gclgpOPsGtL2sL5pnXvCWn+EPKTqm+i3NgyenuxfvpgrN1ivQ/qXGfEB 0o2eKAqhMujzdiNO69sdwCJD2W9AZTLQ5x0632Y0PBIx4jfd9lsBCWLxzoc8HTM5lAwTkfQqc BAZVtFelQGSOxPHjTsaaM52NXViVwlqc3sxKaa+lMRHQSO7Pq9wg1CEL2isQe+dGySBSbCL0/ pDy7d0oaI+XtxVYUdPJYQRJyqq0OsUlSGpP921ezOqdtcRDRVYNQsaBFIyZip2oLGeYadU76t HmeKw/KyIJplMdiNXXpCeaZ7BqCW+Ij8hWK6MMoi8KUJDfW0BzxxQ3NzutDg4AiRkrQ6tUcCO uIdT/lsqSK/ZEdlyGtv3xd1BZQGrWSfuPe0PWjS3CJfy6KkgCFovAxfK0oUnlA7ooWCDf36bn f6lUzdZ3MFAQ91Kvy1w9zGT59VXJvaufuFuXznF/jlf7dCJK4nXO7r+KVPTXunnRkQEAWqaYe YJLVQ8vIWEPxf4/wfjzpxywn7JhlGwVbrkbUXCiaqPJqE4aBwXUty4YBySKDeQO6XABKKYbTW D1AP93hPWEIVVajmYMLWpRr2Nn6nlNcQE+FBPoy4iUxgrsNSz+k0ERE+dwGyA7J4m3i/JeKob +8eD7VSeLcCGgW3kOdS3Z1Z/PZ0Wj+Ph7dLQxnJMyQga48JFtR/ZLUb9QpGZM63ISExNwS9uI bXimdTTEH71YGEqDCtkB6ft6q7kEtl4HiaZgzYD49dm5SMBriusNEBK7vjs9q7r30C/bprOxJ SjsDO4mW5qZZPSIHgO8ovyUzsEohtz6Xfwd/hBd23E5vT7JT/KHctPmMtgMxyuSkSY9x9kv4t 98hFk+9GRZi1475oO80OMOCdp1WNYn83rjPiYTvJXzIfwPQpds2QhLNuMRocrsoYnMrwEPUpX lVbbhtQx7MtKs7nOZw1zBl8mocRGMWDHyOcmTBw404KhQB6WYBO/9biaiGdDkclTPUAvIq02L TbLZJpL9vE7Td8+kmiy0RedhFlqEnK2x92om4r13SyLCqc56p6WMDrY0MwLqdB09G2+gmP/2d E+IUo9STVnDtNVYtHsIeqw62Fw5i2yqsM9LorLwJDkrQHUdJGamnUKbYaTyqrz10h/Esvd/x3 1xn/uiiGvLYb/oEc3XoZt9nyTfOSGf10SJ6MwmNUEyPBI9sXGdF7AAKdwQo+QZI9rZQ03zyHA 7EEuacr6i89Ojvtw+o0xf+BF3Sxlw5o9//M08PoQRB82aJqOtmi60w894DVc= Archived-At: Subject: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 11:33:38 -0000 Hello OAuth registry reviewers, the IESG-designated experts for the OAuth parameters registry have asked me to send a review request to you about the OAuth parameters registered here: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.2 and here: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.5 and here: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.8 and here: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.10 Thank you in advance for you review comments. Regards, Ludwig From nobody Sat Dec 21 03:35:39 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59515120A32; Sat, 21 Dec 2019 03:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 qZVg6uhX41zl; Sat, 21 Dec 2019 03:35:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 914CD120A42; Sat, 21 Dec 2019 03:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576928115; bh=gViPK7s7bjGsG7WQlqbFTmLt3KRfR4cJHPpPgnRsMAE=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=ccWmaMvTdCUoZzGnYYhCFWy50xBgCbpdrO/UCYuqS2FGfGPuRL+PjMMSbeW+EqtQV Yujo9UnbgHTtj45b+ebjFlg4UVtSysBtoBaWEmU0xUztXwPzv7ldMzVSjGK8kgKBBQ 0pyRJ2myfeKluyQeLI1Lh/TPAXER2UBPd8nAzgzg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MQ5vW-1iMiQt1Uem-00M422; Sat, 21 Dec 2019 12:35:15 +0100 From: Ludwig Seitz To: jwt-reg-review@ietf.org Cc: Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , 'The IESG' , 'Roman Danyliw' , drafts-lastcall@iana.org References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> Message-ID: Date: Sat, 21 Dec 2019 12:35:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:tF+ewU5MTf/RR6JN33vR4xxnNSZUhJjP+EXi6BceaJNoZBSLzUI G61upo3LLbZtqadaTuxzWRg2PTxcEXe4uoErpUDixYG7LAZJBVGBwy86Sxf616iYgO/RfDr YnHsaisrf4953Yj3ADRakyo7FFZIbbU63rzRzt9Uq1Xyjz3Exej3RBShMMx85ioWpnFIFnT 16ZIzxkc+2abo3E2VTGAQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:KGj8sIj2UlQ=:bCYoRtm1Ae7UAIBL22j8P5 QlcbJICQfXHyQU0sdgCfGBgbmUwLzIm91hi8WzD9JsAAmpGgeElPYaTOrvcLPdJW5VY21zjNs K/J35+4zIP3dja1C5wgJC8eFzwLS6wMtJjObHQXX0Wz05IJUPRInmbLnitR5TO++mYkPZhwr/ iCPclIH/kmp71ubVRP6N14sKAA9DThTQ42YP3GoVVRk3GEfHj9ngKV7HvJ0lWnzGVDltGIFDX 2FdiLv1Ktd6LZkXSFFl1VCrvD9eVYFMhxT5+iaXaWB2IUMinOXZB2Nty078mjRqrHf3YaVW5e uA9hRYnTAQ+2YAPQ8n0Nd2O8pzlzrCNLtT4/0nYCeoHkgM/j/I8i3t0E6RrCwNM2VmkceZxPL pCl81m6HeEmfAyOiVowjtSNIoj5GVM//4r/WUC/k4N1YyVOTlKhDlymbWtRZ/+McYvGucpod5 qugs9DNg9RWpA+HIa2sjObxA20DNGgX/2mRXuB9p1hPk/tiapTw7VAidaG2YCi0kd2dIjpbn+ 11qq1w6RnHvn1TBdiAJ26U/v/xe1eO2LnewMBR7HDgWqvyGT2NhuRP0fCZ3WSfRyQ/C/eDNhl rmVfjtgYXRuiAe2/kRSOY4eUvI072oAXhQUtIm8cJwJQHjjs5fu44lWGjl/+AZ7XbwJ0MPNAr e8LBP02p4VMdSp2BkW2nJdsFELZaQ/0lTkC3xz3UTuTDjaQGW05JiRclFHX0ZqZ9o6tot+kxl NjfQyDjCfgM/h3t7FW3NThYztpXi6p4NBihtqTv1Sq025jsIOV+I4AoJtrIZXD8WOeGy3zMM9 4UcKALPAW7XMFw3oVS10djQZgbGiLW5RAsZIfc+xq263QS8zSt6L0V1KEhsU9FGG9NDqTxQDf CpLiXz3luetXLXoDuYDscjEEmiwfIhZCGjs9mBG2S7tusJylly57rvbdUE/fiRzDfA3o6U/Vd uGZN/djXcIAGGgp+N4hs2eTjMWmFnQsLeJUsefIS8qp+Rjy+jFt21tD2qa2AQM9CPILe4ZwRf wuN0HN7ASB26iogFLTznW/oUGpbW+Qx6ye1rv2G28p3PBqFeG73NXHm8zKscOHU7y4PqByC3J wgB+zAonH35IawJ866aCOgBBeqvH1FnP4PUJ9BJWCnMbW1HIgMChhc7ZHEKUVjBXWcbtaCxEG 8HcwyNFqyEM9MyPTCSoJahbVYRAWmw+j8SaaDZKY91kK7Qah/qaKP7mStHG18sfywYccDM4vg Pox3XNV8annZxkjSDuSTVgXfPiELWCZ3RyHif/k/9xQUSKv8XBUV4/ymBMYU= Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 11:35:32 -0000 Hello JWT registry reviewers, the IESG-designated experts for the JWT claims registry have asked me to send a review request to you about the claims registered here: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.12 Thank you in advance for you review comments. Regards, Ludwig From nobody Sat Dec 21 03:37:10 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955D2120A42; Sat, 21 Dec 2019 03:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 AyipakRF03v1; Sat, 21 Dec 2019 03:36:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 86EA9120A32; Sat, 21 Dec 2019 03:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576928200; bh=ywHRkovoxnJruPOMDwG9Q9x7QcTj7kPBajnZz6NAQks=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=H6RtYdozf9vLKtrG6w/5WE5oxW9YcwzORziOTO5qDHeamL7Ru+lMxRQLWJDMi8aQj C6uZf4TVR9ZIIdoNXbOQtVBSoVL8cocmETu+4A5SW4hKVDMhxz82nPMgQ35ze6uMoB MtzLE74bJs2Brzi6BpaxGberZ96rqkmyDJQHNp0U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MMGRA-1iPS180Eje-00JIt1; Sat, 21 Dec 2019 12:36:40 +0100 From: Ludwig Seitz To: cwt-reg-review@ietf.org Cc: Jim Schaad , 'Daniel Migault' , "ace@ietf.org" , 'The IESG' , 'Roman Danyliw' , drafts-lastcall@iana.org, Benjamin Kaduk References: <03f0f73f-4c82-9089-0a81-471a5fb54ba8@gmx.de> Message-ID: Date: Sat, 21 Dec 2019 12:36:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <03f0f73f-4c82-9089-0a81-471a5fb54ba8@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:xg3gChGhlmYmlYky/K+V1x01hSXL2+yXmXVGNAU9TSwUbHG6LUb ZQmHvPrRWpwB4tFMbJFmqCEsubpW3WaaiIb+aOAh9uR4zg0n3ON6H69g78/ozkWWfGHMEpa MVj+sIUyV0HMW2kQdJ59tfH0ez53KLRmvBkUaEvEWdDW4DI427X9poUp5DyuvpHxyDNDuOP vCnjvIzyAQEr2QrcV1jYw== X-UI-Out-Filterresults: notjunk:1;V03:K0:jU9KAxhaxPA=:XzcB9lHjpr0vZ91IOGrPGQ mNnpehaXllySLd+dJ76KvAobxDrpNJp8lccTc7UZLe5Rbil6NXGYC/v1pkUs6BbODaKLemEve 72LxYvyDTgkCg/meHeuix0BlKf5h7N9X4jqsBQM7hTU+zPbzJXcjGuKSy99JQSc/uFMjwl767 MnaFDECyMXhZdnJksxIL2/WZYq/J5xR4HHtzDCPBG/7zAXOXmW2683URNvfrFeVpzg3tpHTA+ NOVGK4X3ZaZxanBPZrADpZfUU4RjNFbAkPi+eB8qUygES2IGZhCZmn/mr5Yuks0h5GY+f8ZI4 YW9/DG+we65oytsVzOf3enXKOWyoUtGiY/QgdE9h0kiuwIr5WGWrsNMxoMclUudkntITIV8Mf EHwipQ8d56Oozy1ihlYiwlzbMMz4Mx79Sw7dup0XTsfdYbAK+7aI6vdTDWuoL+lsE+RG5zgd+ wL81Ab7tQn1Uio0e2sBWLMzobkDYF1ujG6VRFA+rW1YlkZaRBxnJNVpG41ylQE+xwH6Vo9bWD ct2BTlBaHwch8M+1RDMjsXCtul9c1lgsUaXFkAsbXmQ0nbVtir0sVqEOWUG/N0F46ouFcZZi1 uX5SF8W3uLlQ4R7bYhAqp1wwIMO966KdsF+bVjAAfuE14t3qr5Dj9MNXEaAE6VL06ZT4e+mS4 /KlZYtzJLIs64XgMfBMqY3aDnC/J9z3Pj5joUG4B3+tEbCe+9Qz7/ZaHoexlslMWO1E4sMVQI Bfuf2stflxuypmeW+qBQ/T7KgW9V+HI1FMoYuMgsL1TO+lPztT6Yv3TUGi0t//nL/wURcUK7B h0CP0sgmUBQ+pVDDYTPDdm+1e6cieBKuDiSBU06QdBwfV0Ay7xc11Qk0Kn7mFWxiOe8P3K0wl EVV9ORU1AEuOaPmVhKqC4Q3V9MzQ5QQJVpqaElOdF1QJeCUHdyBwf82caShm/AudJ+Okq4lb3 zOSaM2prtIXPgXYo9QxlMutoxvjWnZi2RQS4COM6ouJHVnZAmaXaTHqVqkubz9OyRboEBvdZW gHwWVW/C9h7wTcGx+P5dDHgRZVLevKjdIl6Xm+cq7pMqHUwtVouskavkd7Datcx83HBdejYfJ kmWmSN9vVpeaIS9akF2SKVB7BZEWvfhZucEEJkZf9vxHpn9hhmWslyF1E93b2NnKlYAFgrL1M Nr0nXnYQFiykcU6Yv0YMadSnTZ9bl/k+TJX2JcTFTl27ghZdrjlslHxoWAl57Qby5U6WZkj9V 1skoVqLhlKRGCA3dSs39UZFkXONzcORzQks0y1PcUj8M44ZBaoaAqzuz77uE= Archived-At: Subject: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 11:36:58 -0000 Hello CWT registry reviewers, the IESG-designated experts for the CWT claims registry have asked me to send a review request to you about the claims registered here: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.13 Thank you in advance for you review comments. Regards, Ludwig From nobody Sat Dec 21 04:20:54 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF1120A47; Sat, 21 Dec 2019 04:20:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.114.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157693085291.26419.9876086620697593346@ietfa.amsl.com> Date: Sat, 21 Dec 2019 04:20:52 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 12:20:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-08.txt Pages : 12 Date : 2019-12-21 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client whishes to use, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 21 04:22:47 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A4B120A47; Sat, 21 Dec 2019 04:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 Y0fmdjIuGifJ; Sat, 21 Dec 2019 04:22:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 E4F29120A42; Sat, 21 Dec 2019 04:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576930950; bh=PAgucxF7fFYdQWmcVVZPUDfnj6fmKMphhne7vwVy5/k=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=lY1WIS0df0EG2Pg+KEaTbmP5SYhiwfdCgKt+ZeVwapJhdNtfoxbUcC+RSidbBjncO gibv7OoaPoEWgI8izJBESKuUe9u9MtaFBku3/5ogcG4DuYqoOmtzC8+beDu5VmcK/R owbdfh5AX9smlIHk4EFGidhvvWOz553mLCK+M00Y= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTiPv-1iFJEJ1iyz-00TyLZ; Sat, 21 Dec 2019 13:22:30 +0100 To: elwynd , elwynd@dial.pipex.com Cc: last-call@ietf.org, gen-art@ietf.org, ace@ietf.org References: From: Ludwig Seitz Message-ID: Date: Sat, 21 Dec 2019 13:22:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:XVZtn7gTOwtnIEgAI42qohb6GFJtqLsvdFAiA6GTLNHh8d5YVZ7 sLjxZpSRq07lWDl4CzQUOcbttRLx+zdyhv+y9nOpe+tTAvUYtZ9M+4nqyhBWQ+hQkPs1cDK jTbIQ92ZM+/O+JGdsu5VFvCRbJtJVHKXL7zkQ+argPcyuD557ioe2rGM3uuyEiW/0MUTA/d cfp9DWf+OetZbKg36nEnw== X-UI-Out-Filterresults: notjunk:1;V03:K0:7BcfLeo99B0=:NWRJSWbboxwyffCdlhULfn 8O5y1vbYQoCFPRUxJ4Hnen5d8jubsHBv7U/6x4DsuOrVnIw4nSo0OazUrg5Zk92Llm94u3MPa 7AgYWPEcZuzdLL1LER+YeHM68ii8ZlCstVxQqCz+IPe5WmRo8CPBQiRP0diJ9T4p3zJKoyRaH yA8cJNpL6uymdKo9BQe+JefqXZnYwKv7kiFRCLrFyDuMkTDV/woOEaRum+JmlhUmSLuMurCdW AUhLqFIvqHcj9wwTRz/mC0xwLfG1A+IcLCGGy8B7qwnlo3WqrCkyn1EdPNnuSq4Faap6al092 RRIfyi4MN7P8MbjiHhZR1kaxFveD5FJn1FKtEArXq4Gi2VxWyQlWK+VjejoijS3sl81kHqZ0i OBmzw02RPnhymrNA1h8drVpdREBFoZZxlLM9VEZIJWnkBAzjv2vUCwNkLfgZ8QLEPfdda/xQV p5WHg2p5GdO1Bt63JVnK4Cyz7Hpk6uAxaXyjlnXCD8l/EY1Jl3r5Q28BkdSeLWrzgQE3Pcwa+ ggFz4+7IKqJdNXvjgTauhrqpJ61FgB+RZCAyG3n1G4pZwEbdNsbLrrobxg06JTtcebW83G/BR fZfnXGs5rR7ibVd9tpCJ099YVis7ll+AAHv8dRGAczcN/GmKvdhXAuEZ5tpQ88RmAhmd48UcX yGxzGibR/XrHaYaguoM3JJlL7FAHx4yH59uXu6mBYo7349hR+ROcXV31XBCbkeRY/yQBOnn9P SI5p8kxz/7T2A8qr8GVh2sJMEQeL6cv35lIKh0SGh3nu5h7KMN4ll4ewSOSbS9sqTV0ZFum0O /yqFKccyzGuNvdpLSbgJXyyYXoclDfvlxm06Xxk/K4DckH8Gl2JhE6YzLCLCvMHQVTi/XoJhv oDs2dvoMmoJi7hzCbTLScUGzs2GbXaUdsD8oy+1uGJeHYhprqLC+ZmgBYIFc1CKYGZwWE8RLh IO3Gnj/YRg9/rCv8ieLmoYt7LM3pQu9M3mWPuajZTARBPTeXpRvAQJJTFH8+4P280efukMu7f D9NxHur97NYKIWKxPyo8q3A3xnwdeEQsoreqbeEasQqSevYvH8MNRKgYL/KDQQ5B36+KLygvo XZFJcJSdxQNfFQQyRUk34zD5eBF/gFEUuI+0nNRl+ipDdFH+EWTKWCk0NwFcnYgUTQ7TuSMSv R2ddBMtK2SAP5EeF9isSEruHMeQIe47k1IQoXRh3MTV61sJoRBjHQdq5m+zMqhF79BKaWb6BZ 4UhA5s6C+SxnfSmP73cviAH+X+BLM+GKO8lSF3WqKAz/buoJ/f4bGSHsX3Tg= Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 12:22:37 -0000 On 2019-12-19 21:23, elwynd wrote: > Hi, Ludwig. > > Thanks for the prompt response. > > Regarding he major issue, I understand what the intention of the split > was, but as far as early implementations are concerned, there is no such > thing as a 'minimal breakage'; unless there is some cunning mechanism in > the basic ace-oauth-authz protocol, changes to the structure of the > items defined here will break the protocol.=C2=A0 One possibility that I > could see is the addition of extra keys in the COSE_Key dictionary > structure: In this case you could add some extra words (in the > ace-oauth-authz document) to indicate that unrecognized keys should be > ignored.=C2=A0 This is associated with the editorial comments I made abo= ut > s3.1 that would allow any other keys to be present in the COSE_Key > object structure.=C2=A0 Similarly, the obects defined here are effective= ly > JSON/CBOR dictionaries.=C2=A0 The changes could be accomodated by adding > comments in ace-oauth that extra keys in the items defined would be > ignored. > > In my opinion, it would be best to remove the comments about possible > changes and just state that they have been separated out because they > might be used in other contexts.=C2=A0 The possible 'changes to the > definitions' issue is just a matter of 'institutional memory'.=C2=A0 If = there > is some mechanism, such as I mentioned above, to accommodate changes > without neeeding an update to the ace-oauth-authz (or other protocols > using these items), this should be explained. I have submitted an updated draft (-08) that removes the comments about possible changes. Does this address your major issue? > > Regarding the h vs b64 representations, since they are only examples > (and the strings are essentially arbitrary as the actual keys aren't in > the document), I'd be inclined to put in h representations to avoid my > question arisng. In my newly submitted draft all the b64 representations have been replaced by equivalent h representations. Note that none of these strings are arbitrary, since they do parse to actual keys. The abbreviated b64 strings representing tokens obviously do not parse as such, but come from the actual binary representation of tokens. Happy holidays, Ludwig From nobody Sat Dec 21 05:50:09 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4F120A58; Sat, 21 Dec 2019 05:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 28ArMM8xZZpz; Sat, 21 Dec 2019 05:50:06 -0800 (PST) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266F9120071; Sat, 21 Dec 2019 05:50:06 -0800 (PST) Received: from 6.c.7.a.1.7.5.6.7.5.0.b.b.6.5.f.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:f56b:b057:6571:a7c6]) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iif8u-0006en-AW; Sat, 21 Dec 2019 13:50:04 +0000 SavedFromEmail: elwynd@folly.org.uk Date: Sat, 21 Dec 2019 13:50:00 +0000 In-Reply-To: Importance: normal From: elwynd To: Ludwig Seitz , elwynd@dial.pipex.com Cc: last-call@ietf.org, gen-art@ietf.org, ace@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_4412176544564270" Message-ID: Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 13:50:08 -0000 ----_com.samsung.android.email_4412176544564270 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIEx1ZHdpZy5ZZXMsIC0wOCBhZGRyZXNzZXMgdGhlIHR3byBwb2ludHMgbm90ZWQgYmVsb3cu Li4gdW5mb3J0dW5hdGVseSB5b3UgZGlkbid0IGZpeCB0aGUgdmFyaW91cyBuaXRzIGFuZCB0aGUg b3RoZXIgbWlub3IgaXNzdWVzIGFzIHlvdSBpbmRpY2F0ZWQgeW91IHdlcmUgaW50ZW5kaW5nIHRv IGluIHlvdXIgaW5pdGlhbCByZXNwb25zZSAoRUMgPT4gRUMyLCBldGMpLkVuam95IHRoZSBob2xp ZGF5cyFDaGVlcnMsRWx3eW5TZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuCi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBMdWR3aWcgU2VpdHogPGx1ZHdpZ19zZWl0ekBnbXgu ZGU+IERhdGU6IDIxLzEyLzIwMTkgIDEyOjIyICAoR01UKzAwOjAwKSBUbzogZWx3eW5kIDxlbHd5 bmRAZm9sbHkub3JnLnVrPiwgZWx3eW5kQGRpYWwucGlwZXguY29tIENjOiBsYXN0LWNhbGxAaWV0 Zi5vcmcsIGdlbi1hcnRAaWV0Zi5vcmcsIGFjZUBpZXRmLm9yZyBTdWJqZWN0OiBSZTogW0dlbi1h cnRdIFtBY2VdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mCsKgIGRyYWZ0LWlldGYtYWNlLW9h dXRoLXBhcmFtcy0wNiBPbiAyMDE5LTEyLTE5IDIxOjIzLCBlbHd5bmQgd3JvdGU6PiBIaSwgTHVk d2lnLj4+IFRoYW5rcyBmb3IgdGhlIHByb21wdCByZXNwb25zZS4+PiBSZWdhcmRpbmcgaGUgbWFq b3IgaXNzdWUsIEkgdW5kZXJzdGFuZCB3aGF0IHRoZSBpbnRlbnRpb24gb2YgdGhlIHNwbGl0PiB3 YXMsIGJ1dCBhcyBmYXIgYXMgZWFybHkgaW1wbGVtZW50YXRpb25zIGFyZSBjb25jZXJuZWQsIHRo ZXJlIGlzIG5vIHN1Y2g+IHRoaW5nIGFzIGEgJ21pbmltYWwgYnJlYWthZ2UnOyB1bmxlc3MgdGhl cmUgaXMgc29tZSBjdW5uaW5nIG1lY2hhbmlzbSBpbj4gdGhlIGJhc2ljIGFjZS1vYXV0aC1hdXRo eiBwcm90b2NvbCwgY2hhbmdlcyB0byB0aGUgc3RydWN0dXJlIG9mIHRoZT4gaXRlbXMgZGVmaW5l ZCBoZXJlIHdpbGwgYnJlYWsgdGhlIHByb3RvY29sLsKgIE9uZSBwb3NzaWJpbGl0eSB0aGF0IEk+ IGNvdWxkIHNlZSBpcyB0aGUgYWRkaXRpb24gb2YgZXh0cmEga2V5cyBpbiB0aGUgQ09TRV9LZXkg ZGljdGlvbmFyeT4gc3RydWN0dXJlOiBJbiB0aGlzIGNhc2UgeW91IGNvdWxkIGFkZCBzb21lIGV4 dHJhIHdvcmRzIChpbiB0aGU+IGFjZS1vYXV0aC1hdXRoeiBkb2N1bWVudCkgdG8gaW5kaWNhdGUg dGhhdCB1bnJlY29nbml6ZWQga2V5cyBzaG91bGQgYmU+IGlnbm9yZWQuwqAgVGhpcyBpcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIGVkaXRvcmlhbCBjb21tZW50cyBJIG1hZGUgYWJvdXQ+IHMzLjEgdGhh dCB3b3VsZCBhbGxvdyBhbnkgb3RoZXIga2V5cyB0byBiZSBwcmVzZW50IGluIHRoZSBDT1NFX0tl eT4gb2JqZWN0IHN0cnVjdHVyZS7CoCBTaW1pbGFybHksIHRoZSBvYmVjdHMgZGVmaW5lZCBoZXJl IGFyZSBlZmZlY3RpdmVseT4gSlNPTi9DQk9SIGRpY3Rpb25hcmllcy7CoCBUaGUgY2hhbmdlcyBj b3VsZCBiZSBhY2NvbW9kYXRlZCBieSBhZGRpbmc+IGNvbW1lbnRzIGluIGFjZS1vYXV0aCB0aGF0 IGV4dHJhIGtleXMgaW4gdGhlIGl0ZW1zIGRlZmluZWQgd291bGQgYmU+IGlnbm9yZWQuPj4gSW4g bXkgb3BpbmlvbiwgaXQgd291bGQgYmUgYmVzdCB0byByZW1vdmUgdGhlIGNvbW1lbnRzIGFib3V0 IHBvc3NpYmxlPiBjaGFuZ2VzIGFuZCBqdXN0IHN0YXRlIHRoYXQgdGhleSBoYXZlIGJlZW4gc2Vw YXJhdGVkIG91dCBiZWNhdXNlIHRoZXk+IG1pZ2h0IGJlIHVzZWQgaW4gb3RoZXIgY29udGV4dHMu wqAgVGhlIHBvc3NpYmxlICdjaGFuZ2VzIHRvIHRoZT4gZGVmaW5pdGlvbnMnIGlzc3VlIGlzIGp1 c3QgYSBtYXR0ZXIgb2YgJ2luc3RpdHV0aW9uYWwgbWVtb3J5Jy7CoCBJZiB0aGVyZT4gaXMgc29t ZSBtZWNoYW5pc20sIHN1Y2ggYXMgSSBtZW50aW9uZWQgYWJvdmUsIHRvIGFjY29tbW9kYXRlIGNo YW5nZXM+IHdpdGhvdXQgbmVlZWRpbmcgYW4gdXBkYXRlIHRvIHRoZSBhY2Utb2F1dGgtYXV0aHog KG9yIG90aGVyIHByb3RvY29scz4gdXNpbmcgdGhlc2UgaXRlbXMpLCB0aGlzIHNob3VsZCBiZSBl eHBsYWluZWQuSSBoYXZlIHN1Ym1pdHRlZCBhbiB1cGRhdGVkIGRyYWZ0ICgtMDgpIHRoYXQgcmVt b3ZlcyB0aGUgY29tbWVudHMgYWJvdXRwb3NzaWJsZSBjaGFuZ2VzLiBEb2VzIHRoaXMgYWRkcmVz cyB5b3VyIG1ham9yIGlzc3VlPz4+IFJlZ2FyZGluZyB0aGUgaCB2cyBiNjQgcmVwcmVzZW50YXRp b25zLCBzaW5jZSB0aGV5IGFyZSBvbmx5IGV4YW1wbGVzPiAoYW5kIHRoZSBzdHJpbmdzIGFyZSBl c3NlbnRpYWxseSBhcmJpdHJhcnkgYXMgdGhlIGFjdHVhbCBrZXlzIGFyZW4ndCBpbj4gdGhlIGRv Y3VtZW50KSwgSSdkIGJlIGluY2xpbmVkIHRvIHB1dCBpbiBoIHJlcHJlc2VudGF0aW9ucyB0byBh dm9pZCBteT4gcXVlc3Rpb24gYXJpc25nLkluIG15IG5ld2x5IHN1Ym1pdHRlZCBkcmFmdCBhbGwg dGhlIGI2NCByZXByZXNlbnRhdGlvbnMgaGF2ZSBiZWVucmVwbGFjZWQgYnkgZXF1aXZhbGVudCBo IHJlcHJlc2VudGF0aW9ucy5Ob3RlIHRoYXQgbm9uZSBvZiB0aGVzZSBzdHJpbmdzIGFyZSBhcmJp dHJhcnksIHNpbmNlIHRoZXkgZG8gcGFyc2UgdG9hY3R1YWwga2V5cy4gVGhlIGFiYnJldmlhdGVk IGI2NCBzdHJpbmdzIHJlcHJlc2VudGluZyB0b2tlbnMgb2J2aW91c2x5ZG8gbm90IHBhcnNlIGFz IHN1Y2gsIGJ1dCBjb21lIGZyb20gdGhlIGFjdHVhbCBiaW5hcnkgcmVwcmVzZW50YXRpb24gb2Z0 b2tlbnMuSGFwcHkgaG9saWRheXMsTHVkd2ln ----_com.samsung.android.email_4412176544564270 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5IaSwgTHVkd2lnLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9 ImF1dG8iPlllcywgLTA4IGFkZHJlc3NlcyB0aGUgdHdvIHBvaW50cyBub3RlZCBiZWxvdy4uLiB1 bmZvcnR1bmF0ZWx5IHlvdSBkaWRuJ3QgZml4IHRoZSB2YXJpb3VzIG5pdHMgYW5kIHRoZSBvdGhl ciBtaW5vciBpc3N1ZXMgYXMgeW91IGluZGljYXRlZCB5b3Ugd2VyZSBpbnRlbmRpbmcgdG8gaW4g eW91ciBpbml0aWFsIHJlc3BvbnNlIChFQyA9Jmd0OyBFQzIsIGV0YykuPC9kaXY+PGRpdiBkaXI9 ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+RW5qb3kgdGhlIGhvbGlkYXlzITwvZGl2 PjxkaXYgZGlyPSJhdXRvIj5DaGVlcnMsPC9kaXY+PGRpdiBkaXI9ImF1dG8iPkVsd3luPC9kaXY+ PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiIGRp cj0iYXV0byI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9ImF1 dG8iPlNlbnQgZnJvbSBTYW1zdW5nIHRhYmxldC48L2Rpdj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+ PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9y OiMwMDAwMDAiIGRpcj0iYXV0byI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0t LSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBMdWR3aWcgU2VpdHog Jmx0O2x1ZHdpZ19zZWl0ekBnbXguZGUmZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogMjEvMTIvMjAxOSAg MTI6MjIgIChHTVQrMDA6MDApIDwvZGl2PjxkaXY+VG86IGVsd3luZCAmbHQ7ZWx3eW5kQGZvbGx5 Lm9yZy51ayZndDssIGVsd3luZEBkaWFsLnBpcGV4LmNvbSA8L2Rpdj48ZGl2PkNjOiBsYXN0LWNh bGxAaWV0Zi5vcmcsIGdlbi1hcnRAaWV0Zi5vcmcsIGFjZUBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1 YmplY3Q6IFJlOiBbR2VuLWFydF0gW0FjZV0gR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YKJm5i c3A7IGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wNiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 L2Rpdj5PbiAyMDE5LTEyLTE5IDIxOjIzLCBlbHd5bmQgd3JvdGU6PGJyPiZndDsgSGksIEx1ZHdp Zy48YnI+Jmd0Ozxicj4mZ3Q7IFRoYW5rcyBmb3IgdGhlIHByb21wdCByZXNwb25zZS48YnI+Jmd0 Ozxicj4mZ3Q7IFJlZ2FyZGluZyBoZSBtYWpvciBpc3N1ZSwgSSB1bmRlcnN0YW5kIHdoYXQgdGhl IGludGVudGlvbiBvZiB0aGUgc3BsaXQ8YnI+Jmd0OyB3YXMsIGJ1dCBhcyBmYXIgYXMgZWFybHkg aW1wbGVtZW50YXRpb25zIGFyZSBjb25jZXJuZWQsIHRoZXJlIGlzIG5vIHN1Y2g8YnI+Jmd0OyB0 aGluZyBhcyBhICdtaW5pbWFsIGJyZWFrYWdlJzsgdW5sZXNzIHRoZXJlIGlzIHNvbWUgY3Vubmlu ZyBtZWNoYW5pc20gaW48YnI+Jmd0OyB0aGUgYmFzaWMgYWNlLW9hdXRoLWF1dGh6IHByb3RvY29s LCBjaGFuZ2VzIHRvIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlPGJyPiZndDsgaXRlbXMgZGVmaW5lZCBo ZXJlIHdpbGwgYnJlYWsgdGhlIHByb3RvY29sLiZuYnNwOyBPbmUgcG9zc2liaWxpdHkgdGhhdCBJ PGJyPiZndDsgY291bGQgc2VlIGlzIHRoZSBhZGRpdGlvbiBvZiBleHRyYSBrZXlzIGluIHRoZSBD T1NFX0tleSBkaWN0aW9uYXJ5PGJyPiZndDsgc3RydWN0dXJlOiBJbiB0aGlzIGNhc2UgeW91IGNv dWxkIGFkZCBzb21lIGV4dHJhIHdvcmRzIChpbiB0aGU8YnI+Jmd0OyBhY2Utb2F1dGgtYXV0aHog ZG9jdW1lbnQpIHRvIGluZGljYXRlIHRoYXQgdW5yZWNvZ25pemVkIGtleXMgc2hvdWxkIGJlPGJy PiZndDsgaWdub3JlZC4mbmJzcDsgVGhpcyBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIGVkaXRvcmlh bCBjb21tZW50cyBJIG1hZGUgYWJvdXQ8YnI+Jmd0OyBzMy4xIHRoYXQgd291bGQgYWxsb3cgYW55 IG90aGVyIGtleXMgdG8gYmUgcHJlc2VudCBpbiB0aGUgQ09TRV9LZXk8YnI+Jmd0OyBvYmplY3Qg c3RydWN0dXJlLiZuYnNwOyBTaW1pbGFybHksIHRoZSBvYmVjdHMgZGVmaW5lZCBoZXJlIGFyZSBl ZmZlY3RpdmVseTxicj4mZ3Q7IEpTT04vQ0JPUiBkaWN0aW9uYXJpZXMuJm5ic3A7IFRoZSBjaGFu Z2VzIGNvdWxkIGJlIGFjY29tb2RhdGVkIGJ5IGFkZGluZzxicj4mZ3Q7IGNvbW1lbnRzIGluIGFj ZS1vYXV0aCB0aGF0IGV4dHJhIGtleXMgaW4gdGhlIGl0ZW1zIGRlZmluZWQgd291bGQgYmU8YnI+ Jmd0OyBpZ25vcmVkLjxicj4mZ3Q7PGJyPiZndDsgSW4gbXkgb3BpbmlvbiwgaXQgd291bGQgYmUg YmVzdCB0byByZW1vdmUgdGhlIGNvbW1lbnRzIGFib3V0IHBvc3NpYmxlPGJyPiZndDsgY2hhbmdl cyBhbmQganVzdCBzdGF0ZSB0aGF0IHRoZXkgaGF2ZSBiZWVuIHNlcGFyYXRlZCBvdXQgYmVjYXVz ZSB0aGV5PGJyPiZndDsgbWlnaHQgYmUgdXNlZCBpbiBvdGhlciBjb250ZXh0cy4mbmJzcDsgVGhl IHBvc3NpYmxlICdjaGFuZ2VzIHRvIHRoZTxicj4mZ3Q7IGRlZmluaXRpb25zJyBpc3N1ZSBpcyBq dXN0IGEgbWF0dGVyIG9mICdpbnN0aXR1dGlvbmFsIG1lbW9yeScuJm5ic3A7IElmIHRoZXJlPGJy PiZndDsgaXMgc29tZSBtZWNoYW5pc20sIHN1Y2ggYXMgSSBtZW50aW9uZWQgYWJvdmUsIHRvIGFj Y29tbW9kYXRlIGNoYW5nZXM8YnI+Jmd0OyB3aXRob3V0IG5lZWVkaW5nIGFuIHVwZGF0ZSB0byB0 aGUgYWNlLW9hdXRoLWF1dGh6IChvciBvdGhlciBwcm90b2NvbHM8YnI+Jmd0OyB1c2luZyB0aGVz ZSBpdGVtcyksIHRoaXMgc2hvdWxkIGJlIGV4cGxhaW5lZC48YnI+PGJyPkkgaGF2ZSBzdWJtaXR0 ZWQgYW4gdXBkYXRlZCBkcmFmdCAoLTA4KSB0aGF0IHJlbW92ZXMgdGhlIGNvbW1lbnRzIGFib3V0 PGJyPnBvc3NpYmxlIGNoYW5nZXMuIERvZXMgdGhpcyBhZGRyZXNzIHlvdXIgbWFqb3IgaXNzdWU/ PGJyPjxicj4mZ3Q7PGJyPiZndDsgUmVnYXJkaW5nIHRoZSBoIHZzIGI2NCByZXByZXNlbnRhdGlv bnMsIHNpbmNlIHRoZXkgYXJlIG9ubHkgZXhhbXBsZXM8YnI+Jmd0OyAoYW5kIHRoZSBzdHJpbmdz IGFyZSBlc3NlbnRpYWxseSBhcmJpdHJhcnkgYXMgdGhlIGFjdHVhbCBrZXlzIGFyZW4ndCBpbjxi cj4mZ3Q7IHRoZSBkb2N1bWVudCksIEknZCBiZSBpbmNsaW5lZCB0byBwdXQgaW4gaCByZXByZXNl bnRhdGlvbnMgdG8gYXZvaWQgbXk8YnI+Jmd0OyBxdWVzdGlvbiBhcmlzbmcuPGJyPjxicj5JbiBt eSBuZXdseSBzdWJtaXR0ZWQgZHJhZnQgYWxsIHRoZSBiNjQgcmVwcmVzZW50YXRpb25zIGhhdmUg YmVlbjxicj5yZXBsYWNlZCBieSBlcXVpdmFsZW50IGggcmVwcmVzZW50YXRpb25zLjxicj48YnI+ Tm90ZSB0aGF0IG5vbmUgb2YgdGhlc2Ugc3RyaW5ncyBhcmUgYXJiaXRyYXJ5LCBzaW5jZSB0aGV5 IGRvIHBhcnNlIHRvPGJyPmFjdHVhbCBrZXlzLiBUaGUgYWJicmV2aWF0ZWQgYjY0IHN0cmluZ3Mg cmVwcmVzZW50aW5nIHRva2VucyBvYnZpb3VzbHk8YnI+ZG8gbm90IHBhcnNlIGFzIHN1Y2gsIGJ1 dCBjb21lIGZyb20gdGhlIGFjdHVhbCBiaW5hcnkgcmVwcmVzZW50YXRpb24gb2Y8YnI+dG9rZW5z Ljxicj48YnI+SGFwcHkgaG9saWRheXMsPGJyPjxicj5MdWR3aWc8YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_4412176544564270-- From nobody Sat Dec 21 07:28:19 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995E1120025 for ; Sat, 21 Dec 2019 07:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 YHWdtxc6ENCM for ; Sat, 21 Dec 2019 07:28:16 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20058.outbound.protection.outlook.com [40.107.2.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6AF120013 for ; Sat, 21 Dec 2019 07:28:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H3HmyHxcnV9oy7dgNLvP+7J0AVX2lKw8dckK9zQMb6GUboz5szlyIaapvWnW/ou+m4oQ1Ly9v4K1qk5eSgQQt1JunXkgYWzwbc8YLmzMvX80yJHm5B5RSIy8teB+SlbnNpy+HFWDBOSE0jgECwZJeeHAp8/vCY9tyKhqP9HVdjlV5DMeq3GyX1SxTf+ELxzIapOB6uIhuCRvK9AzxwpNteYvgBKepy7HRthQRB+s3mfGxhkdDnAskiJltWXlVNO1FJu2bGT2XbHvXEQ16c5efGlbmCbJt04lS2HyTabdF60mauxvhDev0B/jVlxE8bwBRGB8o5Kb/+1bYn4j5AMUDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T0fP7BCMtSTPAhLfQM77ftx/kfDm+bzSxRYB71fRK0E=; b=PYmAM+BvUy8Xtxkx23D0DsFr92HaW8mygp1Xap9pJgKY/pHAEQTThPa18MxZqQfr9fPABuRYWOawr2UR3eHJR/FknyDE0KZdfUVH25miRQm3H7xUMk3yOsN6nJrC1ISqngTCkgz2rjGE/gExuFNYSiHp6GcVbqCTZ/sOwtjDFszHHjHPy/iXHgGGawG+3THxK1ZtDlpEXVAemxeSlx/zlffwm2N9TYWj77tuX0v0n0z7qP8ixaKUMsV20oQ5KHiSY0DqN6t9SEOMeEfmEBFo1MzUl18iD5fX2Cf6QMWBEcK7vJ6kjV0/OomeJ3WUB+/Dv/dGgikN6BAFCRMjRVi7fQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T0fP7BCMtSTPAhLfQM77ftx/kfDm+bzSxRYB71fRK0E=; b=kf5ezh1HikGgpLSmWU0H8lvsfTEtXaQ+MgjhpS6IhReKK+TXGPQmwmCCN8J7TMrYBru+MIPtFJNI9k/3clBF1TnjMalUzezhe4IPI1L/IUraNSl4MseAhTnSl3SwuqLK/IB3HjHDtV+GFPSjAkA0Jo1+WzWURpCJApqP6JT+j4w= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB5653.eurprd07.prod.outlook.com (20.178.93.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.7; Sat, 21 Dec 2019 15:28:09 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::8514:c0f:390b:277%6]) with mapi id 15.20.2581.007; Sat, 21 Dec 2019 15:28:09 +0000 From: Francesca Palombini To: Daniel Migault , Ace Wg Thread-Topic: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile Thread-Index: AQHVnrWn369e3fEdOECJBetALv7aeqfE+dYA Date: Sat, 21 Dec 2019 15:28:09 +0000 Message-ID: <7456FFE2-F792-452A-9DA1-5DEA078CECE0@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [2.34.150.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2bd88eec-df73-4b4a-423c-08d7862a6262 x-ms-traffictypediagnostic: AM6PR07MB5653: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(396003)(136003)(199004)(189003)(81156014)(8936002)(9326002)(64756008)(66446008)(66556008)(8676002)(6486002)(2616005)(186003)(66476007)(36756003)(44832011)(2906002)(4744005)(53546011)(6506007)(316002)(966005)(76116006)(91956017)(26005)(86362001)(66946007)(110136005)(5660300002)(33656002)(71200400001)(478600001)(81166006)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5653; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wV1XYpX/2iI38PKL7c+E9aeFhkqodS1vofLflOqIhkhdh+8UFyK9Kz+XWGHfOLzUYr/GaieSqJCJbzsVyFq84Zz/T7vloWmKHgr6Zv7mAw0Pn8aR8V3rdUUfMyDRfNYfxFcCVP12fxzxREvQasHYCdycal1PB4hIsh08h0lPp9j17jd9HkwdAoZVoABBr0AP3YmTikhhOlffcUsTGdIIwcWniRUrIf42SIQPj2Rui/vF0Fa/3592rhG4VdBe5V77qDIYPz9j+wrafzDG2x1ZzMnRPXHn/OLrlbsxYqdN5o+0W6Ys4L9HDylza26jhWkfBzxhyPbp+k2a0cp4AvagiGpTzKIa8DnVg3RfmPyN0wx4GA/T+9wI0ySVFgDvxBpd9PtJdBrbDS+nA6vH0wvut6XPi7a+J67D9MDsffCyl6xAg171zm2PgzW6Zm+TStymNymxz1Ib0Itr1Vhf1lIihhqnhvtRmi1RkG7eunZa3MY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7456FFE2F792452A9DA15DEA078CECE0ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2bd88eec-df73-4b4a-423c-08d7862a6262 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2019 15:28:09.3069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Zs9Mifg0oz9Tm4PnqbhOxhcNdCLGMIvNo2oHj1N8Z+f/E8uJpj3tQbE8l0m5Lu/LD5Dw2BAAoQe6P0SzIr+nmoCeQfptqAfb1U4FyqhOFBhzZfBImLAEeMbANlUj64zt X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5653 Archived-At: Subject: Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 15:28:18 -0000 --_000_7456FFE2F792452A9DA15DEA078CECE0ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaXMgYWRvcHRpb24gY2FsbCBoYXMgZW5kZWQgYSB3aGlsZSBhZ28sIEkgYW0gd2Fp dGluZyBmb3IgYSBjb25jbHVzaW9uIGJlZm9yZSBzdWJtaXR0aW5nIHRoZSBuZXh0IHZlcnNpb24g b2YgdGhlIGRvY3VtZW50LCBhbHNvIGluIHZpZXcgb2YgbmV4dCBpbnRlcmltLg0KDQpIb3BlIHlv dSBoYXZlIGEgaGFwcHkgbmV3IHllYXIgY2VsZWJyYXRpb24sDQpGcmFuY2VzY2ENCg0KRnJvbTog QWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERhbmllbCBNaWdhdWx0IDxk YW5pZWwubWlnYXVsdD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFR1ZXNk YXksIDE5IE5vdmVtYmVyIDIwMTkgYXQgMDk6NDUNClRvOiBBY2UgV2cgPGFjZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFtBY2VdIENhbGwgZm9yIGFkb3B0aW9uIGRyYWZ0LXBhbG9tYmluaS1hY2UtY29h cC1wdWJzdWItcHJvZmlsZQ0KDQpEZWFyIHdvcmtpbmcgZ3JvdXAsDQoNCkFzIG1lbnRpb25lZCBk dXJpbmcgdGhlIEFDRSBtZWV0aW5nLCB0aGlzIG1haWwgc3RhcnRzIGEgY2FsbCBmb3IgYWRvcHRp b24gZm9yIGRyYWZ0LXBhbG9tYmluaS1hY2UtY29hcC1wdWJzdWItcHJvZmlsZS4gUGxlYXNlIHBy b3ZpZGUgeW91ciBmZWVkIGJhY2tzIGJ5IERlY2VtYmVyIDQuDQoNCg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1Yi1wcm9maWxl Lw0KDQoNCllvdXJzLA0KRGFuaWVsDQoNCg0K --_000_7456FFE2F792452A9DA15DEA078CECE0ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <75C94E444851574FAC97550E6127FFE4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlRoaXMgYWRvcHRpb24gY2FsbCBoYXMgZW5kZWQgYSB3aGlsZSBhZ28s IEkgYW0gd2FpdGluZyBmb3IgYSBjb25jbHVzaW9uIGJlZm9yZSBzdWJtaXR0aW5nIHRoZSBuZXh0 IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBhbHNvIGluIHZpZXcgb2YgbmV4dCBpbnRlcmltLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5Ib3BlIHlvdSBoYXZlIGEgaGFwcHkgbmV3IHllYXIgY2VsZWJyYXRpb24sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5GcmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5BY2UgJmx0O2FjZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYg b2YgRGFuaWVsIE1pZ2F1bHQgJmx0O2RhbmllbC5taWdhdWx0PTQwZXJpY3Nzb24uY29tQGRtYXJj LmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCAxOSBOb3ZlbWJlciAyMDE5 IGF0IDA5OjQ1PGJyPg0KPGI+VG86IDwvYj5BY2UgV2cgJmx0O2FjZUBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+W0FjZV0gQ2FsbCBmb3IgYWRvcHRpb24gZHJhZnQtcGFsb21iaW5p LWFjZS1jb2FwLXB1YnN1Yi1wcm9maWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgd29ya2luZyBn cm91cCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXMgbWVudGlvbmVkIGR1cmluZyB0aGUgQUNFIG1lZXRpbmcsIHRoaXMgbWFpbCBz dGFydHMgYSBjYWxsIGZvciBhZG9wdGlvbiBmb3IgZDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ cmFmdC1wYWxvbWJpbmktYWNlLWNvYXAtcHVic3ViLXByb2ZpbGUuIFBsZWFzZSBwcm92aWRlIHlv dXIgZmVlZCBiYWNrcyBieSBEZWNlbWJlciA0Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhbG9tYmluaS1hY2UtY29hcC1wdWJz dWItcHJvZmlsZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhbG9t YmluaS1hY2UtY29hcC1wdWJzdWItcHJvZmlsZS88L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPllvdXJzLCA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRhbmllbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7456FFE2F792452A9DA15DEA078CECE0ericssoncom_-- From nobody Sat Dec 21 11:07:46 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF2A120059 for ; Sat, 21 Dec 2019 11:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Lsz--HfI6LBZ for ; Sat, 21 Dec 2019 11:07:42 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C81A12004F for ; Sat, 21 Dec 2019 11:07:42 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 21 Dec 2019 11:07:36 -0800 From: Jim Schaad To: 'Ludwig Seitz' , 'Daniel Migault' CC: , 'Benjamin Kaduk' , 'Roman Danyliw' References: <157508633572.4770.7120325133415529789.idtracker@ietfa.amsl.com> <000901d5b201$0ff47c90$2fdd75b0$@augustcellars.com> <42f75b3b-9d85-5483-401b-d23b167dd038@gmx.de> In-Reply-To: <42f75b3b-9d85-5483-401b-d23b167dd038@gmx.de> Date: Sat, 21 Dec 2019 11:07:34 -0800 Message-ID: <008301d5b831$e91ba8f0$bb52fad0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHhbZrA39yrlgk7GZbeDpCgEddqRwIbSyNFAgMixioBz+/VpgHr1TCip2617vA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] FW: [IANA #1157486] Last Call: (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed Standard X-BeenThere: ace@ietf.org 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: Sat, 21 Dec 2019 19:07:45 -0000 Personal opinion, I think that we should be requesting a separate page. I think we are = going to have enough different registries that keeping them separate = from OAuth is going to be useful in preventing confusion. For the = mapping registries, it might be useful to see if IANA can give us a link = from the mapping registry to the OAuth registry. Jim -----Original Message----- From: Ludwig Seitz =20 Sent: Saturday, December 21, 2019 3:26 AM To: Jim Schaad ; 'Daniel Migault' = Cc: ace@ietf.org; Benjamin Kaduk ; 'Roman Danyliw' = Subject: Re: FW: [IANA #1157486] Last Call: = (Authentication and Authorization = for Constrained Environments (ACE) using the OAuth 2.0 Framework = (ACE-OAuth)) to Proposed Standard > From: Sabrina Tanamal via RT > Subject: [IANA #1157486] Last Call:=20 > (Authentication and Authorization=20 > for Constrained Environments (ACE) using the OAuth 2.0 Framework=20 > (ACE-OAuth)) to Proposed Standard > > (BEGIN IANA COMMENTS) > > IESG/Authors/WG Chairs: > > The IANA Functions Operator has completed its review of = draft-ietf-ace-oauth-authz-27. If any part of this review is inaccurate, = please let us know. > > The IANA Functions Operator has a question about one of the actions = requested in the IANA Considerations section of this document. > > The IANA Functions Operator understands that, upon approval of this = document, there are fifteen actions which we must complete. > > NOTE: We=E2=80=99re asking the ADs how to handle the registrations for = which Hannes is the only reviewer. > > IANA Question --> Several sections of the current draft propose to = create new registries (Sections 8.1, 8.3, 8.4, 8.6, 8.7, 8.9, and 8.11). = For each of these requests, IANA asks the authors where the new = registries are to be located. Should they be added to an existing = registry page? If not, do they belong in an existing category at = http://www.iana.org/protocols? For each of the new registries, it is not = clear from the context of the request where the new registries should be = established. > Hello WG chairs (WG and ADs in cc), I am in need of some guidance here due to my lack of experience in IANA = matters. Do we want to establish a new protocol page for ACE in the IANA = registries? Alternatively we could add them to the OAuth pages under a specific ACE = section. Regards, Ludwig From nobody Sat Dec 21 19:49:21 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16612008B; Sat, 21 Dec 2019 19:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OEzT4ue+; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=njb5Wxe7 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 SiEjETdSRsZV; Sat, 21 Dec 2019 19:49:12 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53BD120072; Sat, 21 Dec 2019 19:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15885; q=dns/txt; s=iport; t=1576986552; x=1578196152; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H7HLJPPTFMohAHcrO9mz46CXJGLS6sJS25n82DslCd4=; b=OEzT4ue+WGfJmU3GuSEltVAGtsaJWXPlGDwTM8Th72/baYXiEiRHpcHg /y87R9qgbaCKdNSMUeZxf2LU/gh7+8e2gSf1XmYT/RKzTf2in/SHO0+i/ IvzDxH96EA6dXsutPRnQ4l0gElgnMc+rLu/ZxVDHwJU93nL3EYw8SP8vd o=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AxZ3Gkhz26WmXhS7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCCQBM5/5d/4cNJK1cCYQPJAUnBWw?= =?us-ascii?q?rLSAECyqEB4NGA4p2gl+YCIFCgRADVAIHAQEBCQMBARgLCgIBAYRAAoIcJDg?= =?us-ascii?q?TAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQQBARARHQEBJQcLAQsEAgEIEQQBASs?= =?us-ascii?q?CAgIlCx0IAgQBCQQFCAYUgjVMgXlNAx8PAQIMoDQCgTiIYXWBMoJ+AQEFgTU?= =?us-ascii?q?BE0GDFRiCBQcDBoE2gVOKKQ4PGoFBP4ERR4JMPoJkAQEBAgGBLAEICgEJGDC?= =?us-ascii?q?CXjKCLI01CAyCcYgZhx+OLnQKgjSDYYI3gRuEdEeJRoJGh3uQFo5SiFKSBAI?= =?us-ascii?q?EAgQFAg4BAQWBaSJnWBEIcBU7gmxQGA1XjEYYFYM7hRSFP3QBgSePUYFTXwE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.69,342,1571702400"; d="p7s'?scan'208";a="395533292" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Dec 2019 03:49:10 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xBM3nAkF001033 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Dec 2019 03:49:10 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 21:49:10 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 21:49:09 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 21 Dec 2019 22:49:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A3HKfD283llBdKFxY5sbRV8hnfhS+ZyPzyZLmt/yue7m/XGXNTmxdN8pcQBxEjVYxleJnYspEEvNvtPmq/bJemVL2tF83da89qnIq1tLTJLQl698Mdc9eYMdgQFUiuR6NG+iosZRBF0nH1WjdDTPkdO63iUR8cFL7mE1qlMKM/MWlFAkZ1Lq+iMNuKAPF9x4v5CBG2CFOebgpk2PEznmpnm/FclptIm01/9wBVtVgxt6hKm9SDZVqybSWiSnKsak2llnCeQ3rkOwPUYpR+1A8bXsjgYgMTxcMNT4W1a/q8L3AjKpquuntBPAWNdHrwqY58Vs5Eiwu4KBRgg/zWbL0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pWRQhy+TzCBeGVjU8Zyw6arJ0xdO8sNZkTA6DaJg+2s=; b=l4KRWZVtiLwpmzTpokU83SW0qqyesM8W7TBzEofAJvrBkN1zhbGCXILltG4PGNlja1WOGWS0YH6SooXV27HbC58NitUu/+amuR6Tp+iKTDgFF+i5jk6mfDp+6JVQ15ROmcrgdSDNTChq/lx+4pZLnqkZjWfPJtJrTBiCE2ZU3DYWi74MWrMZAZ0h3RE2RKVFVRsHGw+X0qMwtTLFIbutWT+nkRIjGHKm/lHmdy2ndlu6vZB2aL3VZ+gfGtWolLWwMiAV5SMtzOS00rXb5Go/1CREbNEcVYiEiz2yIQmpzkmI7uwhRz6LDPp0SswQc3s2+kTPUWsHr3LjTlRfsAGAYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pWRQhy+TzCBeGVjU8Zyw6arJ0xdO8sNZkTA6DaJg+2s=; b=njb5Wxe7kHey5GUp3Jw/E2tSiJ+oDeauAvK6NO8L1MfqXq9D5nsbObY5N2uaZ9+eCUQuKqaAs/kvb6IsBoZ2VNJ7f6h++plBdg/+iYWlsGYfCeLlPrOktCignZawbGXcyN9xqTpz/1ohMfIoMZN6Ue1vqqIOvKS357IM/MullBQ= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2738.namprd11.prod.outlook.com (52.135.245.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Sun, 22 Dec 2019 03:49:08 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.017; Sun, 22 Dec 2019 03:49:08 +0000 From: "Panos Kampanakis (pkampana)" To: Barry Leiba , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Thread-Index: AQHVtIXtXsiUGCzH10qa4vZMC+mOsqfFhtmQ Date: Sun, 22 Dec 2019 03:49:08 +0000 Message-ID: References: <157655152334.24617.3401591731456466633.idtracker@ietfa.amsl.com> In-Reply-To: <157655152334.24617.3401591731456466633.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1004::3d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a34f25f5-b359-470f-f0bb-08d78691e61d x-ms-traffictypediagnostic: BN7PR11MB2738: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(376002)(39860400002)(346002)(396003)(136003)(366004)(199004)(189003)(13464003)(76116006)(5660300002)(8936002)(316002)(54906003)(66476007)(66556008)(186003)(478600001)(2906002)(9686003)(66616009)(81166006)(81156014)(52536014)(33656002)(86362001)(53546011)(6506007)(55016002)(7696005)(66946007)(4326008)(64756008)(71200400001)(110136005)(8676002)(66446008)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2738; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /Dqyew+P71rdBERG1KFK/yHCj2MXJe33fyq80tWYnVGepY/kYAKtBfGZBcX7wP9n4couGNJKYRQY/Y8COUrlowHycH8c/IA1nSjq4eHxpuv5Zh65mf/v/5gSvg+w3QGly6L4qIDfDGwT2AzZIRvD3oqSO9fLPY52crqv56dmRL5cU9CUZmxg1lB6L/9zHtlKKmJf6oih1kRqO65wPqGzRLdzz+wpqWnqfhKNcp7Mfqjuk9YmZZ1GS2v4nbGjqTfeVf5XwJ6yG6FW1z2Onxa4tYeqMtrmCkt6+cC0wvrTTpjnKDHIemu2VdffIVHodqdluLSIb2kysICrnkNCaJ185H5QWonp5i9xFvLvfoc+xASUFB76aMd/Y/quMoFtiHbE9u/ntqmzMeE1CFJsDYXVQpgC3Ft8eywa/efs1Yt2xZ9qhkJHZlLRXGztKIO8xhKaCiX1LEugJm8ozqAe86qRzfTfBMhEkM04LNgh8FmWUjRjJuenVxUt5vCA+WnCHozSrJYXaQZ9vW9xn/dHn/fdWVhFR9KtepJBfRPVRsD7VArpq5iIl9Kr1gl7tsD8+s4t/rSopUV32s0qgvBhLFyBB1E0GQ5Hnx9N+YMc7DEcNoQ= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_002A_01D5B850.D9FFC490" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a34f25f5-b359-470f-f0bb-08d78691e61d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2019 03:49:08.4086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RTldhneRcDQw87uAxMj6QfQozg7ufIocChmbvesW/DVFqrGbVxbKhqYKyPRjUmZup2Fh0UHGWAMztdhjrLYybw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2738 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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: Sun, 22 Dec 2019 03:49:15 -0000 ------=_NextPart_000_002A_01D5B850.D9FFC490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Barry, Thank you for the thorough review. We are tracking your feedback and our = responses in a git issue = https://github.com/SanKumar2015/EST-coaps/issues/153 We mostly confirm = all your minor text changes and nit fixes. The TBD one we will not fix = as we are waiting on IANA. Let us know if something does not make sense.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Barry Leiba via = Datatracker Sent: Monday, December 16, 2019 9:59 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: = (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this =E2=80=94 a useful document. I have a bunch of = comments, but they=E2=80=99re all editorial. Please consider them, but = there=E2=80=99s not a need to give a detailed reply. -- Section 4 -- In that case, the server MAY want to authenticate a client certificate against its trust store although the certificate is expired (Section 10). Total nit: Why "want to"? Why not "server MAY authenticate"? As described in Section 2.1 of [RFC5272] proof-of-identity refers to a value that can be used to prove that the private key corresponding to the certified public key is in the possession of and can be used by an end-entity or client. I find the passive voice to be quite awkward here, and suggest making it = active: NEW As described in Section 2.1 of [RFC5272], proof-of-identity refers to a value that can be used to prove that an end-entity or client is in possession of and can use the private key corresponding to the certified public key. END the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed as if each handshake message had been sent as a single fragment (Section 4.2.6 of [RFC6347]). I know this wording is directly from 6347, but I think it's unclear and = would like to suggest an alternative. The "as a single fragment" part = is odd, because I think what it's really saying is that it's computed as = if it had not been fragmented. My suggestion is to change it thus (and = similarly for the next paragraph after): NEW the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed on each reassembled message, as if each handshake message had not been fragmented (Section 4.2.6 of [RFC6347]). END If that's not correct, please take that as further evidence that it's = unclear, and adjust accordingly. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions which was not the case with [RFC7030]. For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. Two total nits: a. Comma before "which", please. b. The "for example" needs some rewording to make it work: NEW For example, if an EST csrattrs request is followed by a simpleenroll request, both can use the same authenticated DTLS connection. END -- Section 5.1 -- EST-coaps is targeted for low-resource networks with small packets. Two types of installations are possible (1) rigid ones where the address and the supported functions of the EST server(s) are known, and (2) flexible one where the EST server and it supported functions need to be discovered. This needs a colon (:) after "possible", a comma after "rigid ones", "a" = before "flexible one", another comma after "flexible one", and make it = "its supported". -- Section 5.5 -- Similarly, 2.04 is used in successfull response to EST-coaps POST requests (/sen, /sren, /skg, /skc). There's odd spacing here; please fix it. And "successful" is = misspelled. -- Section 5.7 -- If the server is very slow (i.e., minutes) in providing the response (i.e., when a manual intervention is needed), I think you mean "e.g." for both of those, evidence for my general = aversion to using Latin abbreviations that many people don't fully = understand. It also feels odd to have the two examples separated in = this way. I suggest this: NEW If the server is very slow in providing the response (for example, manual intervention is required and it could take minutes for it to respond), END it SHOULD respond with an ACK containing response code 5.03 (Service unavailable) and a Max- Age Option to indicate the time the client SHOULD wait to request the content later. Perhaps, "to indicate the time the client SHOULD wait before sending = another request to obtain the content." ? After a delay of Max-Age, the client SHOULD resend the identical CSR to the server. As long as the server responds with response code 5.03 (Service Unavailable) with a Max-Age Option, the client SHOULD keep resending the enrollment request until the server responds with the certificate or the client abandons the request for other reasons. That last sentence reads very strangely to me. It SHOULD keep resending = the request until it decides to stop? What does that actually mean? Maybe what you're really trying to say is something like this?: NEW As long as the server continues responding with response code 5.03 (Service Unavailable) with a Max-Age Option, the client will continue to delay for Max-Age and then resend the enrollment request until the server responds with the certificate or the client abandons the request for policy or other reasons. END -- Section 5.8 -- In scenarios where it is desirable that the server generates the private key, server-side key generation is available. This seems like a content-free sentence. Maybe this?: NEW Private keys can be generated on the server. Scenarios where that makes sense include those where it is considered more secure... END Of course, that does not eliminate the need for proper random numbers in various protocols like (D)TLS (Section 10.1). May I suggest this?: NEW As always, it is necessary to use proper random numbers in various protocols such as (D)TLS (Section 10.1). END server or proxy to generate the private key and the certificate which are transferred back to the client Needs a comma before "which". or the asymmetric keypair establishment method is out of scope of the specification. "of this specification". [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.3) . The two representations More odd spacing. Dependent on the request, the private key can be in unprotected PKCS#8 [RFC5958] format "Depending upon the request" In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client-defined (in the CSR) asymmetric public key and is carried in an encryptedKey attribute in a KeyTransRecipientInfo structure. Long sentence that needs punctuation: comma after "operations", comma = before "which", comma before "and". Also, I would move "(in the CSR)" a = few words later, after "public key". -- Section 7 -- It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). Odd spacing, again. But "it is recommended to follow" is also odd = English. I suggest making this active, rather than passive, thus: NEW Implementations should follow the default CoAP configuration parameters ([RFC7252]). END I don't think the "based on experiments" bit adds anything, but if you = want to keep it you can prepend "Experiments have shown that" to my = suggestion. -- Section 9.1 -- Don't you want to remove the "TBD" on "TBD287" here? Wasn't the "TBD" = just a flag to remind people that it hadn't been formally allocated yet? =E2=80=94 Section 10.1 =E2=80=94 It is important to note that sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs are not available on many constrained devices, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, as pointed out in [PsQs]. The sentence order is wrong here. For example, mouse movement is not a = constrained device. The correct order is more like this: NEW It is important to note that, as pointed out in [PsQs], sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, are not available on many constrained devices. END _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_002A_01D5B850.D9FFC490 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjIyMDM0OTA3WjAvBgkqhkiG9w0BCQQxIgQgoowIOuDq7+8AihAvvvcZVVtzSpYdodaE DS83JjMG8wowSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA KSxARFDcVmEvNKlVRzFu283U65V2U8KtI2vGFgaNz9otQI/ZB/lmYPQE2H5lrUHC1DgcjVKmp3H8 1VFaxVugjIkLNb6fqvPEifbWd7qw1qGxtLBndGvggQvOy303lIkQ8Zj7YXNSot6HLvTY2oVygvyR 2ti6R78FKJADAbo50N2xVMIgv813IAq+ybLfze1dQaPCVPpe8e2+qVtgIYVlK/3wOENj1AeKJNaZ pF0EO2VxT5LltAwgNAR0xlQoh7NebRKviTt7lSdzdVpHXehvv+UP+hVTgZzGpPqwZbkQ2qrXhioF hCpy1wz1aHo9etGp15U8t+GsKIcGMsoxWX1H5AAAAAAAAA== ------=_NextPart_000_002A_01D5B850.D9FFC490-- From nobody Sat Dec 21 20:37:36 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A571D120098; Sat, 21 Dec 2019 20:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JLz8EeNk; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Pjeb6pV6 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 Ylm_sKobAhUG; Sat, 21 Dec 2019 20:37:32 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3586C120090; Sat, 21 Dec 2019 20:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8749; q=dns/txt; s=iport; t=1576989452; x=1578199052; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dbpUS45E+VPl+wVkzhZ3i4pMa5BEQ92DRAtV742Z0DA=; b=JLz8EeNkobK+1kH6yhJneeIaYiB6M9sUG4LW1g/CF2AlX8J+QKkJB/yK ZX14xLGauieyxq4DcKbmxaoGU1zOrhPo1fjT/5lTswmFyKpTR8Xfu2P8R la4JWs9XJxvElMWKD+gD9z3x4EnUZNjC6yu4mABGGBUYF/EG2m9zk/Uqk c=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3Aku1UWBJdWFYvjd9D5tmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+CQAf8v5d/5RdJa1lHgELHINJUAV?= =?us-ascii?q?sKy0gBAsqhAeDRgOKdoJfmAiBQoEQA1QCBwEBAQkDAQEYCwoCAQGEQAKCHCQ?= =?us-ascii?q?4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEDAQEBEBEdAQEsCwEEBwQCAQgRBAE?= =?us-ascii?q?BHg0CAgIlCx0IAgQBDQUIBhSDAYF5TQMOEQ8BAgygMwKBOIhhdYEygn4BAQW?= =?us-ascii?q?BNQETQYMRGIIFBwMGgTaBU4pGGoFBP4ERR4JMPoJkAQEBAgGBLAESASEwgl4?= =?us-ascii?q?ygiyNSYJxnloKgjSDYYI3gRuPAYJGh3uQFo5SgUaHDJIEAgQCBAUCDgEBBYF?= =?us-ascii?q?pImdYEQhwFTuCbFAYDY0SOIM7hRSFP3QBgSePUYIyAQE?= X-IronPort-AV: E=Sophos;i="5.69,342,1571702400"; d="p7s'?scan'208";a="387969821" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Dec 2019 04:37:31 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xBM4bUXE032581 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Dec 2019 04:37:31 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 22:37:29 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 23:37:29 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 21 Dec 2019 22:37:29 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ge6FOJbIOMQL+SGVWv5EqjxFqiGV56mcQo05wpQ0ZTbChUPBS0wEZwR+CE1aNsffEH72GEDk5kXFGTKlxkifLkEz4qrT2jhLEYZgxy9R0nbJGNMZaKNXabRhCvO3g2DvLrwYI4J64+NPnnCHqAgL9060qqHRCxoMB/kV/L++sxQIhYH3jARcC+iP5Cj8t0PdujKT/jb9T61s7GFE7+A6vZ5OPBsRPhlOg92hmx0gGm1/iM4gMkeW5Ny5R2AH0rjDqDxHdhDbAGtXPPPUyhY3lay7tYHGnKPrfXK45+5z2rOoxLYglnNIBn96EI9YzCH7gRMLUXuI/D4DMFdqDQBj/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O32qzpiwe/yZvWONlEuWQ/BhotMtZYYxQAzp1TN5YNQ=; b=oPL3sfe7fCYak2PG3FZUoeNAnpPRK/4taafq63RbJxjVUC61rGYm8kywaK23wWTo/9/H6Sg0uUBIx/4ebACKOzojCvQqPCnHbM9D7EAffb4ijbDRKM9Pb1Iu1/z7+LCtmGh9zEPrFvyPi4Cmqe5v+koFrTTyvf9Ai67uP7KY61uE99qjeo1zL+8I1bDvWY/vFlEacpZaEwqHRbQ2Hjk5bwDnKuYuUWysgES1jQM6qjtJuJorH5GDOLg53CwOOi0KR0OAMIBcAqjtzaGn/JrpWiQaZfHjIuvJN1J+C4jtaFEkT+ZrVaUX10ZMQeOUEwOBcMLI4dF2RACrgZDEngckEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O32qzpiwe/yZvWONlEuWQ/BhotMtZYYxQAzp1TN5YNQ=; b=Pjeb6pV6YFp9W6iSogn6zxA6UDE1pZJPSXvIoWzA/u9BLogMhhbVQhzBsDcolbERbGd5HGTkNtYKVr/X2ElnpN565LsDkeDIuEJV/bFPRttwYCpMyVsav92xNYxdHStOuQmrRmF6rM+d5haJVBXvuVsOuUFVYp6BafF8CnB+cNM= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2802.namprd11.prod.outlook.com (52.135.247.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.15; Sun, 22 Dec 2019 04:37:28 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.017; Sun, 22 Dec 2019 04:37:28 +0000 From: "Panos Kampanakis (pkampana)" To: Adam Roach , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Thread-Index: AQHVtUrvBuuwn1+t5EO6fSPw+/uqFKfFlcug Date: Sun, 22 Dec 2019 04:37:27 +0000 Message-ID: References: <157663612332.4994.1427589526663831052.idtracker@ietfa.amsl.com> In-Reply-To: <157663612332.4994.1427589526663831052.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1004::3d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98e1a1c0-6b04-4026-6cc2-08d78698a656 x-ms-traffictypediagnostic: BN7PR11MB2802: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(366004)(396003)(136003)(39860400002)(346002)(376002)(199004)(189003)(13464003)(51914003)(478600001)(4326008)(2906002)(966005)(55016002)(9686003)(7696005)(66446008)(66556008)(64756008)(66476007)(66616009)(76116006)(66946007)(8936002)(6506007)(54906003)(110136005)(52536014)(53546011)(8676002)(33656002)(81166006)(81156014)(86362001)(71200400001)(316002)(186003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2802; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CJcyRaVFosKy1F2YhhF6Xf5JfQkORrZelN3n7+vqshuiC28Sg6EvgxgUKEI6yJSHm9Qand1WNfoinxd/E8vC55XwPjyvzRCLFVhgk8etm4LNWz8m1flH2lV6jiLJk+VoxJnCtCI4r8Imc5BdDxym5WYueyI8ZHd3QzDxilR/0wEnvCbVf2uD59e7DzEz74oVy5y9j3AYmWaQq8krQJgUR3A8bV+7bkBkpKGdk+7HrSo2qvcdYQP7n60GnUNcBdWI6VOUgeQIpF4D7VQBQ//IRWE2inZDrGMR3+cxMy9OX+D+kAJrTcF3sD18MJivEMXbYr3FFG4UHu2xLIXjSpJjtNYali/SAwMVwWY1gdtlOe0KZ3VoMFj8aLn8uJEe+5Hx9Mg8BhcxJTFNY/iZiG08hnVi8+YxsM4fChITB8GI7Xmy7i2qcUpH9QdHV0QBwKoqgODzRN8AaWIwItaM/3gzXHtNqSLQD03GHPyU590lQUghzpvtYng2fgA6uO9bhi4qT8U9FiEOpSLxqt0GxbyEp2Z/Ev1nQilg5OgDlNt3gfGVKG/DewUJ+G4eOlcKCei0dkGiqcNR77YYbkHG7HKs9SFNn3tHW8TXniH4mcJRAfY7XT22TBZl8yCJtG2P7dp4 x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0032_01D5B857.9A4E35A0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 98e1a1c0-6b04-4026-6cc2-08d78698a656 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2019 04:37:27.9107 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: J1cqxsfR2zp8+vC1Uk2TJVJrfQ6jIY0W+twaBEk8sKltrFFTDyMj8s8p8maF1pJupC5Qs1c27nZkMnbZk3NcDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2802 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Sun, 22 Dec 2019 04:37:35 -0000 ------=_NextPart_000_0032_01D5B857.9A4E35A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Adam, Thank you for the feedback. For completeness, we are tracking it in a = git issue https://github.com/SanKumar2015/EST-coaps/issues/156=20 Good point about updating the Well-Known URIs to include [This RFC] = additionally to RFC7030. We will make sure we add this in the IANA = considerations. We will also address the other three nits as well.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Adam Roach via Datatracker Sent: Tuesday, December 17, 2019 9:29 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with = DISCUSS and COMMENT) Adam Roach has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work that the authors and working group put into this = document. I have one DISCUSS-level comment that should be very easy to resolve, = and a small number of editorial nits. -------------------------------------------------------------------------= -- =C2=A79: Since this specification is adding new endpoints under /.well-known/est, = it needs to update the "Well-Known URIs" registry so that the entry for = "est" indicates this document (in addition to RFC 7030). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =C2=A75.3: > The Content-Format (HTTP Media-Type equivalent) of the CoAP message HTTP doesn't have a "Media-Type" field. Presumably this intends to say = "Content-Type"? -------------------------------------------------------------------------= -- =C2=A75.3: > Media-Types specified in the HTTP Content-Type header (Section 3.2.2 Nit "...header field..." -------------------------------------------------------------------------= -- =C2=A75.5: > HTTP response code 202 with a Retry-After header in [RFC7030] has no Nit "...header field..." _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0032_01D5B857.9A4E35A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjIyMDQzNzI2WjAvBgkqhkiG9w0BCQQxIgQgKe2vnkj9xI65IDNITBynSl3//b0RSAG6 dHNel1ThVAwwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA CbLiY3x22Z1p/QkGByQLpNjsZKXgIzi922VDhypNtXTrdmDwpqVlSNc0qCEvGRKmj4XjA2redIJ7 V4kHL7Wd+0UEUTLkwK3sT+/ZSMRKzZDtjbpOATWnszHb0fx4o8iTHtavbU3mSPS5FeVQsNIEZUYr TIHjOrGSAFxCKVxnwRtFDkmXjAi79tpm1Zt4xBDdIINtL3HyHSWv6iEULtqf8u1ckuwFcjnygikE z1TejxBmZrMsRk3zYGhOy/Cqm0+fmYu8HG2v046NWPoDix1XUlmFcieIVNIVH4IJrnWM6m1y/YNL XJVfraDtb+b7pHXpx3vKgdJ1inSlsHPvUnbEfgAAAAAAAA== ------=_NextPart_000_0032_01D5B857.9A4E35A0-- From nobody Sun Dec 22 04:26:30 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ED212010C; Sun, 22 Dec 2019 04:26:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.114.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157701758837.3862.1156493910273885866@ietfa.amsl.com> Date: Sun, 22 Dec 2019 04:26:28 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2019 12:26:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-09.txt Pages : 13 Date : 2019-12-22 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client wishes to use, the proof-of-possession key that the Authorization Server has selected, and the key the Resource Server should use to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-09 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 22 04:36:15 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B1120114; Sun, 22 Dec 2019 04:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 6d17V6udLax4; Sun, 22 Dec 2019 04:36:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 57D5312010C; Sun, 22 Dec 2019 04:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1577018164; bh=NKargB5YzOhAVk+w29BZVH+JFhbw1SR8fECECdQIaR8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=EhvKKBbtWkNsqocN/Gv1643KME5Io1OwAsZhQRd9J3kh70P02xWSWf9urO37/kSZc //c8ll20tpDaizjOr/OoO9y0vjmj9r3jF0WC0jLWLPKwtdmZBTQK9njEZBILkW7Ud+ q8qhjEcvcNnkgc5LlL2pZD9iLx9PuhA11GGvyi2A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N2V0B-1hfKY71p4p-013tDd; Sun, 22 Dec 2019 13:36:04 +0100 To: Elwyn Davies , gen-art@ietf.org Cc: last-call@ietf.org, draft-ietf-ace-oauth-params.all@ietf.org, ace@ietf.org References: <157636356557.14894.14267145373083139598@ietfa.amsl.com> From: Ludwig Seitz Message-ID: <60524620-542b-293d-d954-7c7ecb45bde1@gmx.de> Date: Sun, 22 Dec 2019 13:35:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157636356557.14894.14267145373083139598@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:bZcUBJmY7vljvff1FNjJuNxDgGNnSc12ju8JukVANPU214HF9HF Hq6avnQ5abXxFtwTz/Ja8sMeW+S3K7UxnvqO23Hstq3HTZ86RpzITvd2X+F1pbeqAclxzki q5O6pFt2aR19U7W83IDqaaSHmsJi2PyxWv2W2T/L+DO44fM6ZyFvi8r3UPC855WWG6zqMkI RiFWkUKa84UbzIAM/EVmw== X-UI-Out-Filterresults: notjunk:1;V03:K0:wIzPWt7Z0r4=:2Ivk5kglV+pP35DCRZosv9 8TJM1PGp1Bumj5P6dDmxcCcJy96/64mpvIB1tcPx5vUfnNiJGsXQYBeqWfoW/RboYQFg+WNeS XibrV3KoosnFcqvT+SfdBpj3lDkFXC7GQSUmlB9/k+GcL83XyJ7W3zjJ0CgGZuVG1nwDQfPvV 6xH9zvGkRfdwoi6/TOH946ztcSf5tDtW1RMiZI8OEALBqcTPpF9q8gM/HfhJEgPP/7o7pkUZD /a1yDkwkqcih7orhxgPMV3XuqMMIl3XD64/2MnTZs/aVQ6qFdvbNJzceCYwP3IYwNRiEOcOFC 3Hw9w/Tt49FMjuCwgQNoOGxk+t5D7phiTvLNZ/xOrp7NXK2KhaZR27kb/ei/tHQJRD1mn1lfK mSHLq34tfMzsa5FiOYtj4CM+xs1JFtMwLXTogPWKADSE6JEkwf0+AAVZNdnQw6XgEp/x3a0Jk ALfjf7z0ouXRZ7zPFs5zARWaByvFtO8hPKx9CB9fXQW8+rCGmdFLkDhLMY24UChxSQWVODNzx xdeN7tyPKiep2C13t/2ZIOXUS2wB6l21jxXzdQ8dP+Zb+P0ELqhw1w0oxkLWttcYkfE5V2QMN LGG4ELaDHhGkzYPIZ78tMhfYZRDR/nXq6Iqg7ZBTes6a+rdHKaeAFV954nwLRfC8PIGAftq0c u8FT6ye79udeN5cZ6WHam0cewbkVbHe8F+xrZ8PdtSaRaYjlNAdNIg9KV7zB3nLM6SuVNz5RI fpU8ZxjyBMmrrl2u+0nBWIno7R2D0PnMLtlJQKg2EAwdwy5bmyIwnmJ60KHs03gbUrPiwNUw0 jtvlh7yvYwZD6S3x+LXgx5bTX2EJ6Aox9+r0pgHr5zvzktWUl/gocA3LrIjiigdgPxJCCbd8I 91tm5zIoigm3+a42B8ieMlDZPW4rUazKpWcKWNBt4WmYtCGWsIDHCX3Kyc2hDz5RhKtwr3UIZ m+4zOEqCPuakb1zNzAff5PcsG0fjhl7NIZv84EBJv0BPJXJdHqYb0NmztJiF6DifMKsrded61 9Y/P6DHl8nQdDuEfZWyKNjx4pfWliRbDN0XN42GWm4CI8YtpybvbE2eMJQ5k/ceU15JtjdQ3D GrgFIGArXrsfL7FwZfqm7F8ukCdAw2CIYD6r6SvkERKROzhk5ATV28UEdw4yOuFENxMVUkm8V H/v8SzGKiR/uxJ6JCxOGC5mMUqocF5xbOAi2UeBuZIy7SvZ37qzkxQM13G5cFoE0XovIDgB+7 H7cslnONHtmZUxqfAeeMbKmOI9e3+YVS3OunSL1rm+A4npk83dkBEFtW5TXo= Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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: Sun, 22 Dec 2019 12:36:14 -0000 Hello Elwyn, I have now submitted -09 to fix the minor issues and nits, which I forgot in my -08. Comments inline. Regards, Ludwig On 2019-12-14 23:46, Elwyn Davies via Datatracker wrote: > Minor issues: > ss3.1, 3.2 and 4.1:=C2=A0 The COSE_Key type 'EC' used in several kty fie= lds is not > defined.=C2=A0 I assume it should be 'EC2'. > Fixed > ss3.1, 3.2 and 4.1:=C2=A0 Does it matter that the definitions of the x a= nd y > parameters in an EC2 key are given as 'h' encodings in RFC8152 but are g= iven as > 'b64' in this document?=C2=A0 I am very much not an expert here. > All changed to 'h' encoding > s6: This section starts with 'If CBOR is used...': The main ACE draft > draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and= CBOR > encodings of payloads, although CBOR is recommended.=C2=A0 This is not m= ade explicit > in this addition to that specification and the use of CBOR diagnostic > representation and the prominence of COSE_Key items could make it appear= up > until s6 that this specification is intended just for CBOR encoding.=C2= =A0 A few > words at the beginning would clarify the dual alternatives. > Added a paragraph in the introduction to clarify this. > Nits/editorial comments: > General: s/e.g./e.g.,/ (3 places) > Fixed > Abstract, 2nd sentence: s/whishes/wishes/ > Fixed > Abstract: Need to expand AS and RS. > > s2:=C2=A0 RS, AS and (probably) various other terms are defined in RFC 6= 749 and need > to be expanded on=C2=A0 first use.=C2=A0 Adding something like the para = from > draft-ietf-ace-oauth-authz would solve this (except for the abstract). > I added a sentence in the terminology section to clarify this. However note that it already said (in -06): Readers are assumed to be familiar with the terminology from [I-D.ietf-ace-oauth-authz]. Which included the terms AS and RS. > > s3:=C2=A0 This section needs a reference to RFC 8152 for the specificati= on of the > CWT COSE_Key item that is used extensively. Done > > s3/s4: Some introductory text for each section is desirable. > Done > s3.1, para 2 (definition of req_cnf):: Possibly add a note that the > recommendation against symmetric keys implies currently kty being 'Symme= tric'. > Will it ever be anything else? > Done > s3.1:=C2=A0 The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-0= 3 contans > the following > > The COSE_Key MUST contain the required key members for a COSE_Key of= that > key type and MAY contain other COSE_Key members, including the "kid"= (Key > ID) member. > > 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 exp= lained > in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be > encrypted as described in Section 3.3. > > These riders probably apply to all the subsectons of s3 and to s4.1 and = could > be included in the currently empty main section text. > Here I disagree. The text explicitly refers to draft-ietf-ace-cwt-proof-of-possession, saying that the contents of the 'cnf', 'req_cnf' and 'rs_cnf' parameters use the syntax of the 'cnf' claim from section 3.1 of draft-ietf-ace-cwt-proof-of-possession. The requirements in section 3.2 draft-ietf-ace-cwt-proof-of-possession follow from the use of the definitions in 3.1. I don't see the value of reiterating such a long text from that document here, when an explicit reference is already given. > s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also al= l other > uses do not hyphenate and RPK needs to be expanded. > s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/ Done From nobody Sun Dec 22 10:39:16 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED09120026; Sun, 22 Dec 2019 10:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 iXj7CRKEJY7i; Sun, 22 Dec 2019 10:39:08 -0800 (PST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4180120019; Sun, 22 Dec 2019 10:39:07 -0800 (PST) Received: from 9.5.8.9.a.5.e.c.2.c.2.d.8.4.5.c.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:c548:d2c2:ce5a:9859]) by b-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ij5wt-0004Yd-1F; Sun, 22 Dec 2019 18:27:27 +0000 SavedFromEmail: elwynd@folly.org.uk Date: Sun, 22 Dec 2019 18:27:22 +0000 In-Reply-To: <60524620-542b-293d-d954-7c7ecb45bde1@gmx.de> Importance: normal From: elwynd To: Ludwig Seitz , Elwyn Davies , gen-art@ietf.org Cc: last-call@ietf.org, draft-ietf-ace-oauth-params.all@ietf.org, ace@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_4645990373229240" Message-ID: Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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: Sun, 22 Dec 2019 18:39:11 -0000 ----_com.samsung.android.email_4645990373229240 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIEx1ZHdpZy5IYXZpbmcgaGFkIGFub3RoZXIgbG9vayBhdCBzZWN0aW9uIDMuMSBvZiBkcmFm dC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbiwgdGVjaG5pY2FsbHkgdGhlIHJ1bGVz IGFib3V0IHdoaWNoIGtleXMgaGF2ZSB0byBiZSBwcmVzZW50IGFyZSBub3QgcGFydCBvZiB0aGUg c3ludGF4IG9mIHRoZSBjbmYgY2xhaW0uwqAgVGhlIHBvaW50IGNhbiBiZSBjb3ZlcmVkIGJ5IGNo YW5naW5nICcic3ludGF4IG9mIHRoZSAnY25mJyBjbGFpbSJ0byAic3ludGF4IGFuZCBzZW1hbnRp Y3Mgb2YgdGhlICdjbmYnIGNsYWltImluIGVhY2ggY2FzZS5Ib3dldmVyLCB0aGUgc2Vjb25kIGxv b2sgdGhyZXcgdXAgYW5vdGhlciBwb2ludDrCoCBGaWd1cmUgMiBpbiBzMy4yIGdpdmVzIGEgU3lt ZXRyaWMga2V5IGV4YW1wbGXCoCAtIEkgdGhpbmsgdGhpcyBzaG91bGQgdXNlIGFuIEVuY3J5cHRl ZF9DT1NFX0tleSAob3IgRW5jcnlwdGVkX0NPU0VfS2V5MCkgYXMgZGVzY3JpYmVkIGluIHNlY3Rp b24gMy4zIG9mIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLk90aGVyd2lz ZSBJIHRoaW5rIHdlIGFyZSBkb25lLkV2ZW50dWFsbHkgd2Ugd2lsbCBnZXQgdG8gQ2hyaXN0bWFz IcKgwqBDaGVlcnMsRWx3eW5TZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuCi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBMdWR3aWcgU2VpdHogPGx1ZHdpZ19zZWl0ekBnbXgu ZGU+IERhdGU6IDIyLzEyLzIwMTkgIDEyOjM2ICAoR01UKzAwOjAwKSBUbzogRWx3eW4gRGF2aWVz IDxlbHd5bmRAZGlhbC5waXBleC5jb20+LCBnZW4tYXJ0QGlldGYub3JnIENjOiBsYXN0LWNhbGxA aWV0Zi5vcmcsIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy5hbGxAaWV0Zi5vcmcsIGFjZUBp ZXRmLm9yZyBTdWJqZWN0OiBSZTogW0dlbi1hcnRdIFtBY2VdIEdlbmFydCBsYXN0IGNhbGwgcmV2 aWV3IG9mCsKgIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wNiBIZWxsbyBFbHd5bixJIGhh dmUgbm93IHN1Ym1pdHRlZCAtMDkgdG8gZml4IHRoZSBtaW5vciBpc3N1ZXMgYW5kIG5pdHMsIHdo aWNoIElmb3Jnb3QgaW4gbXkgLTA4LkNvbW1lbnRzIGlubGluZS5SZWdhcmRzLEx1ZHdpZ09uIDIw MTktMTItMTQgMjM6NDYsIEVsd3luIERhdmllcyB2aWEgRGF0YXRyYWNrZXIgd3JvdGU6PGRlbGV0 ZWQ+PiBzMy4xOsKgIFRoZSB0ZXh0IGluIHMzLjIgb2YgZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29m LW9mLXBvc3Nlc3Npb24tMDMgY29udGFucz4gdGhlIGZvbGxvd2luZz4+wqDCoMKgwqAgVGhlIENP U0VfS2V5IE1VU1QgY29udGFpbiB0aGUgcmVxdWlyZWQga2V5IG1lbWJlcnMgZm9yIGEgQ09TRV9L ZXkgb2YgdGhhdD7CoMKgwqDCoCBrZXkgdHlwZSBhbmQgTUFZIGNvbnRhaW4gb3RoZXIgQ09TRV9L ZXkgbWVtYmVycywgaW5jbHVkaW5nIHRoZSAia2lkIiAoS2V5PsKgwqDCoMKgIElEKSBtZW1iZXIu Pj7CoMKgwqDCoCBUaGUgIkNPU0VfS2V5IiBtZW1iZXIgTUFZIGFsc28gYmUgdXNlZCBmb3IgYSBD T1NFX0tleSByZXByZXNlbnRpbmcgYT7CoMKgwqDCoCBzeW1tZXRyaWMga2V5LCBwcm92aWRlZCB0 aGF0IHRoZSBDV1QgaXMgZW5jcnlwdGVkIHNvIHRoYXQgdGhlIGtleSBpcyBub3Q+wqDCoMKgwqAg cmV2ZWFsZWQgdG8gdW5pbnRlbmRlZCBwYXJ0aWVzLiBUaGUgbWVhbnMgb2YgZW5jcnlwdGluZyBh IENXVCBpcyBleHBsYWluZWQ+wqDCoMKgwqAgaW4gW1JGQzgzOTJdLiBJZiB0aGUgQ1dUIGlzIG5v dCBlbmNyeXB0ZWQsIHRoZSBzeW1tZXRyaWMga2V5IE1VU1QgYmU+wqDCoMKgwqAgZW5jcnlwdGVk IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4+PiBUaGVzZSByaWRlcnMgcHJvYmFibHkgYXBw bHkgdG8gYWxsIHRoZSBzdWJzZWN0b25zIG9mIHMzIGFuZCB0byBzNC4xIGFuZCBjb3VsZD4gYmUg aW5jbHVkZWQgaW4gdGhlIGN1cnJlbnRseSBlbXB0eSBtYWluIHNlY3Rpb24gdGV4dC4+SGVyZSBJ IGRpc2FncmVlLiBUaGUgdGV4dCBleHBsaWNpdGx5IHJlZmVycyB0b2RyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLCBzYXlpbmcgdGhhdCB0aGUgY29udGVudHMgb2YgdGhlJ2Nu ZicsICdyZXFfY25mJyBhbmQgJ3JzX2NuZicgcGFyYW1ldGVycyB1c2UgdGhlIHN5bnRheCBvZiB0 aGUgJ2NuZidjbGFpbSBmcm9tIHNlY3Rpb24gMy4xIG9mIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9v Zi1vZi1wb3NzZXNzaW9uLlRoZSByZXF1aXJlbWVudHMgaW4gc2VjdGlvbiAzLjIgZHJhZnQtaWV0 Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb25mb2xsb3cgZnJvbSB0aGUgdXNlIG9mIHRoZSBk ZWZpbml0aW9ucyBpbiAzLjEuSSBkb24ndCBzZWUgdGhlIHZhbHVlIG9mIHJlaXRlcmF0aW5nIHN1 Y2ggYSBsb25nIHRleHQgZnJvbSB0aGF0IGRvY3VtZW50aGVyZSwgd2hlbiBhbiBleHBsaWNpdCBy ZWZlcmVuY2UgaXMgYWxyZWFkeSBnaXZlbi5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX0dlbi1hcnQgbWFpbGluZyBsaXN0R2VuLWFydEBpZXRmLm9yZ2h0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFydA== ----_com.samsung.android.email_4645990373229240 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj5IaSwgTHVkd2lnLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9 ImF1dG8iPkhhdmluZyBoYWQgYW5vdGhlciBsb29rIGF0IHNlY3Rpb24gMy4xIG9mIGRyYWZ0LWll dGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLCB0ZWNobmljYWxseSB0aGUgcnVsZXMgYWJv dXQgd2hpY2gga2V5cyBoYXZlIHRvIGJlIHByZXNlbnQgYXJlIG5vdCBwYXJ0IG9mIHRoZSBzeW50 YXggb2YgdGhlIGNuZiBjbGFpbS4mbmJzcDsgVGhlIHBvaW50IGNhbiBiZSBjb3ZlcmVkIGJ5IGNo YW5naW5nICcic3ludGF4IG9mIHRoZSAnY25mJyBjbGFpbSI8L2Rpdj48ZGl2IGRpcj0iYXV0byI+ dG8gInN5bnRheCBhbmQgc2VtYW50aWNzIG9mIHRoZSAnY25mJyBjbGFpbSI8L2Rpdj48ZGl2IGRp cj0iYXV0byI+aW4gZWFjaCBjYXNlLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRp diBkaXI9ImF1dG8iPkhvd2V2ZXIsIHRoZSBzZWNvbmQgbG9vayB0aHJldyB1cCBhbm90aGVyIHBv aW50OiZuYnNwOyBGaWd1cmUgMiBpbiBzMy4yIGdpdmVzIGEgU3ltZXRyaWMga2V5IGV4YW1wbGUm bmJzcDsgLSBJIHRoaW5rIHRoaXMgc2hvdWxkIHVzZSBhbiBFbmNyeXB0ZWRfQ09TRV9LZXkgKG9y IEVuY3J5cHRlZF9DT1NFX0tleTApIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMyBvZiBkcmFm dC1pZXRmLWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbi48L2Rpdj48ZGl2IGRpcj0iYXV0byI+ PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5PdGhlcndpc2UgSSB0aGluayB3ZSBhcmUgZG9uZS48 L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5FdmVudHVhbGx5 IHdlIHdpbGwgZ2V0IHRvIENocmlzdG1hcyEmbmJzcDsmbmJzcDs8L2Rpdj48ZGl2IGRpcj0iYXV0 byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5DaGVlcnMsPC9kaXY+PGRpdiBkaXI9ImF1dG8i PkVsd3luPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9z aWduYXR1cmUiIGRpcj0iYXV0byI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1 NzU3IiBkaXI9ImF1dG8iPlNlbnQgZnJvbSBTYW1zdW5nIHRhYmxldC48L2Rpdj48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZToxMDAlO2NvbG9yOiMwMDAwMDAiIGRpcj0iYXV0byI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+ PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBM dWR3aWcgU2VpdHogJmx0O2x1ZHdpZ19zZWl0ekBnbXguZGUmZ3Q7IDwvZGl2PjxkaXY+RGF0ZTog MjIvMTIvMjAxOSAgMTI6MzYgIChHTVQrMDA6MDApIDwvZGl2PjxkaXY+VG86IEVsd3luIERhdmll cyAmbHQ7ZWx3eW5kQGRpYWwucGlwZXguY29tJmd0OywgZ2VuLWFydEBpZXRmLm9yZyA8L2Rpdj48 ZGl2PkNjOiBsYXN0LWNhbGxAaWV0Zi5vcmcsIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy5h bGxAaWV0Zi5vcmcsIGFjZUBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbR2VuLWFy dF0gW0FjZV0gR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YKJm5ic3A7IGRyYWZ0LWlldGYtYWNl LW9hdXRoLXBhcmFtcy0wNiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5IZWxsbyBFbHd5biw8 YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj5JIGhhdmUgbm93IHN1Ym1pdHRlZCAtMDkgdG8g Zml4IHRoZSBtaW5vciBpc3N1ZXMgYW5kIG5pdHMsIHdoaWNoIEk8YnIgZGlyPSJhdXRvIj5mb3Jn b3QgaW4gbXkgLTA4LjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPkNvbW1lbnRzIGlubGlu ZS48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj5SZWdhcmRzLDxi ciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPkx1ZHdpZzxiciBkaXI9ImF1dG8iPjxiciBkaXI9 ImF1dG8iPjxiciBkaXI9ImF1dG8iPk9uIDIwMTktMTItMTQgMjM6NDYsIEVsd3luIERhdmllcyB2 aWEgRGF0YXRyYWNrZXIgd3JvdGU6PGJyIGRpcj0iYXV0byI+Jmx0O2RlbGV0ZWQmZ3Q7PGJyIGRp cj0iYXV0byI+PGJyIGRpcj0iYXV0byI+Jmd0OyBzMy4xOiZuYnNwOyBUaGUgdGV4dCBpbiBzMy4y IG9mIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLTAzIGNvbnRhbnM8YnIg ZGlyPSJhdXRvIj4mZ3Q7IHRoZSBmb2xsb3dpbmc8YnIgZGlyPSJhdXRvIj4mZ3Q7PGJyIGRpcj0i YXV0byI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgQ09TRV9LZXkgTVVTVCBjb250 YWluIHRoZSByZXF1aXJlZCBrZXkgbWVtYmVycyBmb3IgYSBDT1NFX0tleSBvZiB0aGF0PGJyIGRp cj0iYXV0byI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgdHlwZSBhbmQgTUFZIGNv bnRhaW4gb3RoZXIgQ09TRV9LZXkgbWVtYmVycywgaW5jbHVkaW5nIHRoZSAia2lkIiAoS2V5PGJy IGRpcj0iYXV0byI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJRCkgbWVtYmVyLjxiciBk aXI9ImF1dG8iPiZndDs8YnIgZGlyPSJhdXRvIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZSAiQ09TRV9LZXkiIG1lbWJlciBNQVkgYWxzbyBiZSB1c2VkIGZvciBhIENPU0VfS2V5IHJl cHJlc2VudGluZyBhPGJyIGRpcj0iYXV0byI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz eW1tZXRyaWMga2V5LCBwcm92aWRlZCB0aGF0IHRoZSBDV1QgaXMgZW5jcnlwdGVkIHNvIHRoYXQg dGhlIGtleSBpcyBub3Q8YnIgZGlyPSJhdXRvIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJldmVhbGVkIHRvIHVuaW50ZW5kZWQgcGFydGllcy4gVGhlIG1lYW5zIG9mIGVuY3J5cHRpbmcg YSBDV1QgaXMgZXhwbGFpbmVkPGJyIGRpcj0iYXV0byI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBpbiBbUkZDODM5Ml0uIElmIHRoZSBDV1QgaXMgbm90IGVuY3J5cHRlZCwgdGhlIHN5bW1l dHJpYyBrZXkgTVVTVCBiZTxiciBkaXI9ImF1dG8iPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZW5jcnlwdGVkIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy48YnIgZGlyPSJhdXRvIj4m Z3Q7PGJyIGRpcj0iYXV0byI+Jmd0OyBUaGVzZSByaWRlcnMgcHJvYmFibHkgYXBwbHkgdG8gYWxs IHRoZSBzdWJzZWN0b25zIG9mIHMzIGFuZCB0byBzNC4xIGFuZCBjb3VsZDxiciBkaXI9ImF1dG8i PiZndDsgYmUgaW5jbHVkZWQgaW4gdGhlIGN1cnJlbnRseSBlbXB0eSBtYWluIHNlY3Rpb24gdGV4 dC48YnIgZGlyPSJhdXRvIj4mZ3Q7PGJyIGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+SGVyZSBJ IGRpc2FncmVlLiBUaGUgdGV4dCBleHBsaWNpdGx5IHJlZmVycyB0bzxiciBkaXI9ImF1dG8iPmRy YWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLCBzYXlpbmcgdGhhdCB0aGUgY29u dGVudHMgb2YgdGhlPGJyIGRpcj0iYXV0byI+J2NuZicsICdyZXFfY25mJyBhbmQgJ3JzX2NuZicg cGFyYW1ldGVycyB1c2UgdGhlIHN5bnRheCBvZiB0aGUgJ2NuZic8YnIgZGlyPSJhdXRvIj5jbGFp bSBmcm9tIHNlY3Rpb24gMy4xIG9mIGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNz aW9uLjxiciBkaXI9ImF1dG8iPlRoZSByZXF1aXJlbWVudHMgaW4gc2VjdGlvbiAzLjIgZHJhZnQt aWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb248YnIgZGlyPSJhdXRvIj5mb2xsb3cgZnJv bSB0aGUgdXNlIG9mIHRoZSBkZWZpbml0aW9ucyBpbiAzLjEuPGJyIGRpcj0iYXV0byI+PGJyIGRp cj0iYXV0byI+SSBkb24ndCBzZWUgdGhlIHZhbHVlIG9mIHJlaXRlcmF0aW5nIHN1Y2ggYSBsb25n IHRleHQgZnJvbSB0aGF0IGRvY3VtZW50PGJyIGRpcj0iYXV0byI+aGVyZSwgd2hlbiBhbiBleHBs aWNpdCByZWZlcmVuY2UgaXMgYWxyZWFkeSBnaXZlbi48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJh dXRvIj48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBkaXI9ImF1dG8iPkdlbi1hcnQgbWFpbGluZyBs aXN0PGJyIGRpcj0iYXV0byI+R2VuLWFydEBpZXRmLm9yZzxiciBkaXI9ImF1dG8iPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFydDxiciBkaXI9ImF1dG8iPjwvYm9k eT48L2h0bWw+ ----_com.samsung.android.email_4645990373229240-- From nobody Sun Dec 22 18:29:25 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0425512006F for ; Sun, 22 Dec 2019 18:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 iCIQ0_EmkdVv for ; Sun, 22 Dec 2019 18:29:23 -0800 (PST) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 59B6B120025 for ; Sun, 22 Dec 2019 18:29:23 -0800 (PST) Received: by mail-vs1-f43.google.com with SMTP id s16so8254335vsc.10 for ; Sun, 22 Dec 2019 18:29:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XKiJktJZPneqnFSaSFHcMhlWg4BN4V7+N6kyFur8lHg=; b=U7zPC6w3NYY8+CPzg8mgZIBuOJQmVVcJTF5qW9OUBnnV5gmMPHhDdre/mtUJq5clue wTB7qHFiuXKGP6tZ3jkdWoZ9lNes2Zwp0lxPXSS9gdMaGcN2RnNLhNxgROyY1tzJOeNm VVb9X9ZaBx6yklHMJPXda4ryy5CNELrgagAloCqNcw8mBMhnzbuqPtv/q47Rxz9QWD0L JAPn063At2OoNgCc/6XiDJDDplBd43B9lANPWfRL01SSNTRH/aHC0/yoUW+JpX8j/NRK 1wWgzAuIJaKX03XheOWN6MpDNtMdm8yz7NMzF0LM/A8r5Znb7TlBm7X6aH/9JBG6YtNL WJyQ== X-Gm-Message-State: APjAAAVmd4T3AoRMS2gTr3LWoRWLttejWzW2Sn6gJ8ze7WTfCgRPEEiH McFJJl44Mfm33qh4jVYtfdOtvPguVIrRIvQbqv/9Sg== X-Google-Smtp-Source: APXvYqxPVjnMvF3ncYNgOHcLZLkooz8tbhVLXQa+o+BAw9UnAJlfnRfFUQY1pMBkCgMzq5KmaQis9KX3Mm8PmhNymPM= X-Received: by 2002:a67:b309:: with SMTP id a9mr10193745vsm.97.1577068162470; Sun, 22 Dec 2019 18:29:22 -0800 (PST) MIME-Version: 1.0 References: <7456FFE2-F792-452A-9DA1-5DEA078CECE0@ericsson.com> In-Reply-To: <7456FFE2-F792-452A-9DA1-5DEA078CECE0@ericsson.com> From: Daniel Migault Date: Sun, 22 Dec 2019 21:29:11 -0500 Message-ID: To: Francesca Palombini Cc: Daniel Migault , Ace Wg Content-Type: multipart/alternative; boundary="0000000000009c54e1059a55cb25" Archived-At: Subject: Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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, 23 Dec 2019 02:29:25 -0000 --0000000000009c54e1059a55cb25 Content-Type: text/plain; charset="UTF-8" Hi, You are correct, the call has expired. Please upload the document as a WG document! Yours, Daniel On Sat, Dec 21, 2019 at 10:28 AM Francesca Palombini wrote: > Hi, > > > > This adoption call has ended a while ago, I am waiting for a conclusion > before submitting the next version of the document, also in view of next > interim. > > > > Hope you have a happy new year celebration, > > Francesca > > > > *From: *Ace on behalf of Daniel Migault > > *Date: *Tuesday, 19 November 2019 at 09:45 > *To: *Ace Wg > *Subject: *[Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile > > > > Dear working group, > > > > As mentioned during the ACE meeting, this mail starts a call for adoption > for draft-palombini-ace-coap-pubsub-profile. Please provide your feed > backs by December 4. > > > > https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/ > > > > Yours, > > Daniel > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000009c54e1059a55cb25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

You are correct, the call has= expired. Please upload the document as a WG document!

=
Yours,=C2=A0
Daniel

On Sat, Dec 21, 2019 at 10:28 AM Francesca= Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

This adoption call has ended a while ago, I am= waiting for a conclusion before submitting the next version of the documen= t, also in view of next interim.

=C2=A0

Hope you have a happy new year celebration,=

Francesca

=C2=A0

From: = Ace <ace-bounces@ietf.org> o= n behalf of Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org&g= t;
Date: Tuesday, 19 November 2019 at 09:45
To: Ace Wg <ace= @ietf.org>
Subject: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-pro= file

=C2=A0

Dear working group,=C2=A0

=C2=A0

As mentioned during the ACE meeting, this mail start= s a call for adoption for draft-palombini-ace-c= oap-pubsub-profile. Please provide your feed backs by December 4.





Yours, =

Daniel<= /u>



_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000009c54e1059a55cb25-- From nobody Sun Dec 22 20:41:11 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C86120074; Sun, 22 Dec 2019 20:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BI6rDV6I; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=ZPsS2RSK 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 TU6H3rjn_8sH; Sun, 22 Dec 2019 20:41:08 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7721B120025; Sun, 22 Dec 2019 20:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10896; q=dns/txt; s=iport; t=1577076068; x=1578285668; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6UL3siiuK08M7p+UEBwwrOivNtJaXGiUX/a3sLQupv4=; b=BI6rDV6I5LaSC+5/ngTaHODtI6M2donKNJtOIdhM5r1JZYxM+dghiUYY ob56WGL+460YbWQztFQ8eokLtwTm66MM0zBDICahwgkUj04A/NtW+xUFN /h2/dCTvQ/v5R0rIc7TEkedGSOzVFbHfUtkRteAHBA8w7KlG5UeiAcIEX Q=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AgWzvwx8UgUcdJf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaGAEjjJfjjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVCQC1RABe/5xdJa1lHgELHINJUAV?= =?us-ascii?q?sKy0gBAsqhAiDRgOKd4JfmAiBQoEQA1QCBwEBAQkDAQEYCwoCAQGEQAKCHCQ?= =?us-ascii?q?4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBEBEdAQEsCwELBAIBBgIOAwQ?= =?us-ascii?q?BAR4NAgICJQsdCAIEAQ0FCAYUgwGBeU0DHw8BAgyQRJBkAoE4iGF1gTKCfgE?= =?us-ascii?q?BBYE1ARNBgw0YggUHAwaBNoFTiikdGoFBP4ERR4JMPoJkAQEBAgGBLAESAQk?= =?us-ascii?q?YMIJeMoIsjT0MgnGIGZZBCoI0g2GCN4EbjwGCRod7jjGBZY5SiFKSBAIEAgQ?= =?us-ascii?q?FAg4BAQWBaSJnWBEIcBU7gmxQGA2NEjiDO4UUhT90AYEnjTARFwKBOl8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,346,1571702400"; d="p7s'?scan'208";a="388633844" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Dec 2019 04:41:07 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xBN4f731010570 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Dec 2019 04:41:07 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 22 Dec 2019 22:41:06 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 22 Dec 2019 22:41:06 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 22 Dec 2019 22:41:06 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D7Yer+3ydqrHV81SUxn5TpXkYK1bREHsZiknUjaht/eNfIcVOPIaZm1hY9QoBl3s4dMdO+HQEZkP4UmxQeSKWwLXKnV3+kR+Mg9bfmPx1SGLw2vKDYwPK/v+PlxGed3FWR66gugJw+M0QvPm3FSpTVEAo7W636w4OSlWrhb+YstD9Xh6JCBZelbgXIkm+9vOIpiha9JXoxQ/pWhtsiJZ77nsPVym2uN1ZV9RlCzF6gzCHqfp7TzijPtHrjEirvtVdnWDZOZka1ZHvUTuaThilz2a4BWBf1lF2DDhLJh/cOXbMxJSUkxmfa8dA4LwSbumcwb5r+fDkgwgJjmKYLYvuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8TXq2ZjLq4tj/Dtpv5wiJOkssgNWJcYHA9PXt33iF0k=; b=mvXPR/rucTMasDmtgtJ9m+Xs/GeqPu0NCE3TPZjZ9aacQyGfXZwh+Ekp8TSwrpIQs4l6UsdH4i9YLM2cC/N3T20tOMqv39ZwrGEy5lhBVuLFiAS0b5T7vpQ7rt4w9TpXWOPmQhcICI6HXaRSzoMcnYxzGEaYv1QG3Hj1oA7ybDfJA4ezimb2VnzHZcdEpuaKohqsNO9RZ70IXHMyhCshef3unsPGIpn/nrPDE9hTgFHjn8mXwZFxGTbPiSnM2AFe1HGtis30h28NMKLMUzQF5BOdNEj5f8rgtyL7gIByCu/bF3ZjNYkjfBtqLz3J3SMal+jWa8+xAR3oH7FnrrACSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8TXq2ZjLq4tj/Dtpv5wiJOkssgNWJcYHA9PXt33iF0k=; b=ZPsS2RSKhqjkQQQjiOCm6lrjazCPk90bVvHoeQGh8hF4cifHCiLf4r+CJBVyB5kHe1VGqs0PsqN25dHgSPPRkWem+Pv8cgCcqXDMn5ybOVrstNz84WZhU0n2Kj/HIT/RhJpgzvAGOHXrc0oVVMnkO41sfjC7kDiuz+PCdQHVzaM= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2548.namprd11.prod.outlook.com (52.135.245.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.16; Mon, 23 Dec 2019 04:41:05 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.017; Mon, 23 Dec 2019 04:41:05 +0000 From: "Panos Kampanakis (pkampana)" To: Roman Danyliw , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Thread-Index: AQHVtFyGFe5/PrA9gkyvssXlx+7u4afHLUWw Date: Mon, 23 Dec 2019 04:41:04 +0000 Message-ID: References: <157653372668.24465.13819182999807823012.idtracker@ietfa.amsl.com> In-Reply-To: <157653372668.24465.13819182999807823012.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 986db3a6-dc77-4284-0d65-08d78762524f x-ms-traffictypediagnostic: BN7PR11MB2548: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(366004)(136003)(346002)(396003)(376002)(39860400002)(199004)(189003)(13464003)(6506007)(53546011)(54906003)(52536014)(478600001)(110136005)(186003)(71200400001)(81156014)(55016002)(81166006)(86362001)(8676002)(4326008)(9686003)(66616009)(76116006)(66476007)(33656002)(64756008)(66446008)(966005)(5660300002)(8936002)(66946007)(66556008)(7696005)(2906002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2548; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qfhWzMXJ9C/MhZAFxm4DVt1kNBpgoZdBYzuH+a8We+t6GhvASGfiQ14I2lKnNqaUVBRVBD+T0B6TuH14K3JgCloOEb4IEvU7Kvwv5YEcpJnrHznAhdJ0TfripaP/AWu9g3zHZh/zVzrtAEZsNB2NI+ZD27G5/ZK42dhOFMhl3oYYM+F8AeBUPmDvmYVBOwDWgl7zYU5KUgTrK2m6i0RrhyXjaw/0pPmdram7TjGW/QNMuXNZZaFQQ2+/vBzyuRa9jdP3dY5LgbasYen/JXKSoq2WPRV+q0AmPHZIMePd8fZ4Odwf15m96yBN0Sccz2NGnyebstI1QPVbem+INaU3NkrSIRNf67YGs1+qb5vhMP2vuZZYII09rHLtlq6qBoSHFwbLjQKTxdZVJhX5A7AxcoeEKyTMqYoYiSgAJw5ij9I4KCMWWTiMfvXtLC32K2357ppJuCXMQhzU741pMGlDntDmZJXc9PqlHAC8/d9099Irka80F4fB1oK/mOmr3iRUF7eMoo21ZJcqQq+OT1GdRbsS/7a6oAV7AGcAIslj8KXnYsn/cVWu4PUHDRllZksAZzHPjyJJaTZhcNaX4tv7802ZdV85inZ178ZebVKv0fE= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0012_01D5B921.45E088E0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 986db3a6-dc77-4284-0d65-08d78762524f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2019 04:41:05.0783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Na9xmUrxyloOqQ5r49JiZeJkCRDT4Pj5+lm45MgR6GeCUhbEzwvuLOvVMYN9+g5SLcrl7UuxBKJdNzcfMWrZmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2548 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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, 23 Dec 2019 04:41:11 -0000 ------=_NextPart_000_0012_01D5B921.45E088E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thank you for the thorough review.=20 Please check the response to your feedback in = https://github.com/SanKumar2015/EST-coaps/issues/154 There we include = the fixes we will make and our thoughts on a couple of your comments.=20 Please let us know if you have any further objections. Panos -----Original Message----- From: Ace On Behalf Of Roman Danyliw via = Datatracker Sent: Monday, December 16, 2019 5:02 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Roman Danyliw's No Objection on = draft-ietf-ace-coap-est-17: (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 4. Per =E2=80=9Cthe DTLS connections SHOULD only be kept = alive for EST messages that are relatively close to each other=E2=80=9D, = I think the text means that some EST messages are more likely to occur = one after another. It would be worth being clearer what these would be. * Section 5.1. Per =E2=80=9CThese URIs are shorter than the ones in = [RFC7030]=E2=80=9D, does Table 1 imply that when using EST-coaps the = =E2=80=9Clonger names=E2=80=9D from RFC7030 wouldn=E2=80=99t be valid? * Section 5.2 Per =E2=80=9CThe latter ones are deemed to expensive = =E2=80=A6=E2=80=9D, was difficult to parse as the sentence prior has = three things (instead of two). Is this sentence referring to the = =E2=80=9Cnot specified functions=E2=80=9D only? * Section 5.3, Per =E2=80=9C30% smaller payload for DER-encoded = ASN.1=E2=80=9D, if you can cite this metric, please do. * Section 5.8. Per =E2=80=9CIn summary, the symmetrically encrypted key = is included in the encryptedKey attribute in a KEKRecipientInfo = structure=E2=80=9D, if this is done in a server-side key generation = scenario, where is the client getting the key to decrypt the server = computed key material? Should the DecryptKeyIdentifier/ = AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per = Sections 4.4.1.1/4.4.1.2 of RFC7030? * Section 10.1. Per =E2=80=9CWhen server-side key generation is used, = the constrained device depends on the server to generate the private key = randomly, but it still needs locally generated random numbers for use in = security protocols, as explained in Section 12 of [RFC7925].=E2=80=9D, = is the =E2=80=9Csecurity protocols=E2=80=9D referenced here anything = beyond DTLS? * Section 10.1. Per =E2=80=9CIn such occasions, checking the = certificate revocation status or authorizing the client using another = method is important for the server to ensure that the client is to be = trusted.=E2=80=9D -- does this text suggest that expired+revoked certificates should not = be used? -- to word-smith: s/for the server to ensure that the client is to be trusted/for the = server to raise its confidence that the client can be trusted/ * Section 10.1. Per =E2=80=9CMore information about recommendations of = TLS and DTLS are included in [BCP195]=E2=80=9D, thanks for referencing BCP195. = Could you please clarify with normative language if these recommendations SHOULD/MUST be = followed? * Editorial - Section 4. Per =E2=80=9CAuthenticating and negotiating DTLS keys = requires resources on low- end endpoints and consumes valuable = bandwidth=E2=80=9D, I=E2=80=99m not sure this sentence is needed. = Technically, =E2=80=9Cauthenticating and negotiating DTLS keys requires = resources=E2=80=9D on any endpoint. - Section 4. OLD: Given that after a successful enrollment, it is more likely that a = new EST transaction will take place after a significant amount of time, = NEW: Given that after a successful enrollment, it is more likely that a = new EST transaction will not take place for a significant amount of = time, - Section 5.5. Typo. s/successfull/successful/ - Section 5.8. s/Such scenarios could be when it is =E2=80=A6/Such = scenarios apply when it is =E2=80=A6/ - Section 5.8. s/ client, or when the resources/client, when the = resources/ - Section 5.8. s/Then the private key/The private key/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0012_01D5B921.45E088E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjIzMDQ0MTAzWjAvBgkqhkiG9w0BCQQxIgQgslXHphC0PGUB2UM/lP9RCpYGMYxUlugS vCSPPgTvk10wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA l524p3d6R4Fb4zfrmXz8RBqoewqGNpQJhhwi5DNGLfvRAkfQgb2lZuCRwqOiQZ8D1N89WnzF8EH3 Gfzn4lLbeUv78ubxJFqSzdRFlk9pfwalrUGTuWMqVefkMUjo0Zna8SMrjqywLjMLm0X1BflmbcfR zb25hhiLJ9cGH9QzkSFuAoQYlc1ATTKny8A1SkV0znki7odaNhd2L1V8r/FpuvPImztTWDOXtKi1 9NApmHrxmb2HRHHZxguiLxDa7cYflJk5RsZ2Tm00Jj/098MFZrBSg06eEHD4R0bCTtrEfrLq1EC0 nEeACziaM9jniTZwnBLMoOyUdDhuPILST11DAgAAAAAAAA== ------=_NextPart_000_0012_01D5B921.45E088E0-- From ludwig.seitz@combitech.se Sun Dec 22 23:52:46 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBB7120074; Sun, 22 Dec 2019 23:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6lDhWAiRVx7l; Sun, 22 Dec 2019 23:52:43 -0800 (PST) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A1A12004A; Sun, 22 Dec 2019 23:52:42 -0800 (PST) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id xBN7qHsh025100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Dec 2019 08:52:17 +0100 Received: from corpappl16594.corp.saab.se (corpappl16594.corp.saab.se [10.12.12.126]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id xBN7q3fW013399 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Dec 2019 08:52:03 +0100 Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16594.corp.saab.se (10.12.12.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Mon, 23 Dec 2019 08:52:03 +0100 Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1847.003; Mon, 23 Dec 2019 08:52:03 +0100 From: Seitz Ludwig To: "'elwynd'" , Ludwig Seitz , "Elwyn Davies" , "gen-art@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-ace-oauth-params.all@ietf.org" , "ace@ietf.org" Thread-Topic: [Gen-art] [Ace] Genart last call review of draft-ietf-ace-oauth-params-06 Thread-Index: AQHVuPcohBjIfZMHXEW74d/seKNoOKfHVcdA Date: Mon, 23 Dec 2019 07:52:03 +0000 Message-ID: <343e0d4096cf4bb782cccf10176748f1@combitech.se> References: <60524620-542b-293d-d954-7c7ecb45bde1@gmx.de> In-Reply-To: Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.199] Content-Type: multipart/alternative; boundary="_000_343e0d4096cf4bb782cccf10176748f1combitechse_" MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: xBN7q3fW013399 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.502, required 5, ALL_TRUSTED -1.00, HTML_MESSAGE 0.00, KAM_NUMSUBJECT 0.50, SURBL_BLOCKED 1.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1577692324.00995@vdOiiTCHW/Vc4xPoDziqPQ X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Mon, 23 Dec 2019 08:52:18 +0100 (CET) Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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, 23 Dec 2019 07:57:55 -0000 --_000_343e0d4096cf4bb782cccf10176748f1combitechse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRWx3eW4sDQoNClNvcnJ5IGZvciBiZWluZyBhIHBhaW4uIEkgaGF2ZSBvbmUgbW9yZSBj b21tZW50Lg0KDQovTHVkd2lnIChub3cgZmluYWxseSBmcm9tIHRoZSBjb3Jwb3JhdGUgYWNjb3Vu dCkNCg0KRnJvbTogZWx3eW5kIDxlbHd5bmRAZm9sbHkub3JnLnVrPg0KU2VudDogZGVuIDIyIGRl Y2VtYmVyIDIwMTkgMTk6MjcNClRvOiBMdWR3aWcgU2VpdHogPGx1ZHdpZ19zZWl0ekBnbXguZGU+ OyBFbHd5biBEYXZpZXMgPGVsd3luZEBkaWFsLnBpcGV4LmNvbT47IGdlbi1hcnRAaWV0Zi5vcmcN CkNjOiBsYXN0LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy5hbGxA aWV0Zi5vcmc7IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtHZW4tYXJ0XSBbQWNlXSBHZW5h cnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMtMDYNCg0K SGksIEx1ZHdpZy4NCg0KSGF2aW5nIGhhZCBhbm90aGVyIGxvb2sgYXQgc2VjdGlvbiAzLjEgb2Yg ZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24sIHRlY2huaWNhbGx5IHRoZSBy dWxlcyBhYm91dCB3aGljaCBrZXlzIGhhdmUgdG8gYmUgcHJlc2VudCBhcmUgbm90IHBhcnQgb2Yg dGhlIHN5bnRheCBvZiB0aGUgY25mIGNsYWltLiAgVGhlIHBvaW50IGNhbiBiZSBjb3ZlcmVkIGJ5 IGNoYW5naW5nICcic3ludGF4IG9mIHRoZSAnY25mJyBjbGFpbSINCnRvICJzeW50YXggYW5kIHNl bWFudGljcyBvZiB0aGUgJ2NuZicgY2xhaW0iDQppbiBlYWNoIGNhc2UuDQoNCltMU10gT2suIFdp bGwgZG8uDQoNCkhvd2V2ZXIsIHRoZSBzZWNvbmQgbG9vayB0aHJldyB1cCBhbm90aGVyIHBvaW50 OiAgRmlndXJlIDIgaW4gczMuMiBnaXZlcyBhIFN5bWV0cmljIGtleSBleGFtcGxlICAtIEkgdGhp bmsgdGhpcyBzaG91bGQgdXNlIGFuIEVuY3J5cHRlZF9DT1NFX0tleSAob3IgRW5jcnlwdGVkX0NP U0VfS2V5MCkgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4zIG9mIGRyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uLg0KDQpbTFNdIEZpZ3VyZSAyIGluIDMuMiBnaXZlcyBhbiBl eGFtcGxlIG9mIGEgQVMgcmVzcG9uc2UgdG8gYSBjbGllbnQgcmVxdWVzdGluZyBhbiBhY2Nlc3Mg dG9rZW4uIEFzIHBlciB0aGUgcmVxdWlyZW1lbnRzIGZyb20gZHJhZnQtaWV0Zi1hY2Utb2F1dGgt YXV0aHosIHRoaXMgY29tbXVuaWNhdGlvbiBNVVNUIGJlIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0 ZWQsIHRoZXJlZm9yZSBpdCBpcyB1bm5lY2Vzc2FyeSB0byBhZGRpdGlvbmFsbHkgZW5jcnlwdCB0 aGUgQ09TRV9LZXkuDQpUaGUgcHJvdmlzaW9ucyBpbiAzLjMgb2YgZHJhZnQtaWV0Zi1hY2UtY3d0 LXByb29mLW9mLXBvc3Nlc3Npb24gYXJlIGZvciBhY2Nlc3MgdG9rZW5zIGluIENXVCBmb3JtYXQs IGNvbnRhaW5pbmcgYSBzeW1tZXRyaWMga2V5LCB0aGF0IGFyZSBub3QgZW5jcnlwdGVkIHRoZW1z ZWx2ZXMgKGkuZS4gb25seSBNQUM6ZWQgb3Igc2lnbmVkKS4NCg0KT3RoZXJ3aXNlIEkgdGhpbmsg d2UgYXJlIGRvbmUuDQoNCkV2ZW50dWFsbHkgd2Ugd2lsbCBnZXQgdG8gQ2hyaXN0bWFzIQ0KDQpb TFNdIEkgcHJvbWlzZSB0byBsZWF2ZSBpdCBiZSBvdmVyIHRoZSBob2xpZGF5cy4NCg== --_000_343e0d4096cf4bb782cccf10176748f1combitechse_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGVsbG8gRWx3eW4sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U29ycnkg Zm9yIGJlaW5nIGEgcGFpbi4gSSBoYXZlIG9uZSBtb3JlIGNvbW1lbnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4vTHVkd2lnIChub3cgZmluYWxseSBmcm9tIHRo ZSBjb3Jwb3JhdGUgYWNjb3VudCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IGVsd3luZCAmbHQ7ZWx3eW5kQGZvbGx5Lm9yZy51ayZndDsNCjxicj4NCjxiPlNlbnQ6 PC9iPiBkZW4gMjIgZGVjZW1iZXIgMjAxOSAxOToyNzxicj4NCjxiPlRvOjwvYj4gTHVkd2lnIFNl aXR6ICZsdDtsdWR3aWdfc2VpdHpAZ214LmRlJmd0OzsgRWx3eW4gRGF2aWVzICZsdDtlbHd5bmRA ZGlhbC5waXBleC5jb20mZ3Q7OyBnZW4tYXJ0QGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBsYXN0 LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy5hbGxAaWV0Zi5vcmc7 IGFjZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0dlbi1hcnRdIFtBY2VdIEdl bmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0wNjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwg THVkd2lnLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IYXZpbmcgaGFkIGFub3RoZXIgbG9vayBhdCBzZWN0aW9uIDMuMSBvZiBkcmFmdC1pZXRm LWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbiwgdGVjaG5pY2FsbHkgdGhlIHJ1bGVzIGFib3V0 IHdoaWNoIGtleXMgaGF2ZSB0byBiZSBwcmVzZW50IGFyZSBub3QgcGFydCBvZiB0aGUgc3ludGF4 IG9mIHRoZSBjbmYgY2xhaW0uJm5ic3A7IFRoZSBwb2ludCBjYW4gYmUgY292ZXJlZCBieSBjaGFu Z2luZyAnJnF1b3Q7c3ludGF4IG9mIHRoZQ0KICdjbmYnIGNsYWltJnF1b3Q7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byAmcXVvdDtzeW50YXgg YW5kIHNlbWFudGljcyBvZiB0aGUgJ2NuZicgY2xhaW0mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluIGVhY2ggY2FzZS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0xTXSBPay4gV2lsbCBkby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIs IHRoZSBzZWNvbmQgbG9vayB0aHJldyB1cCBhbm90aGVyIHBvaW50OiZuYnNwOyBGaWd1cmUgMiBp biBzMy4yIGdpdmVzIGEgU3ltZXRyaWMga2V5IGV4YW1wbGUmbmJzcDsgLSBJIHRoaW5rIHRoaXMg c2hvdWxkIHVzZSBhbiBFbmNyeXB0ZWRfQ09TRV9LZXkgKG9yIEVuY3J5cHRlZF9DT1NFX0tleTAp IGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMyBvZiBkcmFmdC1pZXRmLWFjZS1jd3QtcHJvb2Yt b2YtcG9zc2Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+W0xTXSBGaWd1cmUgMiBpbiAzLjIgZ2l2ZXMgYW4gZXhhbXBsZSBvZiBhIEFTIHJlc3Bv bnNlIHRvIGEgY2xpZW50IHJlcXVlc3RpbmcgYW4gYWNjZXNzIHRva2VuLiBBcyBwZXIgdGhlIHJl cXVpcmVtZW50cyBmcm9tIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LCB0aGlzIGNvbW11bmlj YXRpb24NCiBNVVNUIGJlIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0ZWQsIHRoZXJlZm9yZSBpdCBp cyB1bm5lY2Vzc2FyeSB0byBhZGRpdGlvbmFsbHkgZW5jcnlwdCB0aGUgQ09TRV9LZXkuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhlIHByb3Zpc2lvbnMgaW4gMy4zIG9mIGRyYWZ0LWlldGYtYWNlLWN3 dC1wcm9vZi1vZi1wb3NzZXNzaW9uIGFyZSBmb3IgYWNjZXNzIHRva2VucyBpbiBDV1QgZm9ybWF0 LCBjb250YWluaW5nIGEgc3ltbWV0cmljIGtleSwgdGhhdCBhcmUgbm90IGVuY3J5cHRlZCB0aGVt c2VsdmVzDQogKGkuZS4gb25seSBNQUM6ZWQgb3Igc2lnbmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T3RoZXJ3aXNlIEkgdGhpbmsgd2UgYXJlIGRvbmUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW50dWFsbHkgd2Ugd2lsbCBn ZXQgdG8gQ2hyaXN0bWFzISZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bTFNdIEkgcHJv bWlzZSB0byBsZWF2ZSBpdCBiZSBvdmVyIHRoZSBob2xpZGF5cy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_343e0d4096cf4bb782cccf10176748f1combitechse_-- From nobody Mon Dec 23 01:12:44 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD3B12008A; Mon, 23 Dec 2019 01:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl 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 pny_k1UK12xh; Mon, 23 Dec 2019 01:12:36 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA8312008F; Mon, 23 Dec 2019 01:12:35 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 886298140; Mon, 23 Dec 2019 09:12:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=wVJm1ue86bKHDc3tVg i/P0mYIVCgu/Vkdx45wTWR+gw=; b=Dv1iyezP4yjsdDs5yjJOGjwXwv+H+fkdcq dL43Y4UTpdNf78eaizTGBKrP8AgwkcEQK4OAhlOn/qSr5OzuQ/Tp1cKxO59z7Ehf UaKRHi0y9GQe2Zjq3BgT0JMj30CtGK/BGIFpzxczV7YPfQs6S2JVWwUbZVMpw65A wHec4jClA= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2553:2559:2562:2827:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3874:4118:4250:4321:5007:6119:6248:6261:6657:6659:6678:7903:7974:8603:8784:9036:9177:10004:10400:10848:11232:11658:11783:11914:12043:12109:12114:12295:12663:12740:12895:13071:13139:13161:13229:13255:13848:14093:14096:14149:14180:14721:21060:21080:21325:21433:21451:21627:21771:21818:21939:30003:30054:30062:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none X-HE-Tag: basin55_3381b72596b38 X-Filterd-Recvd-Size: 7008 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf14.hostedemail.com (Postfix) with ESMTPA; Mon, 23 Dec 2019 09:12:33 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_44a3af8ef6f6467ebdf2f1dd617424a3" Date: Mon, 23 Dec 2019 10:12:33 +0100 From: Peter van der Stok To: Carsten Bormann Cc: Klaus Hartke , Alexey Melnikov , ace-chairs@ietf.org, Jim Schaad , Benjamin Kaduk , Ace Wg , draft-ietf-ace-coap-est@ietf.org, The IESG Reply-To: consultancy@vanderstok.org In-Reply-To: <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: <32540abd39940ad245e3c814e64a40e7@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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, 23 Dec 2019 09:12:38 -0000 --=_44a3af8ef6f6467ebdf2f1dd617424a3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed HI all, We had this discussion about this specific text several times. I like to keep at least some text for the following reason: Implementers, new to coap without a photographic memory of RFC7252 text, are surprised by the absence of uri host in the examples, and tend to assume an error. The curent text does not look like a "normative rephrasing" to me. Nevertheless, is the suggestion below acceptable to everyone? OLD The Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. NEW Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Other suggestions are welcome. Peter Carsten Bormann schreef op 2019-12-20 18:16: > On Dec 20, 2019, at 17:34, Klaus Hartke wrote: > >> I would prefer if draft-ietf-ace-coap-est didn't say anything here, >> since the Uri-Host and Uri-Port options and whether they should be >> omitted or not is entirely specified by CoAP [RFC7252].* > > Klaus has an important point here. > > We need to be **much more** vigilant about specifications messing with their normative references. > Saying how they are used, yes, but re-stating (or, worse, re-interpreting) normative material from those references is prone to creating dialects that no longer interoperate with their unadulterated originals. Unless these are hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT. > > Grüße, Carsten > > (*) the normative reference EST has an example for that case: The use of content-transfer-encoding with HTTP, which is explicitly ruled out in Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was a count of RFC 7030 messing with a normative reference, and in turn **needed** to be messed with in CoAP-EST (and eventually needs to be fixed in the parent specification, too). --=_44a3af8ef6f6467ebdf2f1dd617424a3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI all,

We had this discussion about this specific text several = times.
I like to keep at least some text for the following reason:
Implementers, new to coap without a photographic memory of RFC7252 text, = are surprised by the absence of uri host in the examples, and tend to assum= e an error.

The curent text does not look like a "normative reph= rasing" to me.
Nevertheless, is the suggestion below acceptable to ev= eryone?

OLD

The Uri-Host and Uri-Port Options can be omitted if they coincide
&= nbsp;  with the transport protocol destination address and port
&= nbsp;  respectively.  Explicit Uri-Host and Uri-Port Options are = typically
   used when an endpoint hosts multiple virtual se= rvers and uses the
   Options to route the requests accordin= gly.

NEW

Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Optio= ns can be omitted if they coincide
   with the transport pro= tocol destination address and port
   respectively. 
Other suggestions are welcome.

Peter

Carsten Bormann schreef op 2019-12-20 18:16:

= On Dec 20, 2019, at 17:34, Klaus Hartke <hartke@projectcool.de> wrote:

I would prefer if draft-ietf-ace-coap-est didn't= say anything here,
since the Uri-Host and Uri-Port options and whethe= r they should be
omitted or not is entirely specified by CoAP [RFC7252= ].*

Klaus has an important point here.

We need to be **much mo= re** vigilant about specifications messing with their normative references= =2E
Saying how they are used, yes, but re-stating (or, worse, re-inter= preting) normative material from those references is prone to creating dial= ects that no longer interoperate with their unadulterated originals.  = Unless these are hopelessly broken(*) and this is the only way to fix them,= this is a MUST NOT.

Grüße, Carsten

(*) th= e normative reference EST has an example for that case: The use of content-= transfer-encoding with HTTP, which is explicitly ruled out in Section 19.4= =2E5 of RFC 2616 (and now appendix A.5 of RFC 7231).  That was a count= of RFC 7030 messing with a normative reference, and in turn **needed** to = be messed with in CoAP-EST (and eventually needs to be fixed in the parent = specification, too).

--=_44a3af8ef6f6467ebdf2f1dd617424a3-- From nobody Mon Dec 23 06:42:55 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E454B1200C1; Mon, 23 Dec 2019 06:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Q6PKphD7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DqBKcDvA 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 NlH3Au61h8RC; Mon, 23 Dec 2019 06:42:50 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB371200B7; Mon, 23 Dec 2019 06:42:50 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A003821C1B; Mon, 23 Dec 2019 09:42:46 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 23 Dec 2019 09:42:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=8il5EFdC4+iOrbcEtz84kGUq64waNoB JePLhk6EIEM0=; b=Q6PKphD7IGXYrwMWKXPmhyl4hCOx823ZEXDvqO/f3Z4wYVw w8ar/LcMb5bpGJSLSMB/2oc5yqa/0pbIAlUCEVlB8jvWT1ZTpRoQ6+zw0fnY3a7N 1kegL1ZK0ue0j43LXZMeVYuokgMJpKYyxtNjP2Xaehv1sFuLZHZC7WNay7w/UpyC N6Twtn5a/oRJu8m7wfONVMAA2Z5IB1FZgV+XSLsIoNHqLtBJHdKSvBMIzmHIo//f EZ7KYEnehl5GE0UG3DFN/Sr+wLS/CZTNsPDBfrr4LanCrgccuy/WgYNJBrm2E7P8 lQakN4gO7zpmXQ4Dw+purbK5cwmZUUO5dp1C8KA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8il5EF dC4+iOrbcEtz84kGUq64waNoBJePLhk6EIEM0=; b=DqBKcDvAxFSXsPN2vuSs86 sXbMYAyC4hr0q3TWKP+pdHpGOkKHkTR3JDnyFNCIxe7oZmwpKyG3fcErcUso00S6 /dh8rS9veaxPHVVZAH4sYRBlMUP0ShBsVsXBeFKlLY3efZVh1yfrhzFs3U0HoBng Y1ke85Z0YTBjpfWXxWHb+2b9DS50eO9u2D18oFS40zDx06IufEdWSfjPIxVKflVW RrWUAN/LeaY9LgUNMqPSj+y805UCq+ARRuBgqkW8qsizuqQCc4qbFHhGazGP67CW lD5un9qyhNbJRhGJomOabsib3ggrhj8f331bDlRNdSZjJOJ6bXVf0Q/uffYXf0Mg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddvtddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D1EA5C200A4; Mon, 23 Dec 2019 09:42:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <32540abd39940ad245e3c814e64a40e7@bbhmail.nl> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> <32540abd39940ad245e3c814e64a40e7@bbhmail.nl> Date: Mon, 23 Dec 2019 14:42:24 +0000 From: "Alexey Melnikov" To: consultancy@vanderstok.org, "Carsten Bormann" Cc: "Klaus Hartke" , ace-chairs@ietf.org, "Jim Schaad" , "Benjamin Kaduk" , "Ace Wg" , draft-ietf-ace-coap-est@ietf.org, "The IESG" Content-Type: multipart/alternative; boundary=3a22224eb1f640a394c73d1fbde4c809 Archived-At: Subject: Re: [Ace] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-ace-co?= =?utf-8?q?ap-est-17=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ace@ietf.org 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, 23 Dec 2019 14:42:53 -0000 --3a22224eb1f640a394c73d1fbde4c809 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter, On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: > HI all, >=20 > We had this discussion about this specific text several times. > I like to keep at least some text for the following reason: > Implementers, new to coap without a photographic memory of RFC7252 tex= t, are surprised by the absence of uri host in the examples, and tend to= assume an error. >=20 > The curent text does not look like a "normative rephrasing" to me.=20 > Nevertheless, is the suggestion below acceptable to everyone? >=20 > OLD >=20 > The Uri-Host and Uri-Port Options can be omitted if they coincide > with the transport protocol destination address and port > respectively. Explicit Uri-Host and Uri-Port Options are typically > used when an endpoint hosts multiple virtual servers and uses the > Options to route the requests accordingly. >=20 > NEW > Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Opt= ions can be omitted if they coincide > with the transport protocol destination address and port > respectively.=20 >=20 > Other suggestions are welcome. Your suggested text is much better. Thank you, Alexey > Peter > Carsten Bormann schreef op 2019-12-20 18:16: >> On Dec 20, 2019, at 17:34, Klaus Hartke wrote= :=20 >>>=20 >>> I would prefer if draft-ietf-ace-coap-est didn't say anything here, >>> since the Uri-Host and Uri-Port options and whether they should be >>> omitted or not is entirely specified by CoAP [RFC7252].* >>=20 >> Klaus has an important point here. >>=20 >> We need to be **much more** vigilant about specifications messing wit= h their normative references. >> Saying how they are used, yes, but re-stating (or, worse, re-interpre= ting) normative material from those references is prone to creating dial= ects that no longer interoperate with their unadulterated originals. Unl= ess these are hopelessly broken(*) and this is the only way to fix them,= this is a MUST NOT. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> (*) the normative reference EST has an example for that case: The use= of content-transfer-encoding with HTTP, which is explicitly ruled out i= n Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That wa= s a count of RFC 7030 messing with a normative reference, and in turn **= needed** to be messed with in CoAP-EST (and eventually needs to be fixed= in the parent specification, too). --3a22224eb1f640a394c73d1fbde4c809 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Peter,
=

On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok= wrote:
HI all,

We had this discussion about this specific text s= everal times.
I like to keep at least some text for the fo= llowing reason:
Implementers, new to coap without a photog= raphic memory of RFC7252 text, are surprised by the absence of uri host = in the examples, and tend to assume an error.

The curent text does not look like a "normative rephrasing" to me.
Nevertheless, is the suggestion below acceptable to everyon= e?

OLD

The Uri-Host and Uri-Port Options can be omitted if they coincide
   with the transport protocol destination address an= d port
   respectively.  Explicit Uri-Host = and Uri-Port Options are typically
   used when = an endpoint hosts multiple virtual servers and uses the
&n= bsp;  Options to route the requests accordingly.

=
NEW

Section 5.10.1 of RFC7252 spe= cifies that the Uri-Host and Uri-Port Options can be omitted if they coi= ncide
   with the transport protocol destination= address and port
   respectively. 

Other suggestions are welcome.

Your suggested text is much better.

Thank you,
Alexey

Peter

= Carsten Bormann schreef op 2019-12-20 18:16:

On Dec 20, 2019, at 17:34, Klaus Hartke <hartke@projectcool.de> wrote:

I would prefer if dr= aft-ietf-ace-coap-est didn't say anything here,
since the = Uri-Host and Uri-Port options and whether they should be
o= mitted or not is entirely specified by CoAP [RFC7252].*

Klaus has an important point here.

We need to be **much more** vigilant about specificati= ons messing with their normative references.
Saying how th= ey are used, yes, but re-stating (or, worse, re-interpreting) normative = material from those references is prone to creating dialects that no lon= ger interoperate with their unadulterated originals.  Unless these = are hopelessly broken(*) and this is the only way to fix them, this is a= MUST NOT.

Gr=C3=BC=C3=9Fe, Carsten

(*) the normative reference EST has an example for= that case: The use of content-transfer-encoding with HTTP, which is exp= licitly ruled out in Section 19.4.5 of RFC 2616 (and now appendix A.5 of= RFC 7231).  That was a count of RFC 7030 messing with a normative = reference, and in turn **needed** to be messed with in CoAP-EST (and eve= ntually needs to be fixed in the parent specification, too).

--3a22224eb1f640a394c73d1fbde4c809-- From nobody Mon Dec 23 11:50:01 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AD9120D2A; Mon, 23 Dec 2019 11:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2iqbALqDCHJD; Mon, 23 Dec 2019 11:49:43 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C60120D43; Mon, 23 Dec 2019 11:49:41 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 23 Dec 2019 11:49:30 -0800 From: Jim Schaad To: 'Seitz Ludwig' , 'elwynd' , 'Ludwig Seitz' , 'Elwyn Davies' , CC: , , References: <60524620-542b-293d-d954-7c7ecb45bde1@gmx.de> <343e0d4096cf4bb782cccf10176748f1@combitech.se> In-Reply-To: <343e0d4096cf4bb782cccf10176748f1@combitech.se> Date: Mon, 23 Dec 2019 11:49:28 -0800 Message-ID: <010701d5b9ca$18f4b3c0$4ade1b40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0108_01D5B987.0AD432E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGqYNEoQJoR/zVTA38PKB/Cx2EopAIXUDtOAVeE6aOoA1uCIA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org 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, 23 Dec 2019 19:49:49 -0000 ------=_NextPart_000_0108_01D5B987.0AD432E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Ace On Behalf Of Seitz Ludwig Sent: Sunday, December 22, 2019 11:52 PM To: 'elwynd' ; Ludwig Seitz ; = Elwyn Davies ; gen-art@ietf.org Cc: last-call@ietf.org; draft-ietf-ace-oauth-params.all@ietf.org; = ace@ietf.org Subject: Re: [Ace] [Gen-art] Genart last call review of = draft-ietf-ace-oauth-params-06 =20 Hello Elwyn, =20 Sorry for being a pain. I have one more comment. =20 /Ludwig (now finally from the corporate account) =20 From: elwynd >=20 Sent: den 22 december 2019 19:27 To: Ludwig Seitz >; = Elwyn Davies >; = gen-art@ietf.org =20 Cc: last-call@ietf.org ; = draft-ietf-ace-oauth-params.all@ietf.org = ; ace@ietf.org = =20 Subject: Re: [Gen-art] [Ace] Genart last call review of = draft-ietf-ace-oauth-params-06 =20 Hi, Ludwig. =20 Having had another look at section 3.1 of = draft-ietf-ace-cwt-proof-of-possession, technically the rules about = which keys have to be present are not part of the syntax of the cnf = claim. The point can be covered by changing '"syntax of the 'cnf' = claim" to "syntax and semantics of the 'cnf' claim" in each case. =20 [LS] Ok. Will do. =20 However, the second look threw up another point: Figure 2 in s3.2 gives = a Symetric key example - I think this should use an Encrypted_COSE_Key = (or Encrypted_COSE_Key0) as described in section 3.3 of = draft-ietf-ace-cwt-proof-of-possession. =20 [LS] Figure 2 in 3.2 gives an example of a AS response to a client = requesting an access token. As per the requirements from = draft-ietf-ace-oauth-authz, this communication MUST be confidentiality = protected, therefore it is unnecessary to additionally encrypt the = COSE_Key.=20 The provisions in 3.3 of draft-ietf-ace-cwt-proof-of-possession are for = access tokens in CWT format, containing a symmetric key, that are not = encrypted themselves (i.e. only MAC:ed or signed). =20 [JLS] I tend to agree with not doing the encryption in the example. The = encryption is not required as protection could be done elsewhere and = having an example that people can read increases the usability of the = example. =20 Jim =20 =20 Otherwise I think we are done. =20 Eventually we will get to Christmas! =20 =20 [LS] I promise to leave it be over the holidays. ------=_NextPart_000_0108_01D5B987.0AD432E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Ace <ace-bounces@ietf.org> On Behalf Of Seitz = Ludwig
Sent: Sunday, December 22, 2019 11:52 PM
To: = 'elwynd' <elwynd@folly.org.uk>; Ludwig Seitz = <ludwig_seitz@gmx.de>; Elwyn Davies <elwynd@dial.pipex.com>; = gen-art@ietf.org
Cc: last-call@ietf.org; = draft-ietf-ace-oauth-params.all@ietf.org; = ace@ietf.org
Subject: Re: [Ace] [Gen-art] Genart last call = review of = draft-ietf-ace-oauth-params-06

 

Hello Elwyn,

 

Sorry for being a pain. I have one more = comment.

 

/Ludwig (now finally from the corporate = account)

 

From:<= /b> = elwynd <elwynd@folly.org.uk> =
Sent: den 22 december 2019 19:27
To: Ludwig Seitz = <ludwig_seitz@gmx.de>; = Elwyn Davies <elwynd@dial.pipex.com>; gen-art@ietf.org
Cc: last-call@ietf.org; draft-ietf-ace-o= auth-params.all@ietf.org; ace@ietf.org
Subject: Re: = [Gen-art] [Ace] Genart last call review of = draft-ietf-ace-oauth-params-06

 

Hi, = Ludwig.

 

Having had another look at section 3.1 of = draft-ietf-ace-cwt-proof-of-possession, technically the rules about = which keys have to be present are not part of the syntax of the cnf = claim.  The point can be covered by changing '"syntax of the = 'cnf' claim"

to = "syntax and semantics of the 'cnf' = claim"

in each = case.

 

[LS] Ok. Will do.

 

However, the second look threw up another point:  = Figure 2 in s3.2 gives a Symetric key example  - I think this = should use an Encrypted_COSE_Key (or Encrypted_COSE_Key0) as described = in section 3.3 of = draft-ietf-ace-cwt-proof-of-possession.

 

[LS] Figure 2 in 3.2 gives an example of a AS response to a client = requesting an access token. As per the requirements from = draft-ietf-ace-oauth-authz, this communication MUST be confidentiality = protected, therefore it is unnecessary to additionally encrypt the = COSE_Key.

The provisions in 3.3 of draft-ietf-ace-cwt-proof-of-possession are for = access tokens in CWT format, containing a symmetric key, that are not = encrypted themselves (i.e. only MAC:ed or = signed).

 

[JLS] I tend = to agree with not doing the encryption in the example.=C2=A0 The = encryption is not required as protection could be done elsewhere and = having an example that people can read increases the usability of the = example.

 

Jim

 

 

Otherwise I = think we are done.

 

Eventually we will get to = Christmas!  

 

[LS] I promise to leave it be over the = holidays.

------=_NextPart_000_0108_01D5B987.0AD432E0-- From nobody Mon Dec 23 13:32:47 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBD1201DB for ; Mon, 23 Dec 2019 13:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com 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 ZXeS8RRaImdc for ; Mon, 23 Dec 2019 13:32:44 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 DC24C120043 for ; Mon, 23 Dec 2019 13:32:43 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id v201so13610280lfa.11 for ; Mon, 23 Dec 2019 13:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fiTwlEjaVD0YoVtNbrIVL0N8M/0BAqK84c8oSmI7dxQ=; b=Izqir33qowcQZGPOG1k9g7tNAG/293yiZA+Kg67DslTNl4OOVh8PbUJ3yjvL/Kvi+g 4GB2WqezkZndYxro6dZO1C5x0/hHy9V0g447Wn6UMuPpC9n8kOlEK5yyULxTt4/P1P6W oYuxK+5m2tSzNXcjQUzjly8lQWTucHoNs+Ww8CwB/EbAsmYeRJFY01vshUyGcddck4dr WLjzCPdjkpDn1Cr1RnZW4IrHRpCzmMBoT0pO72IkUUM5SLrkx6AcYj10ozwxAFbLzSn3 91aorW6JuTtJ/45u9Rwwz+FJQBjUSbf/BYj2hcDsHewNG9PKkGgwwjQT/Pju2CMsqbig GT+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fiTwlEjaVD0YoVtNbrIVL0N8M/0BAqK84c8oSmI7dxQ=; b=Ya56VoQ7AwrpkSlnIzomeNC7ecLkc6GtXZ2fGw8mWNkFCBf/RPpqRk/S0so+fc7sNu 2YS5HmnfQ++6Iqc81mrCBE4YDo866I1AVrzZKRVf+MlB+uaNxuopkv5qFFnmk3QVPEX4 4F/Ux9vvN8Qi63vRCU/0KCdOV4KiVGgpEko9EgHHhCxY/6QjkwSzk9HwqlXTnJJGdvsT j/cT6rkWotTMAHAHzYBQVyY5kysr+Usml8/kMjIGEhgCjDujxwobljDNrTx/NzDBsWIJ 92WXxYpbqYPOpxbS1Oo/dyrwR6Vuu2YHAnbE09dqaZxPKF4P+eWvAUc9bv2HoW5o6/JA il1A== X-Gm-Message-State: APjAAAVYFcNJNWzrYZrTWkTd3Blod8QqWdYU1yfIA7RxsJc/SON40oGY 6EBvEPv3SQqA5XfG0UPeFQt6JWfJL4DlUXbT5BawLzPnriiZwqY8DCP/Rb1ik17vbsbOfN4+ySx /MhdT3+6u4xA= X-Google-Smtp-Source: APXvYqyIz+RQHqv1WKCsq0BhXG9rwaTN3K8oYZ5l5CJohr+20QZIO84FA7DtRW3ehEQCwCSwDmQrEReA0QgQPIHib54= X-Received: by 2002:ac2:44d9:: with SMTP id d25mr18711436lfm.15.1577136762012; Mon, 23 Dec 2019 13:32:42 -0800 (PST) MIME-Version: 1.0 References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> In-Reply-To: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> From: Brian Campbell Date: Mon, 23 Dec 2019 14:32:15 -0700 Message-ID: To: Ludwig Seitz Cc: oauth-ext-review@ietf.org, Roman Danyliw , Daniel Migault , Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , drafts-lastcall@iana.org Content-Type: multipart/alternative; boundary="0000000000007698ea059a65c40e" Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org 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, 23 Dec 2019 21:32:46 -0000 --0000000000007698ea059a65c40e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The OAuth Token Introspection Response registry already has an entry for "cnf", which makes the first request in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4 rather problematic. On Sat, Dec 21, 2019 at 4:19 AM Ludwig Seitz wrote: > Hello OAuth registry reviewers, > > the IESG-designated experts for the OAuth parameters registry have asked > me to send a review request to you about the OAuth parameters registered > here: > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.3 > > and the OAuth introspection response parameters registered here: > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4 > > Thank you in advance for you review comments. > > Regards, > > Ludwig > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000007698ea059a65c40e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Dec 21, 2019 at 4:19 AM Ludwig Seitz <ludwig_seitz@gmx.de> wrote:
Hello OAuth registry reviewers,

the IESG-designated experts for the OAuth parameters registry have asked me to send a review request to you about the OAuth parameters registered here:

https://tools.ietf.org/html/dr= aft-ietf-ace-oauth-params-07#section-9.3

and the OAuth introspection response parameters registered here:

https://tools.ietf.org/html/dr= aft-ietf-ace-oauth-params-07#section-9.4

Thank you in advance for you review comments.

Regards,

Ludwig

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000007698ea059a65c40e-- From nobody Tue Dec 24 06:50:54 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69696120106; Tue, 24 Dec 2019 06:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lSLQE/9p; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=jtF9GPae 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 2pquiuBdceo1; Tue, 24 Dec 2019 06:50:50 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82961200F7; Tue, 24 Dec 2019 06:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10039; q=dns/txt; s=iport; t=1577199049; x=1578408649; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y0R5kp4TSQbGWU4H4VFQ7K89wC3tXsafEKK9XEu6KcM=; b=lSLQE/9ptYJ1y+6pE1xt7HjQcTWSSjaT3yN/3rkVHD0ETFdMwJv/5AeA K2bo++fm466cMxWBU3JohqFOOdfXNNcO+4cEou2fyLoqiXaVOAl+s50rI zl2HrkgBg7C0dEhno33D1qVuxcgqKlRNgMUKX1Qg7wIOVj2g0kT4waA4E Y=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AN0jYmxTjPiXMoCqXWMZ8SISsTdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQ5FcFaXVls13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7BQD1JAJe/5pdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBUiQsBWwrLSAECyqHTgOKeYJfmAiCUgNSAQECBwEBAQkDAQE?= =?us-ascii?q?YDQgCAQGEQAKCHyQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBEC4BASw?= =?us-ascii?q?LAQsCAgIBCBEEAQEBJwcCGQwLFAkIAgQBDQUIBhSDAYF5TQMfDwECDKBzAoE?= =?us-ascii?q?4iCFAgieCfgEBBYE1AYNLGIIFBwMGBYExgVOIKYIdGoFBP4EPAkeCTD6CZAE?= =?us-ascii?q?BAoFLGBWDK4IsjUmJTZd+CoI0g2GCN4EbjwGaV45SiFKSBAIEAgQFAg4BAQW?= =?us-ascii?q?BaSIqgS5wFTuCbFAYDY0SOIM7hRSFP3QBAYEmkDkBAQ?= X-IronPort-AV: E=Sophos;i="5.69,351,1571702400"; d="p7s'?scan'208";a="686538306" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2019 14:50:48 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xBOEom41006545 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Dec 2019 14:50:48 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 08:50:47 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:50:46 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Dec 2019 09:50:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nve3Om1HkSRwOW615lB9i5ru33d+CzV8MyFU+W2Zzge4vG26a9I6WAb9D41buztjc8z7OKjtj1Ha6429xNahQ2l6FwaJKmuGfD0I2NRXK/UIoHZqovEMzS/y98iLjCGiBp5jCGdV0cM+jW112Z0yVmtbklQrQoGoKUps37hgR2jm5XZouaZ3S9+JhllJcURdnwPxElXsHNC10gz6RLejdtic6hGjGTFOuKMX/kriRp38qGGHCYHn73rrfrVKv6o/pNXMJmjZczS0jWOXlnFgd7NodRM4R1xnE9CeyPT0g3ypmgEIyx/BUg7lSdiJ33MvMz8jvrUE5d5X0xeLgEP5nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NJVzkzSR+TlGmcTrnhO5Jzf5D+DYW8d5N5O7VR+49cY=; b=auSXCPlpM0DbRK/HCA/gC9gTRjpdJdm+oNrpkr0nIDFaK0VYFpFEcxixviwITh6JPHuyNGYav/lasxpXvNoq/xrNwGj+vLDakpM5eq+c+7kJaoedoGPiiBicceJMhN1LpqilEBR1AtTQ3wv+FTvdl/r+buO8qRqCSu/mcNDEB5lXeFSFUG8PilHKgW9OTCfpyY9hNdkTaCka32lvKykdN6bUp6W9Un2YfGZ343fXJqkQC8HbhnaMQm+vMLsfEhNl31j1GxWoxGjawph7a6Ezo9UfudFO2qYowc4L8/dj0M6R6rpG+hOn/H83b2Sgc5KhDSXUJFbyh0SZTFh/m/C4Bw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NJVzkzSR+TlGmcTrnhO5Jzf5D+DYW8d5N5O7VR+49cY=; b=jtF9GPae6criFG3ot7yCo8cSTBUJ/D5iucxw2ND36qg6poYdAHw4MWPRrn+zJNqrKMOMu4eX7jo20NMmvFhAyITmX4CGl5B9PkdEqvJ8C0AaQdrKGK26SVmnPkjm88UseL5AO/Lm82U+rSoH9JBqe4R1W1/44RFzH1W//IeUJ0I= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2579.namprd11.prod.outlook.com (52.135.253.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Tue, 24 Dec 2019 14:49:29 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Tue, 24 Dec 2019 14:49:29 +0000 From: "Panos Kampanakis (pkampana)" To: Magnus Westerlund , "iesg@ietf.org" CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Thread-Index: AQHVtmteNYW1qV2WE0en9EAnACcqDKfCd2YggABM1wCAAHy84IAGJIqA Date: Tue, 24 Dec 2019 14:49:27 +0000 Message-ID: References: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::215] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d6c66459-f8bf-4823-581e-08d788807a96 x-ms-traffictypediagnostic: BN7PR11MB2579: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(346002)(39860400002)(396003)(376002)(366004)(136003)(189003)(199004)(13464003)(64756008)(33656002)(966005)(2906002)(478600001)(66616009)(66946007)(66476007)(76116006)(66446008)(66556008)(55016002)(71200400001)(9686003)(86362001)(52536014)(4001150100001)(53546011)(186003)(6506007)(5660300002)(8676002)(81156014)(7696005)(4326008)(8936002)(81166006)(316002)(54906003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2579; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +/1g+amnUDPyJBZB2n00KeyGO9vbClbHQIv4e93XWF4vX9TLvU5UkcfOmIZ+5Y3S8tjYBndE7oHqS0cRBt/3p3d4n690h7XZnfCuLM2DdatXDeiK1SHhdn+vPfoXdlQrw2abeh8gTTGF9rlhvRkxbCVM1KxNAF9T9nlLF9W6D8ONgR4mC4o82wlyodLIchPi2EqA3CnFVzs3YVFAV2WJyQOQeAvAFoMiWcXkcG4yY4UWbf2TIKjN1qNy23vNSJiYAh4wyjvP0L4qyU9NvzFEEKPqOPlfT543XBDwPjZ5L+DLp30nwZRLymEluDmXGVaiPAKKYhPg+TQGu58fshQSOKSV76corJy6h+fS3umNeOwqRdCB9ca0YTcZ9hw/HiDJZ2y16Cn0+dLzhK4+OWjzQsdPbRL9Qj1VLCfGzdKhVxc0g914YUQaEZ3sGA99P9Pc31GtuXWBiwQ6GdWQY4FqVuThOG8fL7KuSqK2ZvpuJu02myz1dSfeJ7zaSRU4kOSm2GOMqbq6cpX8Gc5xfBktFsRjShUDacje2Rd459vGWXUBnG4jteeH49cBcqlAz2Ecg8dia7jJI3gF7pcZKn4EwfHcZ2S2onCL42x8z0EeEUs= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0033_01D5BA3F.6CF2DFE0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d6c66459-f8bf-4823-581e-08d788807a96 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2019 14:49:28.6791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5dr8gK0Ade9vMAYmdXemO3p8jFNeUR1UZHNRWsgo7pgWCH/Oyd0pUbxLbrXNDvHRqrInFacK7vbyNyzu5a7Bbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2579 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) X-BeenThere: ace@ietf.org 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, 24 Dec 2019 14:50:52 -0000 ------=_NextPart_000_0033_01D5BA3F.6CF2DFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Magnus, This commit https://github.com/SanKumar2015/EST-coaps/commit/37f6337a3b389632c18b77d3c4d b8f28aabe9b63 tries to address your feedback. Let us know if it does not make sense. Rgs, Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Friday, December 20, 2019 12:19 PM To: Magnus Westerlund ; iesg@ietf.org Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Hi Magnus, I see your point about the confusion the word "support" could cause. Our intention was to make Block1 and Block2 MTI for the server, Block2 MTI for the client and Block1 optional to implement for the client only if it needs it. RFC7959 says " Implementation of either Block option is intended to be optional. ". So, I think it makes more sense to replicate this language instead of support. We will use "implement" in place of "support" in our draft. Regarding what happens if a client wants to send a large request and it has not implemented Block 1, I don't think we should define that in our draft. RFC7959 says when you see a Block message you MUST process it or reject the message. It does not mandate what the sender application does if it has a large message and does not have COAP Blocks implemented. The right behavior in this case is to depend on the lower layer protocol. So if COAP does not support it, then IP. I do not think we should interfere with that in our draft, it falls in general TCP/IP layering. Does the above sound reasonable? Panos -----Original Message----- From: Ace On Behalf Of Magnus Westerlund Sent: Friday, December 20, 2019 4:34 AM To: iesg@ietf.org; Panos Kampanakis (pkampana) Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Hi, On Fri, 2019-12-20 at 05:01 +0000, Panos Kampanakis (pkampana) wrote: > Thanks Magnus. > > > The EST-coaps client MUST support > > Block1 only if it sends EST-coaps requests with an IP packet size > > that exceeds the Path MTU. > > > > I think the requirement for when Block1 is required to be supported > > in the above sentence is unclear. Is the intention to say: An > > EST-coaps MUST support > > block1 to be capable to send requests that would otherwise result in > > the reliance on IP level fragmentation? > > Yes, that was the intention. We will rephrase it to say > > [...] The EST-coaps client MUST support > Block1 only if it sends large EST-coaps requests that would > otherwise result to IP layer fragmentation. > Is it support or use block1 when the request is to big? I think the combination of support and only results in uncertainty towards what the implementor. Based on this reformulation I have the impression you want to make the implementation optional if the expected EST-coaps request size is less than what the IP MTU can send without fragmentation. However, that leads me to ask what is the behavior of a node that suddenly are faced with a request that is larger. Refuse to send it with an error or still rely on IP fragmentation? There is always the potential for a request being to large unless implementation support of block1 is mandated. Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0033_01D5BA3F.6CF2DFE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI0MTQ0OTI1WjAvBgkqhkiG9w0BCQQxIgQgMJRaRmE7aLgRrEFRilziHgci1Y0xWCH4 HQ/+xvTFVGcwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA Z9EqguZQXr2APINhMldjT3S++lW+UpPzClXnMPq/n+lFesKrmUJgDpXC2Jj6R/cV6nN3lHmTQyWE gyNNhhFjt+7fCvqG+tEeCh347Og/M7CgfwUowC80r2DSS1Sw2dtS0o02ZF5fIfP4JGfz/QZg5IQm fJPU4lwFOxE9hB/z62uYI7S/zUPj5A0wa97FuURydTT1RxRf5GnPajbJ7gRyFY+r7NuoHN6tNXaY c/xRsi8EYC2SYl3a043nfKL8EZKbcHH/diBvC52ozO1gH6aK+2Y103QP33NWz0eHx3VD8m2TdSN1 nu8L76XgNjER+CWtejZ6tsO9RddqyJ4tSEjcwgAAAAAAAA== ------=_NextPart_000_0033_01D5BA3F.6CF2DFE0-- From nobody Tue Dec 24 07:42:39 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934751200B8; Tue, 24 Dec 2019 07:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QmafbKGF; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=nZH3cbDP 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 IlPxsbyZK3Sz; Tue, 24 Dec 2019 07:42:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96E81200A4; Tue, 24 Dec 2019 07:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11610; q=dns/txt; s=iport; t=1577202153; x=1578411753; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4vlPi0y+8skscfl+SKBA1sF5ofAZxDDI+QjZbfPsWbc=; b=QmafbKGFyKm2okSDob8MOCRIzofXlCyJSxHp5eMSnu48mE0I7GRcuAI4 CCmE1qpZcehYLr0lBS4vOc/HVrc3xwoRLGfvYS0pj7AJhpKofsxCkbnFH 0ZyNpPhZ85/nZuv5koOcNo51UK2ppcUQT1Y8TFzCvom3UDhTM++X/vMYb c=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AsxyddRK4VrxJ92hVJNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+BQCGMAJe/4YNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBUlAFbCstIAQLKoQIg0YDinmCX5gIgUKBEANUAgcBAQEJAwE?= =?us-ascii?q?BGA0IAgEBhEACgh8kOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQMBARARHQE?= =?us-ascii?q?BLAsBCwQCAQYCDgMEAQErAgICJQsdCAIEAQ0FCAYUgwGBeU0DHw8BAgyQGZB?= =?us-ascii?q?kAoE4iGF1gTKCfgEBBYE1ARNBgnYYggUHAwaBNoFTiikdGoFBP4ERR4JMPoJ?= =?us-ascii?q?kAQEBAgGBLAESAQkYFRuCXjKCLI09DIJxiBmWQQqCNINhgjeBG48BgkaHe44?= =?us-ascii?q?xgWWOUohSkgQCBAIEBQIOAQEFgWkiZ1gRCHAVO4JsUBgNjRI4gzuFFIU/dAE?= =?us-ascii?q?JgR6NdhEXAoE6XwEB?= X-IronPort-AV: E=Sophos;i="5.69,351,1571702400"; d="p7s'?scan'208";a="686560301" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2019 15:42:32 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xBOFgWgc017896 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Dec 2019 15:42:32 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:42:31 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:42:31 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Dec 2019 09:42:31 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VIzzSZmHVgQmLHhySTiXUxIG4QRgmwquWpWGqGMXItLHbNLNpfGvxdzURgxqsMzpvXWAYff33Cc3zzNb/uGvfoipXmuNkTIzVpVldOfyXiVBeV0tQDwVpkNyWuBe1ZPYwBVDBcuXgQV6xoPiJcxcJhkjM3HF+m8wPp0kaBLLHYCGNedKwP5XT3lga0YZPRk8IEw9JrUCx97eEXxH1pQK6+SsUNUqLJP0OQh+AwcHhreplsAeXbrfOaAWSXoBmBe8DpNT3HzMDVmoARtn+fXiEGDT70+TIH8mp6JZ0ZDCzlmYegi7ix9YC9Pq4A/FWxb2+qpiVgH4Gu45qnsGciTm3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LVS35xZex7sioLPrMUMWxn6L+LXN1tr7cpjwvAPDc4=; b=YoOmLlWblprGC2Y/YiHQce7M5EYlVSegvPIbVau/TpeL43EaSrt0Y2RDU/DC7lFn6QR2hFV0t/osyH8p599dgT7U2xmh4r9ZZKV6CxKFw8GBAahkyezr1G1IQ60W0OUyqA1Wa/uuQ6y1hhTvv8KNkkMJuQ5Yp+rkRm9xdGWegaquuVD9wxTOxxgsT7nrfbbgol2MlEIuQeeBQS8s0LceOVk1TmoWmkpO3Y03BePJTUuLX/6INYuWLHzb6LBMcxL04VDthYukcENZrbscCgEMYcv9Kv9B7Imxgdbx3cRWdFszXTbwYY4tK76JKAIVY0YXgYRfUAHgbnVEzB2cLB7nHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LVS35xZex7sioLPrMUMWxn6L+LXN1tr7cpjwvAPDc4=; b=nZH3cbDPBn9o0f5YZNw1Fbh+iXV1nIJ4xT1SF7bEfFpp+GMePDbhWiMelVnrqY3JqsPNQw3p864mcZ4XC4h92b5U+y6EyJKgKM+p2MPbRHh7Su8w2GtdXOUI4/nJdPZNLVEANztZ3+jZuLlPPizksPcqV7hH6ZuWt2/1fenJcd4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2643.namprd11.prod.outlook.com (52.135.245.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Tue, 24 Dec 2019 15:42:29 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Tue, 24 Dec 2019 15:42:29 +0000 From: "Panos Kampanakis (pkampana)" To: Roman Danyliw , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Thread-Index: AQHVtFyGFe5/PrA9gkyvssXlx+7u4afHLUWwgAJIMVA= Date: Tue, 24 Dec 2019 15:42:29 +0000 Message-ID: References: <157653372668.24465.13819182999807823012.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::215] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59474af3-037e-480f-acdd-08d78887e295 x-ms-traffictypediagnostic: BN7PR11MB2643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(366004)(136003)(39860400002)(376002)(396003)(346002)(13464003)(189003)(199004)(966005)(66946007)(64756008)(52536014)(33656002)(76116006)(55016002)(66556008)(66616009)(66476007)(66446008)(186003)(9686003)(110136005)(81156014)(54906003)(81166006)(53546011)(6506007)(5660300002)(316002)(71200400001)(8936002)(4326008)(8676002)(7696005)(2906002)(478600001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2643; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CztHrhoOfRUJbfn5f4ptaAcaoHGtVufIgpJtOn7b2knqaHKV22DOh3I/UXG2BeF0oLNUEWvZ5yx8iyEVMLeQsu5/5hJ9EebTqtEONObpkp5OTSU8HwpdSXtZMh8D4lSGuC8k/zqUEKWfp0utj+4TprrpgT1/148mHKoIgjJjUwdRrenN3xiJvv+qZmHw/3Z1JGjhIeOp70IepLC75L9tAl5vl48X99otJfwcd5rfiPVwWJJ86vBqyBhmTTuoSdUPTjEWsRCQgozQJ1LhughvDGqdUZ/pEBGQ0xAlq3GN0wLVJEiepUQyujn0VsFv8DWr0PWVrqt/UEXqS6MTN1GtbyFnCHHMYsiD+nTczP5Zq9NrTgBHNRLEyIeWftPzZ4nz7NRSAr0s8EB53cJdoOsKiNvZWXkfPUnBq00oljrjcB5yE2ESfJCeQ7YlYWyj0+lhSoOYmEagza3y1ElqHKyAjL6AEVZBOaTx34oz4Tww9WUXwNqK5M5fRilXlcZQAirNANeagTV0Pisr7cbkHx6zI8rPpB2fw+n1NAW+17aX4xQrkszn3IT0iG1nNA+qqdwFX2Fb+vtXeqXPQ9wHCTAvSVQY9TsEVlRMcc+0hmmoz3Y= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_004A_01D5BA46.D62629C0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 59474af3-037e-480f-acdd-08d78887e295 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2019 15:42:29.8257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c82G/4l0bgH7QDnoIAm/xjJPg2NIxgBHQ0WMYdWEOApx/SwTHIUoD+YXqHttW2TPkUpGV25qUjw2rzdc4o1boA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2643 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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, 24 Dec 2019 15:42:37 -0000 ------=_NextPart_000_004A_01D5BA46.D62629C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Roman,=20 This commit = https://github.com/SanKumar2015/EST-coaps/commit/222879c5d8fab836a7cb1d35= cb128821ca790370 tries to address your feedback. The full discussion is = in https://github.com/SanKumar2015/EST-coaps/issues/154=20 Let us know if it does not make sense.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis = (pkampana) Sent: Sunday, December 22, 2019 11:41 PM To: Roman Danyliw ; The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: Re: [Ace] Roman Danyliw's No Objection on = draft-ietf-ace-coap-est-17: (with COMMENT) Hi Roman, Thank you for the thorough review.=20 Please check the response to your feedback in = https://github.com/SanKumar2015/EST-coaps/issues/154 There we include = the fixes we will make and our thoughts on a couple of your comments.=20 Please let us know if you have any further objections. Panos -----Original Message----- From: Ace On Behalf Of Roman Danyliw via = Datatracker Sent: Monday, December 16, 2019 5:02 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Roman Danyliw's No Objection on = draft-ietf-ace-coap-est-17: (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 4. Per =E2=80=9Cthe DTLS connections SHOULD only be kept = alive for EST messages that are relatively close to each other=E2=80=9D, = I think the text means that some EST messages are more likely to occur = one after another. It would be worth being clearer what these would be. * Section 5.1. Per =E2=80=9CThese URIs are shorter than the ones in = [RFC7030]=E2=80=9D, does Table 1 imply that when using EST-coaps the = =E2=80=9Clonger names=E2=80=9D from RFC7030 wouldn=E2=80=99t be valid? * Section 5.2 Per =E2=80=9CThe latter ones are deemed to expensive = =E2=80=A6=E2=80=9D, was difficult to parse as the sentence prior has = three things (instead of two). Is this sentence referring to the = =E2=80=9Cnot specified functions=E2=80=9D only? * Section 5.3, Per =E2=80=9C30% smaller payload for DER-encoded = ASN.1=E2=80=9D, if you can cite this metric, please do. * Section 5.8. Per =E2=80=9CIn summary, the symmetrically encrypted key = is included in the encryptedKey attribute in a KEKRecipientInfo = structure=E2=80=9D, if this is done in a server-side key generation = scenario, where is the client getting the key to decrypt the server = computed key material? Should the DecryptKeyIdentifier/ = AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per = Sections 4.4.1.1/4.4.1.2 of RFC7030? * Section 10.1. Per =E2=80=9CWhen server-side key generation is used, = the constrained device depends on the server to generate the private key = randomly, but it still needs locally generated random numbers for use in = security protocols, as explained in Section 12 of [RFC7925].=E2=80=9D, = is the =E2=80=9Csecurity protocols=E2=80=9D referenced here anything = beyond DTLS? * Section 10.1. Per =E2=80=9CIn such occasions, checking the = certificate revocation status or authorizing the client using another = method is important for the server to ensure that the client is to be = trusted.=E2=80=9D -- does this text suggest that expired+revoked certificates should not = be used? -- to word-smith: s/for the server to ensure that the client is to be trusted/for the = server to raise its confidence that the client can be trusted/ * Section 10.1. Per =E2=80=9CMore information about recommendations of = TLS and DTLS are included in [BCP195]=E2=80=9D, thanks for referencing BCP195. = Could you please clarify with normative language if these recommendations SHOULD/MUST be = followed? * Editorial - Section 4. Per =E2=80=9CAuthenticating and negotiating DTLS keys = requires resources on low- end endpoints and consumes valuable = bandwidth=E2=80=9D, I=E2=80=99m not sure this sentence is needed. = Technically, =E2=80=9Cauthenticating and negotiating DTLS keys requires = resources=E2=80=9D on any endpoint. - Section 4. OLD: Given that after a successful enrollment, it is more likely that a = new EST transaction will take place after a significant amount of time, = NEW: Given that after a successful enrollment, it is more likely that a = new EST transaction will not take place for a significant amount of = time, - Section 5.5. Typo. s/successfull/successful/ - Section 5.8. s/Such scenarios could be when it is =E2=80=A6/Such = scenarios apply when it is =E2=80=A6/ - Section 5.8. s/ client, or when the resources/client, when the = resources/ - Section 5.8. s/Then the private key/The private key/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_004A_01D5BA46.D62629C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI0MTU0MjI4WjAvBgkqhkiG9w0BCQQxIgQgpdpw4Ks9qFe9g9ywRuVf5MO1aSIhPKef 0xU9OKxLNCYwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA Gk1bVPpE7VRBLXFLUad08DkKk7DgcudL5dukgAvIW+nfrfb07090zqLOxxYU+aTRfdNVikyGzIrw LE4J2I17Dl+y2GYP2p/ozdNTYjZl5TrGh4Nh5H+HZXCutX39nFesTKJ2V4NWrThavQYwLVlvZBy4 zIKvPWQlq3qbzp2adTU2t/BmdK/lAVd8YT6A1+KMqnsRwq5tnaFra8kfDX4yn7xNB/6c8+7pONHp 12ggZE5/Jyzpi3u7zzGV+1l9hALv7ObDjU1+FVzVy3uai6iwKdYQpdwfXksjMWz0ShhBvVhrvie9 cmku7oMEj9cxakIlKCVv7Bozm214+ymXHGfrFwAAAAAAAA== ------=_NextPart_000_004A_01D5BA46.D62629C0-- From nobody Tue Dec 24 07:46:29 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DFA120154; Tue, 24 Dec 2019 07:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KBeQkNuU; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=PHtUKyT/ 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 uBa6mjqFt9Rr; Tue, 24 Dec 2019 07:46:18 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C4D120180; Tue, 24 Dec 2019 07:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9548; q=dns/txt; s=iport; t=1577202378; x=1578411978; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=epfZsuK4VGH21TeLwh7eV/4B6auoU/gNqpGU7SfgGms=; b=KBeQkNuUrsXmovEF66HlhrTKsuIXMOFqxde2ClmnI6HxKVsC/f8XZeZS NY3nGsVc4NtfLVvbt9KiVyMRlot5QvceWtQI6N25YwhjKe1Vcgsa7INMj 1dQ3bMqqd3oScQCC4GBAxWxRxAhmUA1m54H+/14amL9u3rPtHL4ckg//s w=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AXJyH/BYV5tzPD6LJdMGU1ov/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5CACWMQJe/4YNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYF8gVIkLAVsKy0gBAsqh04DinmCX5gIgUKBEANUAgcBAQEJAwEBGA0IAgE?= =?us-ascii?q?BhEACgh8kOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQMBARAuAQEsCwELBAI?= =?us-ascii?q?BCBEEAQEvAiULHQgCBAENBQgGFIMBgXlNAx8PAQIMoHcCgTiIYYIngn4BAQW?= =?us-ascii?q?BNQETQYJ2GIIFBwMGgTaBU4pGGoFBP4ERR4JMPoJkAQEBAgGBLAESAQkYFYM?= =?us-ascii?q?rgiyNJSSJTZd+CoI0g2GCN4EbjwGCRod7kBaOUohSkgQCBAIEBQIOAQEFgWk?= =?us-ascii?q?iRCNYEQhwFTuCbFAYDY0SOIM7hRSFP3QBgSeOB4IyAQE?= X-IronPort-AV: E=Sophos;i="5.69,351,1571702400"; d="p7s'?scan'208";a="389735868" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2019 15:46:17 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xBOFkHtB022978 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Dec 2019 15:46:17 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:46:16 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:46:15 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Dec 2019 10:46:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aF/6UUK0XhTzXD68vUqIxgMyKDvGxYcxW9OMs2e0eRY+zOAQAdjaRpp3TR/6y+M6xHRFyAikFWxtl7z+DVJZrWjCOIAuCyDy+wUvlwewDOAo9Fq4tWf2x4kAXKhnHVY3f4pzLT8VXnHp0/Hb19IaxaL2/uVWQpy/PSO5b73zVTtIXTKK7bVUbZmyluIYD8oUvtZxhnhRjLYVlbdKpRrg93qrhYDqbpbZ2JwwM3qpqwfN2/mHKMEuRKYZfV4A73PXLLorpreoqrCDiF/c54B+75iPhfZ0R2EEG0LoD6oGi2Wqrol9qxk9g531RTgsVa67pe0fdKe6+nGmqCvIM7bCSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rdLBYRhN8SXAtt6L7e55eBtx3B+V6o0Yl4sf6suS9SI=; b=OY+5BdIVCfvvKW3tkSktG5EBbO++hweiacRBPb4JU8axVjGe5SpPmX2O2fIuR6OjQllbN3kz5WDNKAvaHtycze7MOmpPTZp918QBXX3rUP6liAe8m9S0mJukn4/JZHlx1Ya9QwBqFj2cPuwsiBDsYvKGmXaAmCeE2VyFZFz0XL+09qpsnrpz/5FOQGsQ2iZHWwBhp/a35hErYnzZE57kRtPpUAeS5MfVu7lMs7R5vAA85vVYXxXKPzsrlDf8JUD0sNbiIng5mHDLs1kf51TCY5yW19h+xxnaGgnDH12laAl4rLzJxDNwgqhQcU4rN18Rvin6bKNPtbodCbI/d/Lj4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rdLBYRhN8SXAtt6L7e55eBtx3B+V6o0Yl4sf6suS9SI=; b=PHtUKyT/Umrf5tCxopW+DOL+2ZSZN5afgfS9tmKoXSae4q0f3rBX7QoYO8e8Fp+DkNf5nBziPOI/2U6mVuN4KXhJSu5lKDFbUBletnuJQrfJw8SyIpXt/xYV0xt7QNhDARy1FaYovltWq8QrSQpO46fDBKzAPYn49wTJFWL+4Qg= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2580.namprd11.prod.outlook.com (52.135.246.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Tue, 24 Dec 2019 15:46:15 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Tue, 24 Dec 2019 15:46:14 +0000 From: "Panos Kampanakis (pkampana)" To: Alissa Cooper , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Thread-Index: AQHVtREze2mzYAiIIU2GJp/gU3IOXqfCdYQQgAcCmjA= Date: Tue, 24 Dec 2019 15:46:14 +0000 Message-ID: References: <157661132422.26387.11388034337323397614.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::215] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06684f32-df24-4cdb-c38e-08d7888868a8 x-ms-traffictypediagnostic: BN7PR11MB2580: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(366004)(39860400002)(396003)(376002)(346002)(136003)(199004)(189003)(13464003)(316002)(5660300002)(2906002)(54906003)(110136005)(71200400001)(52536014)(4326008)(966005)(81156014)(81166006)(33656002)(55016002)(9686003)(8936002)(7696005)(66946007)(66446008)(76116006)(66476007)(66556008)(66616009)(64756008)(86362001)(6506007)(53546011)(186003)(478600001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2580; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ERvvA9cDkdybbkfCIH9PtsGlsO3dn8UYW49027HZXq66bMdvyVpwCDEMt0jqaUVr9KuJuQ3d8gTF9vMncA6phpj1EJM3/4NkrnE03My7ipioY/00cduGCG5zRXMWEfdHudOFkwcImHGdHAd969Ko2TjoeiMV7blv3EE//3p6dZgltCBMMksaEFTX7zLn+PyElAYWqXyk9z4r37uK1amdvsldRZRZJYJxMXxnBL7ggY7xqYwiLtTJct6zD19YPjWebI41Ogsm4wKGLEb3HAyBKxfHsjQqfhkb+RxnWwWBn/y4JRT1tCVof6clMqBO0mBRb3l5tdnRa7opkBSBVI4NZumDobg3WuGo5frSqDu4qodvuSJIeDuulydPC9Cgso8vxVeKjgRR/K2E1keYGYu/yzdCp5SJISyDC2Td2KUlIKt79GGmF1gfQsHfRG5O4Myyxzv4dQdElPKTbhg4eV5gzNrV72oL7Wt1ybawgfYmYlZqT4RXPzhGQKLmAjI49pZf7xmzjyL1YqJXp5IbuDkGQE51/OC9UEUTxFAHM3o/R/WeCR3oik7untUvgZ0q7xQAR+U9SUqZUa5eRTzOMXCupreqs+LkWcz5oHgv1eHcfZQ= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0058_01D5BA47.5C363B40" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06684f32-df24-4cdb-c38e-08d7888868a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2019 15:46:14.6946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xTH4h9cRnLeucILLtAAne4Dn0CtkKzYMORcGHjWTtrAlu8ZvEi5Ua9IR3RwANmD4p8T5SXYo1F1bW6EqjeEGjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2580 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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, 24 Dec 2019 15:46:22 -0000 ------=_NextPart_000_0058_01D5BA47.5C363B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alissa This commit https://github.com/SanKumar2015/EST-coaps/commit/a45eda375f4b228b4bcb29e142e 393cddbaa4e6a tries to address your feedback. The full discussion is in https://github.com/SanKumar2015/EST-coaps/issues/157 Let us know if it does not make sense. Rgs, Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Thursday, December 19, 2019 11:50 PM To: Alissa Cooper ; The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: Re: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Hi Alissa, Thank you for the feedback. > "It is also RECOMMENDED that the Implicit Trust Anchor database used > for EST server authentication is carefully managed to reduce the > chance of a third-party CA with poor certification practices > jeopardizing authentication." > > This strikes me as a slightly odd use of normative language (what are the exception cases when the trust anchor database should not be carefully managed?). > The blurb is directly from RFC7030. We reiterate it here to point it out as a best practice and then we present a potential deviation from it for constrained environments. To avoid this confusion we can rephrase it as As discussed in Section 6 of [RFC7030], it is "RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication. Disabling the Implicit Trust Anchor database after successfully receiving the Distribution of CA certificates response (Section 4.1.3 of [RFC7030]) limits any risk to the first DTLS exchange." [...] Rgs, Panos -----Original Message----- From: Ace On Behalf Of Alissa Cooper via Datatracker Sent: Tuesday, December 17, 2019 2:35 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Alissa Cooper's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 10.1: "It is also RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication." This strikes me as a slightly odd use of normative language (what are the exception cases when the trust anchor database should not be carefully managed?). _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0058_01D5BA47.5C363B40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI0MTU0NjEyWjAvBgkqhkiG9w0BCQQxIgQgGRc8RcxsnpHKAL8HsC5Z7YTxcRHlFoZh H2UfQEv9+rIwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA JqSbSPcrjKAnZe/AoPyjgf8hNW4r0L6vbV19GsnpNDbDk260UW1udFv4I0JkKnE2zlgBG3qZna01 3f3COTTGkisHy2Wp0daUSwHmZhRStCeAj4P4vAXYubyJIBk/JTLFmQN2h/CpLrfwOPg29xZvuWY6 GYE1sSxILnf5cqA9C7OnCXBb5jv98F1JUV/wK566jn9M16hOgSnjtWPSRnQJSW6YaHQX2bSdSOC/ ENK8kz+s7W/ICLKjPfAfRVTZ8aCEwdhPbWTMkqQjS8OvwFybGfzDhWYRFUfFIVWi0pGTe6TJb/QH i98e2mIvCG5cWZ9qvvK7Wxp9Pgtau2zFB/iNMwAAAAAAAA== ------=_NextPart_000_0058_01D5BA47.5C363B40-- From nobody Tue Dec 24 07:47:05 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BFB120154; Tue, 24 Dec 2019 07:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DS+1dVfj; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=hik3BIXI 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 u-eukUudfD2L; Tue, 24 Dec 2019 07:47:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FAD12018B; Tue, 24 Dec 2019 07:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9467; q=dns/txt; s=iport; t=1577202420; x=1578412020; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nJ0K5IFGs6wmF0UEhWC5WjaHO4DEkpUOSK70kdjA9cc=; b=DS+1dVfjpbqFhSocFmgJ0KhCRAvdXkzW+24n0P+3BORNBXnmGM8llLyZ zHLndmtLyifqLGjAclgl5QuSSml+H+5ENC69YP0uiLDS6YFYHgEx1g6CP NdBLZv0plZrZSooX5czkHoGlmfxJcaMd16jpl2BAjqvK22ZbwY+CpxR55 c=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3A6DXAshYfxQC8ranNA+Tlh7T/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+BQBAMgJe/5RdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBUlAFbCstIAQLKoQIg0YDinmCX5gIgUKBEANUAgcBAQEJAwE?= =?us-ascii?q?BGA0IAgEBhEACgh8kOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBAQEQER0?= =?us-ascii?q?BASwLAQQHBAIBCBEEAQErAgICJQsdCAIEAQ0FCAYUgwGBeU0DDhEPAQIMoHU?= =?us-ascii?q?CgTiIYXWBMoJ+AQEFgTUBE0GCdhiCBQcDBoE2gVOKRhqBQT+BEUeCTD6CZAE?= =?us-ascii?q?BAQIBgSwBEgEhFRuCXjKCLI1JgnGeWgqCNINhgjeBG48BgkaHe5AWjlKBRoc?= =?us-ascii?q?MkgQCBAIEBQIOAQEFgWkiZ1gRCHAVO4JsUBgNjRI4gzuFFIU/dAEJgR6OB4I?= =?us-ascii?q?yAQE?= X-IronPort-AV: E=Sophos;i="5.69,351,1571702400"; d="p7s'?scan'208";a="676475875" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2019 15:46:59 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xBOFkxr2030778 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Dec 2019 15:46:59 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:46:58 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:46:58 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Dec 2019 10:46:57 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AJ5qUEUPJe36d/6M2ex1LDhzy+OCkr5ou3CouOA7ohaC2ak0puicM3yyK4iS19s2oir1faH/CcS8w4cmIrzYnZcsBgzOmhv49z3sXJhbpAkbHS0ZgMk2dJEvejE91fnCKSw1vR04rK5KW+JiQOhrzc0qVDHsAX/lzi2TM9NqLY31etRfuxTXmJwJJIekf7obzwHGn6lTHRwV7La4GJQp1+KipUleuTyuXjZjDSz35bFNk2R4mrCdcU3+6pXoGKwfuldE91fJfjZGWrFoYzDqWMCLe7YTgzJ6FNMwHeSM4sXV6/DFhYVzO5GwSxgj9R4smR5vjLEqP9x+ln7t3wzEHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pMnKkD6mxcE67zAswcz1Q7nIpGSqJoOn+Ue5Xemv4nM=; b=AyW++JrnAT5Y4IOsGx5Yn4emxdXu1y/9zLrrUKaoafg9aJl7BQ1SSSUrG0bqm/cUcduYLNWNXqnpjhcx0rd9aiP1bixHD+jEwooENZ+CmqrZ59KyPFXp37RriGfV50OqNtLz7I7xyjGrolgqVugIBo7qPg7/JvtZPhUm3mgmR50TVN5iyG7tsucA1mUIk9b2YGd03tnJ9+eH4+nfJe83ujHiPROxIrKUknCEBlnsJW2fif+TD0cBrr//9MtQ6aA6tToIy8JuWqLhIyG9Yy7OAez2MyST0Iex1cWN3J39gt/kjAky7rrGkBv1u76lcytgKQLb2r4zBi3i+/uYawrYyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pMnKkD6mxcE67zAswcz1Q7nIpGSqJoOn+Ue5Xemv4nM=; b=hik3BIXIfZ8eR23cmkwpAfuAdKt1kCsJrThDONoCCjDb3C7xO66+0NHpVc+5PAeuRHHrItwecwrJ0fdU+4yLOGzmuGAizzdqpgxcjJKLnLn9Ac6UWVDJ6xdO+1cLU04GrGWVi1JixaIbEN7x+t7xeoIFQIUXzo3dl1d9FAOiJMM= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2722.namprd11.prod.outlook.com (52.135.242.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.16; Tue, 24 Dec 2019 15:46:57 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Tue, 24 Dec 2019 15:46:57 +0000 From: "Panos Kampanakis (pkampana)" To: Adam Roach , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Thread-Index: AQHVtUrvBuuwn1+t5EO6fSPw+/uqFKfFlcuggAPduOA= Date: Tue, 24 Dec 2019 15:46:56 +0000 Message-ID: References: <157663612332.4994.1427589526663831052.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::215] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6afb20b5-5bf2-40f2-a9f0-08d7888881e1 x-ms-traffictypediagnostic: BN7PR11MB2722: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(346002)(376002)(136003)(396003)(39860400002)(366004)(13464003)(51914003)(199004)(189003)(53546011)(81166006)(66476007)(66446008)(66556008)(64756008)(6506007)(54906003)(81156014)(110136005)(66946007)(478600001)(2906002)(966005)(76116006)(4326008)(9686003)(33656002)(55016002)(66616009)(8936002)(316002)(86362001)(7696005)(71200400001)(5660300002)(186003)(8676002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2722; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wHaRFLl7lB/rJdIxWyl2axNwtiYb+ZQf+XMRozoUNRkpDO3Ab/Uw4V1vjtbEYPaHcrFX+x4zjk+2swAoylTbvFEIkhgjUczwq9dDXOJMUGOiv2IxlsNqxmvw2ORnSQt0dv9US/3unGXVYiyj6EPbF3cYzg2Qmpp2FGnF+45cbPW3BKxX7y9KnNiBL9VwvVPygAVWKpl1yJn33TOvS/uOUxyipBfWIUxU4oeRRox+12nBLqUOjxzEPiyL0aWC5bLqAkALqxfd6ctRD+ybeWBkOmfMcBb7+g/tqyZW42oQVuTq5R2ZwltZ9eIeWX6w976qW5hbPSDdG/H6M6Ry67XGksLh0K3VRactC7T4lXjnFEI02sE1JSZB/t5ClRFvFBqMWlEZ3433RU7GOik9iMj0so+egtUjhjx8x+dq6KxkBUg3PzAf+I7gVlZEZtcSbsHSgqvbjYrYsPizjctnn7UCmDS1e41B3j9qDE9QlDT6CpQ+Txoj3Yrzg2l0cZ2PJGyL5vBnWSV3MKBRcrni/s1c32iEKTqUs5pAW5yqkogUF6fAwgR30myZ7HmszHTTLIgqx07nQ2lZNWTXIvIDyt+4emhTy/OZdPaqfAB3QeHYxXvC/RRj5eEVcmsrbHz8LsNM x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0061_01D5BA47.755840A0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6afb20b5-5bf2-40f2-a9f0-08d7888881e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2019 15:46:57.0135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KAenan4cwLjbUajxp4V1SMCxF6dFi+kXpjSMbntk7p9Lal9MCqDBBhiCBxXgvUzEF64v7sRk/p//QMrpZqNDUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2722 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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, 24 Dec 2019 15:47:03 -0000 ------=_NextPart_000_0061_01D5BA47.755840A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Adam,=20 This commit = https://github.com/SanKumar2015/EST-coaps/commit/662752d2a725ee72a75af70c= 36a6379b5cc2d4ab tries to address your feedback. The full discussion is = in https://github.com/SanKumar2015/EST-coaps/issues/156=20 Let us know if it does not make sense.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis = (pkampana) Sent: Saturday, December 21, 2019 11:37 PM To: Adam Roach ; The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: Re: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: = (with DISCUSS and COMMENT) Hi Adam, Thank you for the feedback. For completeness, we are tracking it in a = git issue https://github.com/SanKumar2015/EST-coaps/issues/156=20 Good point about updating the Well-Known URIs to include [This RFC] = additionally to RFC7030. We will make sure we add this in the IANA = considerations. We will also address the other three nits as well.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Adam Roach via Datatracker Sent: Tuesday, December 17, 2019 9:29 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Adam Roach's Discuss on draft-ietf-ace-coap-est-17: (with = DISCUSS and COMMENT) Adam Roach has entered the following ballot position for draft-ietf-ace-coap-est-17: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work that the authors and working group put into this = document. I have one DISCUSS-level comment that should be very easy to resolve, = and a small number of editorial nits. -------------------------------------------------------------------------= -- =C2=A79: Since this specification is adding new endpoints under /.well-known/est, = it needs to update the "Well-Known URIs" registry so that the entry for = "est" indicates this document (in addition to RFC 7030). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =C2=A75.3: > The Content-Format (HTTP Media-Type equivalent) of the CoAP message HTTP doesn't have a "Media-Type" field. Presumably this intends to say = "Content-Type"? -------------------------------------------------------------------------= -- =C2=A75.3: > Media-Types specified in the HTTP Content-Type header (Section 3.2.2 Nit "...header field..." -------------------------------------------------------------------------= -- =C2=A75.5: > HTTP response code 202 with a Retry-After header in [RFC7030] has no Nit "...header field..." _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0061_01D5BA47.755840A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI0MTU0NjU1WjAvBgkqhkiG9w0BCQQxIgQgIxROzRsJPaKQ9ZxHFHZNa7BixhYQ6jxb Y1HQdERQwvQwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA Ixy2I3dqvdCCsZhYcWrYa0pu9FKgTFWS4HeTb0PCKIkkERcOkFMErfbbOt3wPHUx76vz/3A1nle2 p/1sz2hP/qfqj1CFzlPQS4iK/FeQ+ZgTRDRPaR63UIyreofEcz5mMgr844Tav3927SRKXPuGg09/ UcWkvg8ipE47BiHL5M/tDm0PU5e5I43RCHA8qNCFHJVlPpk/RWZLzJuoQdrpwP8FA+gQm9eA/FwC zc14TehC/z01RmXm7pQDsWNM8eEGmAAfPI3pZZst8ikE6QTcaSJGNukKrfizK/KU15mze5SyYFLS /PowGz6vReOF8H53Pe2aDITzBg5cJXIAEWi3fgAAAAAAAA== ------=_NextPart_000_0061_01D5BA47.755840A0-- From nobody Tue Dec 24 07:50:14 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6617120119; Tue, 24 Dec 2019 07:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AtrUiKZZ; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=yIINX4LH 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 3ZQueFRGbQQC; Tue, 24 Dec 2019 07:50:10 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F5F1200B8; Tue, 24 Dec 2019 07:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16606; q=dns/txt; s=iport; t=1577202610; x=1578412210; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EbvLlNO/Dg00cKuaZRB1g/ROpCTmp4dEq/+Kny+W8Lw=; b=AtrUiKZZDGC+RSCyxI3MM5QsDZNS/PCFYgf09fwQTWNPYDDdQKZZP9Ga ffZUqknUtgonSOTXcVuHD5fjDuqeSAOy5LpPKONYz9+Jem6ujiB5FQNhO N9gwuV44YSwK/4DUj0hLxd9be3HLxmn5ZBKpEQ2hVxvTXP2GSzgoRY8hg 4=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AgIMhQBQOCEyHCieV5YwVrx+ab9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQ5FcFaXVls13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNCADWMgJe/51dJa1cCR0BAQEJARE?= =?us-ascii?q?FBQGBfIFSJAUnBWwrLSAECyqECINGA4p4gl+YCIFCgRADVAIHAQEBCQMBARg?= =?us-ascii?q?NCAIBAYRAAoIfJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDAQEQER0BASU?= =?us-ascii?q?HCwELBAIBCBEEAQErAgICJQsdCAIEAQkEBQgGFII1TIF5TQMfDwECDKB/AoE?= =?us-ascii?q?4iGF1gTKCfgEBBYE1ARNBgnUYggUHAwaBNoFTiikODxqBQT+BEUeCTD6CZAE?= =?us-ascii?q?BAQIBgSwBCAoBCRgVG4JeMoIsjTUIDIJxiBmHH44udAqCNINhgjeBG4R0R4l?= =?us-ascii?q?GgkaHe5AWjlKIUpIEAgQCBAUCDgEBBYFpImdYEQhwFTuCbFAYDVeMOwsYFYM?= =?us-ascii?q?7hRSFP3QBCYEejgeBU18BAQ?= X-IronPort-AV: E=Sophos;i="5.69,351,1571702400"; d="p7s'?scan'208";a="397279707" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2019 15:50:08 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xBOFo8AQ012121 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Dec 2019 15:50:08 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:50:08 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 09:50:07 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Dec 2019 09:50:07 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FA4cYXXwkg99EJVFr/+tQtNnjhC6klwCn7RqXOxBjNkZCM/OI9MDnQF8KAN2C5YQ/UkURhvhjCqtpNPpD9XIrlXglx3bbjMoPzFg7B4QPP3StaC5jah00MldqB3CkNhCfzl+fXFmTcizaWEsibHEaqVeRgLYG29MYXvbPdzP6SeKHctJkMq1+40yPDJ+PPPK6JeC4EcUvFfYO5jIcjhuSf6lAmcbvOgYZnxtue1dx+ddaDFsPqDTofXLvb5ZJTqpI35XyF81Omb1IU/+w3+zf7W9Przc2wnYrWzkSoCxCWn12ww6xnswzj65Wjr/4OmVkelxdLQ63RAYOGSIFy8/tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I2HwaLw6WP5UrTQB29c95Vq3V71E2JkXAGmZi6V63vY=; b=ijvp6AkvacsOxYclwk0/st/Yq1lyUzBwN1cY8Bs/G+myB+9/7vE3gOjgEfpbRbPf3N8rrnYnj2gVx0covRjwsfz8yry9kdTf3shSkPOWZms1Te3+O269zKvq1hSQdduUcxdNP2SXkHbpWUpIBOH/Dn0bVIJMNu9tRIOQTa7/ZxTEmvmYomaYXnENOi6vmp3SZvjH8xtaAGXbs4F141be1ze3hKqrUDvZ/79sF8UrLdVqgns8s1vpcz8mBV3WcHvDJBN0cSzEkP7KReUKeEnqrxBQv+k3knah/5bDjo4aBN9efynNyEN5PbHZozmm5uSyq/OZfVW1aOnLct+Vlz4spw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I2HwaLw6WP5UrTQB29c95Vq3V71E2JkXAGmZi6V63vY=; b=yIINX4LHmmCoD0aqnUpHvwSmgR3o7cCHbVaw/cuCyqUF+motdk8jP1FsaKFsS+PAHubRSxU/KMV1UntCW5HIeqIkCCiYsyzBKgRiJGEnTTbMcS7RapJFCXZBhh+GzqJIuc0Dk2aPH3gYdiQqMTf1LW4amEkIctjW6sXuIxSE6jw= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2722.namprd11.prod.outlook.com (52.135.242.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.16; Tue, 24 Dec 2019 15:50:06 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Tue, 24 Dec 2019 15:50:06 +0000 From: "Panos Kampanakis (pkampana)" To: Barry Leiba , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Thread-Index: AQHVtIXtXsiUGCzH10qa4vZMC+mOsqfFhtmQgAPuLTA= Date: Tue, 24 Dec 2019 15:50:05 +0000 Message-ID: References: <157655152334.24617.3401591731456466633.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::215] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2fcc898c-5dc3-4c9d-2564-08d78888f28d x-ms-traffictypediagnostic: BN7PR11MB2722: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(346002)(376002)(136003)(396003)(39860400002)(366004)(13464003)(199004)(189003)(53546011)(81166006)(66476007)(66446008)(66556008)(64756008)(6506007)(54906003)(81156014)(110136005)(66946007)(478600001)(2906002)(966005)(76116006)(4326008)(9686003)(33656002)(55016002)(66616009)(8936002)(316002)(86362001)(7696005)(71200400001)(5660300002)(186003)(8676002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2722; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3lwQsun+mB450UDyYY4XjUDBzFHMGRTjXEZg5BoTbupco0AK4UXGgw4EuYC8t9A30T/9Px5sj3NAVx6XsbPwatnU+gOgO6JwMtkxjMrkocQ4xKdJSXWxOZxwRYRfsczMcVZ5cHkOYaypXYzIPsAiipYrfEfSlcFw//8M6YZqoGrtG9nd1VNdp1B9n+iBKpjD8kZfnU0JAckxx+gb2KGpl6K4U48O7/Ej2/x9lwoiVwTGR6AMjKX/nWVi69aMNoju43hqKuKwq3nPGCrr+Zv0PC/b4BDlvBZsoe4nicD79CE0VXRNphq8XVQF1AtCRPn7LtC+IH42rXG+VjT9ux8ovU031iasPkY+X5IeFmnfkI6SX7Ku9mzabekL3jjDN4wic33OcwwKTfIIeY2sdBjTNFFGBQT+wPpXnEqSLFIu45n3YQ6PY/YzKIk5+hESBlrfuCN+/4U8oqETWgGcDDCmfUoSdehtcvQKHHtGcZydFYOWeUCXU3AsMc+E7rPwjL/C4Vhi8SgDf6Uqs+mEV3UxjzNnYprzKl3WuaSMva47S+Mm7CZgX1+leDwd/Z9vhaLmggSqbkR2A0jP8RRvlgIAWoWXLBm9MtBqee/3sAI3P3A= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0069_01D5BA47.E5D518D0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2fcc898c-5dc3-4c9d-2564-08d78888f28d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2019 15:50:05.9952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: O5+COcpWrlVCYVHazU4tqc3paB//pCTA+cGhW10YAvnK13TKWNIB6tLEeM2eizcmt5I5ogqyb62JogwTbZ7cjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2722 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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, 24 Dec 2019 15:50:13 -0000 ------=_NextPart_000_0069_01D5BA47.E5D518D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Barry,=20 This commit = https://github.com/SanKumar2015/EST-coaps/commit/01f7014e2348d09c0a1ff768= eea7d53f4c5471f2 tries to address your feedback. The full discussion is = in https://github.com/SanKumar2015/EST-coaps/issues/153=20 Let us know if it does not make sense.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Panos Kampanakis = (pkampana) Sent: Saturday, December 21, 2019 10:49 PM To: Barry Leiba ; The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: Re: [Ace] Barry Leiba's No Objection on = draft-ietf-ace-coap-est-17: (with COMMENT) Hi Barry, Thank you for the thorough review. We are tracking your feedback and our = responses in a git issue = https://github.com/SanKumar2015/EST-coaps/issues/153 We mostly confirm = all your minor text changes and nit fixes. The TBD one we will not fix = as we are waiting on IANA. Let us know if something does not make sense.=20 Rgs, Panos -----Original Message----- From: Ace On Behalf Of Barry Leiba via = Datatracker Sent: Monday, December 16, 2019 9:59 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; = ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: = (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this =E2=80=94 a useful document. I have a bunch of = comments, but they=E2=80=99re all editorial. Please consider them, but = there=E2=80=99s not a need to give a detailed reply. -- Section 4 -- In that case, the server MAY want to authenticate a client certificate against its trust store although the certificate is expired (Section 10). Total nit: Why "want to"? Why not "server MAY authenticate"? As described in Section 2.1 of [RFC5272] proof-of-identity refers to a value that can be used to prove that the private key corresponding to the certified public key is in the possession of and can be used by an end-entity or client. I find the passive voice to be quite awkward here, and suggest making it = active: NEW As described in Section 2.1 of [RFC5272], proof-of-identity refers to a value that can be used to prove that an end-entity or client is in possession of and can use the private key corresponding to the certified public key. END the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed as if each handshake message had been sent as a single fragment (Section 4.2.6 of [RFC6347]). I know this wording is directly from 6347, but I think it's unclear and = would like to suggest an alternative. The "as a single fragment" part = is odd, because I think what it's really saying is that it's computed as = if it had not been fragmented. My suggestion is to change it thus (and = similarly for the next paragraph after): NEW the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed on each reassembled message, as if each handshake message had not been fragmented (Section 4.2.6 of [RFC6347]). END If that's not correct, please take that as further evidence that it's = unclear, and adjust accordingly. To alleviate this situation, an EST-coaps DTLS connection MAY remain open for sequential EST transactions which was not the case with [RFC7030]. For example, an EST csrattrs request that is followed by a simpleenroll request can use the same authenticated DTLS connection. Two total nits: a. Comma before "which", please. b. The "for example" needs some rewording to make it work: NEW For example, if an EST csrattrs request is followed by a simpleenroll request, both can use the same authenticated DTLS connection. END -- Section 5.1 -- EST-coaps is targeted for low-resource networks with small packets. Two types of installations are possible (1) rigid ones where the address and the supported functions of the EST server(s) are known, and (2) flexible one where the EST server and it supported functions need to be discovered. This needs a colon (:) after "possible", a comma after "rigid ones", "a" = before "flexible one", another comma after "flexible one", and make it = "its supported". -- Section 5.5 -- Similarly, 2.04 is used in successfull response to EST-coaps POST requests (/sen, /sren, /skg, /skc). There's odd spacing here; please fix it. And "successful" is = misspelled. -- Section 5.7 -- If the server is very slow (i.e., minutes) in providing the response (i.e., when a manual intervention is needed), I think you mean "e.g." for both of those, evidence for my general = aversion to using Latin abbreviations that many people don't fully = understand. It also feels odd to have the two examples separated in = this way. I suggest this: NEW If the server is very slow in providing the response (for example, manual intervention is required and it could take minutes for it to respond), END it SHOULD respond with an ACK containing response code 5.03 (Service unavailable) and a Max- Age Option to indicate the time the client SHOULD wait to request the content later. Perhaps, "to indicate the time the client SHOULD wait before sending = another request to obtain the content." ? After a delay of Max-Age, the client SHOULD resend the identical CSR to the server. As long as the server responds with response code 5.03 (Service Unavailable) with a Max-Age Option, the client SHOULD keep resending the enrollment request until the server responds with the certificate or the client abandons the request for other reasons. That last sentence reads very strangely to me. It SHOULD keep resending = the request until it decides to stop? What does that actually mean? Maybe what you're really trying to say is something like this?: NEW As long as the server continues responding with response code 5.03 (Service Unavailable) with a Max-Age Option, the client will continue to delay for Max-Age and then resend the enrollment request until the server responds with the certificate or the client abandons the request for policy or other reasons. END -- Section 5.8 -- In scenarios where it is desirable that the server generates the private key, server-side key generation is available. This seems like a content-free sentence. Maybe this?: NEW Private keys can be generated on the server. Scenarios where that makes sense include those where it is considered more secure... END Of course, that does not eliminate the need for proper random numbers in various protocols like (D)TLS (Section 10.1). May I suggest this?: NEW As always, it is necessary to use proper random numbers in various protocols such as (D)TLS (Section 10.1). END server or proxy to generate the private key and the certificate which are transferred back to the client Needs a comma before "which". or the asymmetric keypair establishment method is out of scope of the specification. "of this specification". [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.3) . The two representations More odd spacing. Dependent on the request, the private key can be in unprotected PKCS#8 [RFC5958] format "Depending upon the request" In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key which is encrypted by the client-defined (in the CSR) asymmetric public key and is carried in an encryptedKey attribute in a KeyTransRecipientInfo structure. Long sentence that needs punctuation: comma after "operations", comma = before "which", comma before "and". Also, I would move "(in the CSR)" a = few words later, after "public key". -- Section 7 -- It is recommended, based on experiments, to follow the default CoAP configuration parameters ([RFC7252]). Odd spacing, again. But "it is recommended to follow" is also odd = English. I suggest making this active, rather than passive, thus: NEW Implementations should follow the default CoAP configuration parameters ([RFC7252]). END I don't think the "based on experiments" bit adds anything, but if you = want to keep it you can prepend "Experiments have shown that" to my = suggestion. -- Section 9.1 -- Don't you want to remove the "TBD" on "TBD287" here? Wasn't the "TBD" = just a flag to remind people that it hadn't been formally allocated yet? =E2=80=94 Section 10.1 =E2=80=94 It is important to note that sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs are not available on many constrained devices, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, as pointed out in [PsQs]. The sentence order is wrong here. For example, mouse movement is not a = constrained device. The correct order is more like this: NEW It is important to note that, as pointed out in [PsQs], sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, are not available on many constrained devices. END _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0069_01D5BA47.E5D518D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI0MTU1MDAzWjAvBgkqhkiG9w0BCQQxIgQgJPFQQjgzZK8/Du7w/eeZloNdlNyHILGH uJkMWjNB8sUwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA M3hFOEy/ENWXy3sigDxWx24qdtz8qMzQ6ChVw8nEyGj9NhifN96PGBf10DG0k60PS8JCvYBVCK/F BoTftXBlt0uGJB1htA+gw9l93zwvI4fMm+BWMfAlSliAJI9gM6FdeJagMOYdFVtIpdjel7z0lG1/ 6kAyXscHpqUQFGiZphGAJQpeszMYzuSQKN4DtzHfvzaLEGl6fHGdKw5yuo1Fq+O8hg+icGpmRKFh TdsNQHPN5Z3ODOU2po6hNDN5ZpFzvzbDQDxDILoTMu7+Fl70MOmtMZZ3AN6ZIaTyktwmndoH974x +5ydJ/YNa1Nim99Y5F7+jl+DWI9toTIhl3IdaQAAAAAAAA== ------=_NextPart_000_0069_01D5BA47.E5D518D0-- From nobody Tue Dec 24 11:33:08 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4441201E0 for ; Tue, 24 Dec 2019 11:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 D0x4zUQYl1Be for ; Tue, 24 Dec 2019 11:33:03 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848CA120046 for ; Tue, 24 Dec 2019 11:33:03 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBOJWnu3028894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Dec 2019 14:32:51 -0500 Date: Tue, 24 Dec 2019 11:32:49 -0800 From: Benjamin Kaduk To: Cigdem Sengul Cc: Francesca Palombini , Ace Wg Message-ID: <20191224193249.GS35479@kduck.mit.edu> References: <75220EAA-9455-4691-9E99-3E16401D1309@ericsson.com> <20191219223015.GO81833@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Review for draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org 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, 24 Dec 2019 19:33:06 -0000 On Fri, Dec 20, 2019 at 12:03:04PM +0000, Cigdem Sengul wrote: > Hello Ben, > Response below. > > > > > > > > > > > > CS: I see that I wasn't clear in my thinking before and mixed up things. > > I > > > was trying to understand how groups map to topics and the topic > > hierarchy; > > > and how group maintenance scales with the increasing number of topics, > > > publisher and subscribers. Said another way, who creates groups, and > > > creates/updates keys for these groups to be maintained in the KDC? > > > > > > I agree topic hierarchies require more thought. Here is my second attempt > > > at explaining my thinking, which is by no means complete: > > > In MQTT, it is possible to publish to all levels in a topic hierarchy > > e.g., > > > if you have sport/tennis/player1/rankings, it is possible to publish to > > the > > > sport, sport/tennis, sport/player1, sport/player1/rankings... > > > One option is to have as many keys as the nodes on the hierarchy > > > independent of actual publishers and subscribers to them. (Assuming this > > > hierarchy is pre-built, and AS2 maintains a complete topic-key database). > > > So, if publisher P1 comes with rights to publish to sport/tennis - he > > gets > > > the keys for that. But, if he comes with the right to publish to > > > sport/tennis/#, he gets multiple keys, one each for every node under > > > tennis. > > > > Having to always send all the keys would get frustrating (and/or expensive > > in terms of bytes!), but the "other option" below feels quite messy with > > respect to having to push out updates when membership/number of groups > > changes. I suppose the right balance depends on actual usage patterns, but > > I would mostly expect a flow where permissions on a hierarchy grant the > > ability to get any (per-topic) key from the hierarchy, but you still have > > to explicitly request the individual key for the individual topics you are > > going to post to, to be of most generic applicability. Am I forgetting a > > reason why that's not possible? > > > > Thanks, > > > > > Yes, both have problems - mainly used them to talk about the differences > between (semi-)static grouping (topics define groups) and dynamic grouping > (active publisher/subscribers and their topic permissions determine groups). > > Yes, a token with scopes that use the wildcard will give you the right to > get any key from the hierarchy. In the "first approach," you would need the > get the specific one for the individual topic because any number of > publisher/subscribers may be on that topic (but not on others). > If I understand correctly, you suggest that the client asks for the right > key just-in-time before a publish/subscribe message? > This is a good solution if the client can connect to AS2 at all times, but > in ACE, I thought, we did not assume ASes are always reachable by clients. > Therefore, I was always thinking of a scenario where the client is > provisioned with the right keys beforehand (determined by their > permissions). Yes, I was thinking of having the client ask for the key "just in time", but you are also right that we do consider cases where such connectivity is not always available. So perhaps there is not a single clear answer for all cases... > But the "second option", where the same encryption key may be used across > different topics, has the same connectivity requirements due to rekeying > expected as groups change. > > I hinted this in my previous e-mail by having to consider rekeying > policies, as I haven't seen it mentioned in coap-pub-sub. > > Need to also consider rekeying as a separate problem that needs to be > addressed regardless of what approach is taken: ace-key-groupcomm refers > to [RFC2093], [RFC2094] and [RFC2627] for rekeying mechanisms and I am not > exactly sure how to use them for client-broker communication. > > ace-key-groupcomm also states: If the application requires forward > security, the KDC MUST generate new group keying material and securely > distribute it to all the current group members but the leaving node, using > the message format of the Key Distribution Response" > If it is the AS2 (KDC) that needs to rekey groups, then AS2 should be able > to connect to the clients and push this information? Am I missing something > here? I think we need to hear from other members of the WG to make progress here; I don't have a clear picture, myself. -Ben > (In MQTT, things were easier when tokens expire. The Broker knows a token > expired and disconnects the client, which forces the client to get a new > token. But, the Broker here has no idea of rekeying. So, the trigger for > that needs to come from AS2. ) > > Regards, > --Cigdem > > > > Ben > > > > > > > > > > > > > > The other option is creating groups dynamically and subtopics inherit > > > authorisations (as captured by the wildcards), i.e., publisher and > > > subscribers that have an exact match in their topic filters form a group. > > > Going back to the previous example, assuming AS2 is generating the keys > > > (need to read the groupcomm in detail to understand how the KDC and its > > > endpoints work in general), I imagine something like this may work: > > > Publisher P1 - publish_sport/tennis/# -> AS2 checks if a matching group > > > exists, doesn't find one, generates the key, and hands it out to P1, > > stores > > > the mapping. > > > Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching group > > > exists, find one, gives out the key to P2. > > > Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching group > > > exists, find one, gives out the key to S1. Until now, assumed no rekeying > > > when the new members join an existing group, as this would work well with > > > MQTT RETAIN option, which enables the publisher to indicate > > > to the Broker that it should store the most > > > recent message for the associated topic. Hence, the new subscribers > > > can receive > > > the last sent message from the publisher of that particular topic > > > without waiting > > > for the next PUBLISH message. > > > Subscriber S2 - publish_sport/tennis/+/rankings - AS2 checks if a > > matching > > > group exists, does not find an exact match -> generates new key, but then > > > needs to update P1, P2, S1 as well as publish_sport/tennis/+/rankings > > will > > > be sent encrypted with the new key, and the rest will be with the old > > key. > > > When they are rekeyed, the publishers may send RETAINED messages again > > with > > > the new key. > > > > > > i.e., > > > P1-P2-S1 are one group > > > P1-P2-S1-S2 would be another group > > > Two groups - two keys. > > > > > > Do not know what is best, or there is a third option. > > > > > > Another thing to consider would be rekeying policies of course. > > > > > > > > > > > > > > Another approach could be each publisher creating its group. This way > > the > > > > number of groups scales with the number of publishers (and the COSE > > keys is > > > > per publisher). > > > > > > > > > > > > > > > > FP: I don't think this scales well, but yes, an application could also > > do > > > > this. > > > > > > > > > > CS: Yes, scratch that - that actually wouldn't work. > > > > > > Thanks, > > > --Cigdem > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > --Cigdem > > > > > > > > > _______________________________________________ > > > Ace mailing list > > > Ace@ietf.org > > > https://www.ietf.org/mailman/listinfo/ace > > > > From nobody Tue Dec 24 12:15:32 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDA21200F4 for ; Tue, 24 Dec 2019 12:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cAOmupLgNCMz for ; Tue, 24 Dec 2019 12:15:30 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354901200B6 for ; Tue, 24 Dec 2019 12:15:29 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBOKFBGG005544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Dec 2019 15:15:13 -0500 Date: Tue, 24 Dec 2019 12:15:10 -0800 From: Benjamin Kaduk To: Jim Schaad Cc: "'Ludwig Seitz'" , "'Daniel Migault'" , "'Roman Danyliw'" , ace@ietf.org Message-ID: <20191224201510.GV35479@kduck.mit.edu> References: <157508633572.4770.7120325133415529789.idtracker@ietfa.amsl.com> <000901d5b201$0ff47c90$2fdd75b0$@augustcellars.com> <42f75b3b-9d85-5483-401b-d23b167dd038@gmx.de> <008301d5b831$e91ba8f0$bb52fad0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008301d5b831$e91ba8f0$bb52fad0$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] FW: [IANA #1157486] Last Call: (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed Standard X-BeenThere: ace@ietf.org 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, 24 Dec 2019 20:15:31 -0000 On Sat, Dec 21, 2019 at 11:07:34AM -0800, Jim Schaad wrote: > Personal opinion, > > I think that we should be requesting a separate page. I think we are going to have enough different registries that keeping them separate from OAuth is going to be useful in preventing confusion. For the mapping registries, it might be useful to see if IANA can give us a link from the mapping registry to the OAuth registry. I think IANA can do that sort of link, and am inclined to agree about having a separate page. -Ben From nobody Thu Dec 26 21:20:20 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18B12006D; Thu, 26 Dec 2019 21:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gDoUTpu5; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=ZF6S2KaF 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 on1JDo5saFnB; Thu, 26 Dec 2019 21:20:10 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE6B12001E; Thu, 26 Dec 2019 21:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19738; q=dns/txt; s=iport; t=1577424010; x=1578633610; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3VCl8PpjNz9nW5xYq/J5UBi5fZHAJIElH5BDCDLmwts=; b=gDoUTpu5hMJaC+tf3hzEp3ImvZd8xXJl3BfuN7WtLJyXxlmfvYlgVg2a ZiRTlud2r1ZhYPdGtExMDLRnhWjd2S2a+pSybQyNq8e3nID5TYIeAFHF7 QSB2Fs6AowwYgn4j5hPveVgNps5Or5l/yxVp+TRNQvxpMkx4C6eJx4qxT k=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AHGIH6xZhQZ2wTNq7qurwyRX/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/BgDVkwVe/5NdJa1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBJS9QBWwrLSAECyqECINGA4p5gl+TKIRhglIDVAIHAQEBCQM?= =?us-ascii?q?BASUIAgEBhEACgh8kOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQMSEQoTAQE?= =?us-ascii?q?3AQ8CAQYCDgMEAQEoAwICAjAUCQgCBAoEBQgGFIMBgXlNAx8PAQIMjnmQZAK?= =?us-ascii?q?BOIhhdYEygn4BAQWBNQGDSxiCBQcDBoE2gVOKRhqBQT+BEUeCTD6CZAEBgWU?= =?us-ascii?q?VFgmCWjKCLJAEOY84jyIKgjSDYYI3gRuPAZpXlySSBAIEAgQFAg4BAQWBaSK?= =?us-ascii?q?BWHAVgydQGA2NEjiDO4pTdAqBHpImAQE?= X-IronPort-AV: E=Sophos;i="5.69,361,1571702400"; d="p7s'?scan'208,217";a="410611159" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Dec 2019 05:20:08 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id xBR5K8cM026461 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Dec 2019 05:20:08 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 23:20:07 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 23:20:07 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 26 Dec 2019 23:20:06 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GsOartDH9mq+wzEUSKqqsQ0XcnXSxvQxftYHsW4509J5v6aVnF4t2bf24DXR4zi57Nxh5FgO1/1iAacXV6U56q5eSF+nYP8h2x/3gw81+4WDA7N3fUdsaJ0KLV3vfGDy2I7tSulSlMs4AJUT+elARW2USmqDJlpwLszhmO0kqMHf4U9U7MjYTplsCLmkCdOXsg/CM5D3J+3k8A0SHh27L1EwdAXoUvrCtEmkelVsOYEae6vHeuZ7GtcqOirKSwBQ8mQtRLumMXDfLfCuJh4v/gwEuHfpbQC9QER+9Z92+sxdEF38haMe4J8bkAPzyP121qx3uPxjKM9X5lfneyW9GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fLDHrTqBTab+8Cqodfae4kNvHEuq1a9XTY1N8biHFuw=; b=Hz6EEZkEKwxViJC8IM0AICpHaOuHsAV9WHYvKX6rzK3AB+aLjcXZaqwZaIHCI5Fc3Hd1Gy3M50fOFrIOSrWxa9OjtScir0LLaA6iFvhSBrSGhc1Hpsiemo2WbAy/nsAACYM6DLQ2gixRZ/eJsxVj5fczclghm9mzUB5IH4fn1WtBoApmDWYL6UoJl4XnMFlwaPd5NXjROCVcC2nW1hRwos5zQy3lcJbz1PsjpKGjR8ktz6AFBSuGOTgAAwrFjlUL72KTTtDnyPeHA/ZUZbT17RcQivgStK1GRBjh7KmlYP0DiCXg/L0J6ubuoUVZ7z0fBR2h9Ysb41e0iVhpYWE7jQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fLDHrTqBTab+8Cqodfae4kNvHEuq1a9XTY1N8biHFuw=; b=ZF6S2KaF9cLRm5YQQ6sLU3DGH7p8My0vncSi74CMOGGj2qpNpu7hrWMm+rS7jTqHl6z+/amd67X7AtVVaGXniOWlNLiuWuQxaESRqTxF5kRKfdwuQtKd5alZoUfqw/1q2WPFKz3I2ZxEv8J/5mPKFWLyf3aX71/Gdl60J+B8D54= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2545.namprd11.prod.outlook.com (52.135.244.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Fri, 27 Dec 2019 05:20:05 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Fri, 27 Dec 2019 05:20:04 +0000 From: "Panos Kampanakis (pkampana)" To: Alexey Melnikov CC: "ace-chairs@ietf.org" , Jim Schaad , Ace Wg , The IESG , "draft-ietf-ace-coap-est@ietf.org" Thread-Topic: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) Thread-Index: AQHVuZ9MKws1vJPug0iD63ohArWgxKfNdnxQ Date: Fri, 27 Dec 2019 05:20:04 +0000 Message-ID: References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> <32540abd39940ad245e3c814e64a40e7@bbhmail.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1003::61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 76f1aa3b-58a0-4a6a-56d5-08d78a8c6e76 x-ms-traffictypediagnostic: BN7PR11MB2545: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(39860400002)(396003)(376002)(136003)(366004)(346002)(189003)(199004)(53754006)(2906002)(33656002)(66556008)(71200400001)(86362001)(9686003)(66476007)(55016002)(81156014)(8676002)(966005)(66446008)(8936002)(81166006)(64756008)(66946007)(66616009)(76116006)(186003)(9326002)(52536014)(4326008)(6506007)(7696005)(53546011)(54906003)(4001150100001)(478600001)(316002)(5660300002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2545; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jZntSiCX7zYqlfPm+XuDSsn8GiT9hiM/MMjKRF3H7/o8QZdxGd2Uh0liClSb4fRdf9FR0Rh3sl4Y/zC2U69XqJM93j1KgWeCPieUYM3Z5/RA0h9d7rW9M6nWe2TiTLi1Yk9ZKceoEi8l5iI25w5GSQT5EBAho08gPnXPFR9EHUdqgvWvhdxNon37LR8CjgwVq+fUYW7vOinDh5Mog5YKy5ruxPpmyut5zdS25Hh9vdEQrH5T2BXIn4+xWnyRtgt0CNlVXhhZu0k8M6M8/WOQRugktkrUE49l7HSjecV3N1797gfv4pSgV/+B+AiwRpwP0vPU+J4RTX80SbjLTfnp4jL2QFGSLC604xxpUEWVSV1/ifUx4HmDx+xlQ8xj+dZF2PDKoHwTAYxKSetIsy9m7HZhwQnLmWi/yrfYEFdSgIhEUJbZcOwjC4Ththo3v8sAt27X7eFmDhOOmdEfusFFS+HT22WeNVrDi8pRRH6lzRGua3/8n+jOKyf5lkCRzA2/GUk/J3h0Ot6Yc/fc8+KlB4pPjW52XGZmH7J3/8Lia/6q9IgXibqu/BWgTY+mp142YCw/txMdAl+ZMr5zFe6mLAE1LPR+hlOAqJPFAYVVWHs= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0007_01D5BC4B.61E36800" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 76f1aa3b-58a0-4a6a-56d5-08d78a8c6e76 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 05:20:04.8259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QaQ+hj2dVkH3r1MITgBtPq8ONyg7Iiiv/ryfNxx00Ow8KKhqjSl6ag5B4emVCViAGzGSENPa1wGU6wjRisSLtg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2545 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 27 Dec 2019 05:20:12 -0000 ------=_NextPart_000_0007_01D5BC4B.61E36800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01D5BC4B.61E36800" ------=_NextPart_001_0008_01D5BC4B.61E36800 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Alexey,=20 =20 This commit = https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f363e5e4= 8cd0d28970f9366e should address your feedback. The full discussion is in = https://github.com/SanKumar2015/EST-coaps/issues/155=20 =20 Let us know if it does not make sense.=20 =20 Rgs, Panos =20 From: Ace On Behalf Of Alexey Melnikov Sent: Monday, December 23, 2019 9:42 AM To: consultancy@vanderstok.org; Carsten Bormann Cc: ace-chairs@ietf.org; Jim Schaad ; Benjamin = Kaduk ; Ace Wg ; The IESG ; = draft-ietf-ace-coap-est@ietf.org; Klaus Hartke Subject: Re: [Ace] Alexey Melnikov's Discuss on = draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) =20 Hi Peter, =20 On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: HI all, =20 We had this discussion about this specific text several times. I like to keep at least some text for the following reason: Implementers, new to coap without a photographic memory of RFC7252 text, = are surprised by the absence of uri host in the examples, and tend to = assume an error. =20 The curent text does not look like a "normative rephrasing" to me.=20 Nevertheless, is the suggestion below acceptable to everyone? =20 OLD =20 The Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. =20 NEW Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port = Options can be omitted if they coincide with the transport protocol destination address and port respectively.=20 =20 Other suggestions are welcome. Your suggested text is much better. =20 Thank you, Alexey Peter Carsten Bormann schreef op 2019-12-20 18:16: On Dec 20, 2019, at 17:34, Klaus Hartke > wrote:=20 =20 I would prefer if draft-ietf-ace-coap-est didn't say anything here, since the Uri-Host and Uri-Port options and whether they should be omitted or not is entirely specified by CoAP [RFC7252].* =20 Klaus has an important point here. =20 We need to be **much more** vigilant about specifications messing with = their normative references. Saying how they are used, yes, but re-stating (or, worse, = re-interpreting) normative material from those references is prone to = creating dialects that no longer interoperate with their unadulterated = originals. Unless these are hopelessly broken(*) and this is the only = way to fix them, this is a MUST NOT. =20 Gr=C3=BC=C3=9Fe, Carsten =20 (*) the normative reference EST has an example for that case: The use of = content-transfer-encoding with HTTP, which is explicitly ruled out in = Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That was = a count of RFC 7030 messing with a normative reference, and in turn = **needed** to be messed with in CoAP-EST (and eventually needs to be = fixed in the parent specification, too). =20 ------=_NextPart_001_0008_01D5BC4B.61E36800 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Alexey,

 

This commit https://github.com/SanKumar2015/EST-coaps/commi= t/77d65f0eb7a28282f363e5e48cd0d28970f9366e should address your = feedback. The full discussion is in https://git= hub.com/SanKumar2015/EST-coaps/issues/155

 

Let us know if it does = not make sense.

 

Rgs,

Panos

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Alexey = Melnikov
Sent: Monday, December 23, 2019 9:42 AM
To: = consultancy@vanderstok.org; Carsten Bormann = <cabo@tzi.org>
Cc: ace-chairs@ietf.org; Jim Schaad = <ietf@augustcellars.com>; Benjamin Kaduk <kaduk@mit.edu>; = Ace Wg <ace@ietf.org>; The IESG <iesg@ietf.org>; = draft-ietf-ace-coap-est@ietf.org; Klaus Hartke = <hartke@projectcool.de>
Subject: Re: [Ace] Alexey = Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and = COMMENT)

 

Hi = Peter,

 

On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok = wrote:

HI all,

 

We had this discussion about this specific text = several times.

I like to = keep at least some text for the following = reason:

Implementers, new = to coap without a photographic memory of RFC7252 text, are surprised by = the absence of uri host in the examples, and tend to assume an = error.

 

The curent text does not look like a "normative = rephrasing" to me.

Nevertheless, is the suggestion below acceptable to = everyone?

 

OLD

 

The Uri-Host and Uri-Port Options can be omitted if = they coincide

   = with the transport protocol destination address and = port

   = respectively.  Explicit Uri-Host and Uri-Port Options are = typically

   = used when an endpoint hosts multiple virtual servers and uses = the

   Options = to route the requests accordingly.

 

NEW

Section 5.10.1 of RFC7252 specifies that the Uri-Host = and Uri-Port Options can be omitted if they = coincide

   with = the transport protocol destination address and = port

   = respectively. 

 

Other suggestions are = welcome.

Your = suggested text is much better.

 

Thank you,

Alexey

Peter

Carsten Bormann schreef op 2019-12-20 = 18:16:

On Dec 20, = 2019, at 17:34, Klaus Hartke <hartke@projectcool.de> = wrote:

 

I would prefer if = draft-ietf-ace-coap-est didn't say anything = here,

since the Uri-Host and Uri-Port = options and whether they should be

omitted or = not is entirely specified by CoAP = [RFC7252].*

 

Klaus has an important point = here.

 

We need to be **much more** vigilant = about specifications messing with their normative = references.

Saying how they are used, yes, but = re-stating (or, worse, re-interpreting) normative material from those = references is prone to creating dialects that no longer interoperate = with their unadulterated originals.  Unless these are hopelessly = broken(*) and this is the only way to fix them, this is a MUST = NOT.

 

Gr=C3=BC=C3=9Fe, = Carsten

 

(*) the normative reference EST has = an example for that case: The use of content-transfer-encoding with = HTTP, which is explicitly ruled out in Section 19.4.5 of RFC 2616 (and = now appendix A.5 of RFC 7231).  That was a count of RFC 7030 = messing with a normative reference, and in turn **needed** to be messed = with in CoAP-EST (and eventually needs to be fixed in the parent = specification, = too).

 

------=_NextPart_001_0008_01D5BC4B.61E36800-- ------=_NextPart_000_0007_01D5BC4B.61E36800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI3MDUyMDAyWjAvBgkqhkiG9w0BCQQxIgQgeqMruxcUaf+UgeIJvmsQHm1rSMIHMUDg GjcvT1Q5+sQwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA YahRV7EtNbhJCcyQoJm2+k7OQCuNlgWTVo9BLsePRLv9pMnKhVzO1AI2wvcP14Vagr3BCu6M0yB9 yUSiIQDJ9lyIEuzqum982Pr57MMPxT+y8HVB4kuSSgukDIFwRwlW6FpVtn8ml+BwAe8t1TI9BlfY UCCljuAFnv1PCKXPFdCnmNtDYRSo1eIdqRhVuXwbbgGXffR84k4gFjKqZmOKoRIdLZOqee7VV4xC jmnTjG3DjW7LKbitKCvFL6eeIv1YOVohWNpcq1sEZwxPLcZ3lRNpVPRNmzJMCRFJdk8l2HmQjkia IzfQZInsGtrWC4X3ItffE0O75FrzZe0QDJaeUgAAAAAAAA== ------=_NextPart_000_0007_01D5BC4B.61E36800-- From nobody Fri Dec 27 06:25:11 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CBF120052; Fri, 27 Dec 2019 06:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 iD3qzH5jHoJF; Fri, 27 Dec 2019 06:25:08 -0800 (PST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) (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 35328120046; Fri, 27 Dec 2019 06:25:08 -0800 (PST) Received: by mail-io1-f65.google.com with SMTP id v3so25923979ioj.5; Fri, 27 Dec 2019 06:25:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gVdfYM0yIzNKYdF3gQ8gE1ku8c8OkWTyKHWrOWm0iMY=; b=s26vMce4Z64QknktzU4pERf7Wc47mVpSV7eSSuIAAx1FCS9ldZEk7a4Yvco0ma0qIE P0C7cRzWu4EhS7JSgWZBkbs3BjcIAErYlSnf4z26rUNORy+myAew1UAcxKD9B+kiYabg QrWKYnxMBb6t+hqlQwmHUtQnOgXYkiodnpLjvEmGpFCr4kPr7I3ne2hXIXRV3WMPqPz2 O7ArFmA2F8Nesr+z3JazowXByaI+JO5teRtm3Rg43f0JT3gzAig33IaYkqGT4PXBEhIB 2s60X9r9b69Jo8mBR5Ce69CkIEnrEK7kNWb452fUllSEAOxaj5ldDV0kzyEbzAvL+gmd 1w+A== X-Gm-Message-State: APjAAAVzEFDdziyM3+RnOwUukjCnNW6DA3U2O7mQgHrF93sCeoJ5j/7L BQnoVNg+htvMmXpOpQ2YgYvPz2yu4UwuhBMz808= X-Google-Smtp-Source: APXvYqyffV0bxBYWfJ4v+7DlMEITddQ64mY4aQx8A7NsJyQDWRElXPFAbnk4Z/vQKeJHuUqY/oqyNtWGszdULHRqHzQ= X-Received: by 2002:a5e:d907:: with SMTP id n7mr31599992iop.187.1577456707193; Fri, 27 Dec 2019 06:25:07 -0800 (PST) MIME-Version: 1.0 References: <157655152334.24617.3401591731456466633.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Fri, 27 Dec 2019 09:24:56 -0500 Message-ID: To: "Panos Kampanakis (pkampana)" Cc: The IESG , "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org 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: Fri, 27 Dec 2019 14:25:10 -0000 Thanks, Panos; it all looks good, and thanks for considering my comments. Barry On Tue, Dec 24, 2019 at 10:50 AM Panos Kampanakis (pkampana) wrote: > > Hi Barry, > > This commit https://github.com/SanKumar2015/EST-coaps/commit/01f7014e2348= d09c0a1ff768eea7d53f4c5471f2 tries to address your feedback. The full discu= ssion is in https://github.com/SanKumar2015/EST-coaps/issues/153 > > Let us know if it does not make sense. > > Rgs, > Panos > > -----Original Message----- > From: Ace On Behalf Of Panos Kampanakis (pkampana) > Sent: Saturday, December 21, 2019 10:49 PM > To: Barry Leiba ; The IESG > Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@= ietf.org; ace@ietf.org > Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-= 17: (with COMMENT) > > Hi Barry, > > Thank you for the thorough review. We are tracking your feedback and our = responses in a git issue https://github.com/SanKumar2015/EST-coaps/issues/1= 53 We mostly confirm all your minor text changes and nit fixes. The TBD one= we will not fix as we are waiting on IANA. > > Let us know if something does not make sense. > > Rgs, > Panos > > > -----Original Message----- > From: Ace On Behalf Of Barry Leiba via Datatracker > Sent: Monday, December 16, 2019 9:59 PM > To: The IESG > Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@= ietf.org; ace@ietf.org > Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: = (with COMMENT) > > Barry Leiba has entered the following ballot position for > draft-ietf-ace-coap-est-17: No Objection > > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this =E2=80=94 a useful document. I have a bunch of comments,= but they=E2=80=99re all editorial. Please consider them, but there=E2=80= =99s not a need to give a detailed reply. > > -- Section 4 -- > > In that case, the > server MAY want to authenticate a client certificate against its > trust store although the certificate is expired (Section 10). > > Total nit: Why "want to"? Why not "server MAY authenticate"? > > As described in Section 2.1 of [RFC5272] proof-of-identity refers to > a value that can be used to prove that the private key corresponding > to the certified public key is in the possession of and can be used > by an end-entity or client. > > I find the passive voice to be quite awkward here, and suggest making it = active: > > NEW > As described in Section 2.1 of [RFC5272], proof-of-identity refers > to a value that can be used to prove that an end-entity or client is > in possession of and can use the private key corresponding to the > certified public key. > END > > the event of handshake message fragmentation, the Hash of the > handshake messages used in the MAC calculation of the Finished > message must be computed as if each handshake message had been sent > as a single fragment (Section 4.2.6 of [RFC6347]). > > I know this wording is directly from 6347, but I think it's unclear and w= ould like to suggest an alternative. The "as a single fragment" part is od= d, because I think what it's really saying is that it's computed as if it h= ad not been fragmented. My suggestion is to change it thus (and similarly = for the next paragraph after): > > NEW > the event of handshake message fragmentation, the Hash of the > handshake messages used in the MAC calculation of the Finished > message must be computed on each reassembled message, as if > each handshake message had not been fragmented (Section 4.2.6 > of [RFC6347]). > END > > If that's not correct, please take that as further evidence that it's unc= lear, and adjust accordingly. > > To alleviate this > situation, an EST-coaps DTLS connection MAY remain open for > sequential EST transactions which was not the case with [RFC7030]. > For example, an EST csrattrs request that is followed by a > simpleenroll request can use the same authenticated DTLS connection. > > Two total nits: > a. Comma before "which", please. > b. The "for example" needs some rewording to make it work: > NEW > For example, if an EST csrattrs request is followed by a > simpleenroll request, both can use the same authenticated > DTLS connection. > END > > -- Section 5.1 -- > > EST-coaps is targeted for low-resource networks with small packets. > Two types of installations are possible (1) rigid ones where the > address and the supported functions of the EST server(s) are known, > and (2) flexible one where the EST server and it supported functions > need to be discovered. > > This needs a colon (:) after "possible", a comma after "rigid ones", "a" = before "flexible one", another comma after "flexible one", and make it "its= supported". > > -- Section 5.5 -- > > Similarly, 2.04 > > is used in successfull response to EST-coaps POST requests (/sen, > /sren, /skg, /skc). > > There's odd spacing here; please fix it. And "successful" is misspelled. > > -- Section 5.7 -- > > If the server is very slow (i.e., minutes) in providing the response > (i.e., when a manual intervention is needed), > > I think you mean "e.g." for both of those, evidence for my general aversi= on to using Latin abbreviations that many people don't fully understand. I= t also feels odd to have the two examples separated in this way. I suggest= this: > > NEW > If the server is very slow in providing the response (for example, > manual intervention is required and it could take minutes for it > to respond), > END > > it SHOULD respond with > an ACK containing response code 5.03 (Service unavailable) and a Max- > Age Option to indicate the time the client SHOULD wait to request the > content later. > > Perhaps, "to indicate the time the client SHOULD wait before sending anot= her request to obtain the content." ? > > After a delay of Max-Age, the client SHOULD resend > the identical CSR to the server. As long as the server responds with > response code 5.03 (Service Unavailable) with a Max-Age Option, the > client SHOULD keep resending the enrollment request until the server > responds with the certificate or the client abandons the request for > other reasons. > > That last sentence reads very strangely to me. It SHOULD keep resending = the request until it decides to stop? What does that actually mean? > > Maybe what you're really trying to say is something like this?: > > NEW > As long as the server continues responding with > response code 5.03 (Service Unavailable) with a Max-Age Option, the > client will continue to delay for Max-Age and then resend the > enrollment request until the server responds with the certificate or > the client abandons the request for policy or other reasons. > END > > -- Section 5.8 -- > > In scenarios where it is desirable that the server generates the > private key, server-side key generation is available. > > This seems like a content-free sentence. Maybe this?: > > NEW > Private keys can be generated on the server. Scenarios where > that makes sense include those where it is considered more > secure... > END > > Of course, that does not eliminate the > need for proper random numbers in various protocols like (D)TLS > (Section 10.1). > > May I suggest this?: > > NEW > As always, it is necessary to use proper random numbers in > various protocols such as (D)TLS (Section 10.1). > END > > server or proxy to generate the private key and the certificate which > are transferred back to the client > > Needs a comma before "which". > > or the asymmetric keypair establishment method is out of scope of the > specification. > > "of this specification". > > [I-D.ietf-core-multipart-ct] containing a CBOR array with four items > > (Section 5.3) > > . The two representations > > More odd spacing. > > Dependent on the request, the > private key can be in unprotected PKCS#8 [RFC5958] format > > "Depending upon the request" > > In > the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key which is encrypted by the client-defined (in the CSR) > asymmetric public key and is carried in an encryptedKey attribute in > a KeyTransRecipientInfo structure. > > Long sentence that needs punctuation: comma after "operations", comma bef= ore "which", comma before "and". Also, I would move "(in the CSR)" a few w= ords later, after "public key". > > -- Section 7 -- > > It is recommended, based on experiments, > > to follow the default CoAP configuration parameters ([RFC7252]). > > Odd spacing, again. But "it is recommended to follow" is also odd Englis= h. I suggest making this active, rather than passive, thus: > > NEW > Implementations should follow the default CoAP configuration > parameters ([RFC7252]). > END > > I don't think the "based on experiments" bit adds anything, but if you wa= nt to keep it you can prepend "Experiments have shown that" to my suggestio= n. > > -- Section 9.1 -- > Don't you want to remove the "TBD" on "TBD287" here? Wasn't the "TBD" ju= st a flag to remind people that it hadn't been formally allocated yet? > > =E2=80=94 Section 10.1 =E2=80=94 > > It is important to note that sources contributing to the randomness > pool used to generate random numbers on laptops or desktop PCs are > not available on many constrained devices, such as mouse movement, > timing of keystrokes, or air turbulence on the movement of hard drive > heads, as pointed out in [PsQs]. > > The sentence order is wrong here. For example, mouse movement is not a c= onstrained device. The correct order is more like this: > > NEW > It is important to note that, as pointed out in [PsQs], sources > contributing to the randomness pool used to generate random > numbers on laptops or desktop PCs, such as mouse movement, > timing of keystrokes, or air turbulence on the movement of hard > drive heads, are not available on many constrained devices. > END > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Sun Dec 29 05:47:39 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CCD1200FB; Sun, 29 Dec 2019 05:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 LZebn8tDMLTB; Sun, 29 Dec 2019 05:47:27 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7092D1200FA; Sun, 29 Dec 2019 05:47:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D0iJr2rudpyvAl0ESRejKmWJ2yzCB/14aK5EIX8pKMpv+HFW+TvcJ/bY28+y3SzIz5cbgkWNDtDM5hlLwRZbWekIbwYm+W/LT+q+QEkrQhXLqnIAqEHBm2MJ9gbNljIbOLium+q+qQWQ3ANU1ejSddGCCK86B8y0o9DaCx7U//8udJcjAXlt/7y4cQ05lrVrJdmMC7owdFkomCtKehuf50BfMZFs/ZZ9uyG+7LAN8ae1kUloRcUFcI/F0rMzzZAtzrsNoHB9K0xQqcDNAsj6NkBbxnAbSDw8aJ8FMw2N+g23vDNBZRM2KJR8Ym8uAteY0WfcIR/p8+v92jCHTpfHFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ks07UscDVvIoG1XtZwfDfyZwj9y+q0yvC5NQc/qOQJU=; b=HVFn1z3H+o5MRk2xbfs4KJVHAgkchWc7zzY3PZ2cSdn3eWEeR0QZ+8zpZvvHP5tp/C/TKOtLh677ebPgvR3wRWavzffhq6/KeaSfQWjvdxdr6QWxvUK4UIKW1RJw7MxdgmHmXs01Hc+s8Gafn5/CZGqetzzjRyayKIyxbX1ulBlba+4r12r7zo5R/ol639b5YbxsNFJieaPw6kJW/3z2EhtsbocWBafRnybzPuxg4R60wp5ES24bMR54Q8gD34CCW5GJ257P8lm5+lD0eNl2i7u13+A0qNwQ7JY2UqHfbXe1//kuzjxmDDxBX0jp89SloI4LH4J0q9/5g/rxkHZoVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ks07UscDVvIoG1XtZwfDfyZwj9y+q0yvC5NQc/qOQJU=; b=XRIJ8+/MGttEny5v966edWMvYJfC8AX68peoTB4pgMa++A9gklwq1fUzsBDSMz98100UuOH9SQZxrm0GA8Uhq20QRJdrQAmoQe3n22IFt2+yRJV/mVj7YLUf/LvHRAX/JCwULunHEuAnk7z4vUB+U65/6u2aUBs11HjNOTByWFQ= Received: from VI1PR07MB5310.eurprd07.prod.outlook.com (20.178.12.13) by VI1PR07MB6399.eurprd07.prod.outlook.com (10.186.161.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.9; Sun, 29 Dec 2019 13:47:23 +0000 Received: from VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64]) by VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64%4]) with mapi id 15.20.2602.009; Sun, 29 Dec 2019 13:47:23 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "pkampana@cisco.com" CC: "ietf@augustcellars.com" , "draft-ietf-ace-coap-est@ietf.org" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) Thread-Index: AQHVtmtdqfoUtzXK1U2FXXdGCVFXHqfCeCqA//80zwCAAZk8gIAGH6KAgAfKUgA= Date: Sun, 29 Dec 2019 13:47:22 +0000 Message-ID: References: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b4c0b51c-05c4-46c0-1983-08d78c65a1d7 x-ms-traffictypediagnostic: VI1PR07MB6399: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(136003)(376002)(396003)(13464003)(199004)(189003)(66476007)(64756008)(5660300002)(316002)(53546011)(66556008)(6506007)(4326008)(26005)(71200400001)(186003)(91956017)(66446008)(110136005)(66946007)(86362001)(66616009)(2616005)(76116006)(54906003)(2906002)(478600001)(6486002)(966005)(44832011)(6512007)(8936002)(8676002)(4001150100001)(81166006)(36756003)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB6399; H:VI1PR07MB5310.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gKrFjrevIt7C24WM2x2s0tIR5o21sM80kmmKuTjpVITGGpvxzPjHTVDjB9hwaX2Gaw3onyP/juGB0ri1khttSxTeUXl+jiV37mLBSdd/fLolRTfXe/iELcxi/vrTFoIdKp4u10GP74WXpYF28rJG3c95ckDea9b/Sbj8dSngfrIddrUS/hNvPRDwV/IHkpSJ4RcSAbh7PI9AtfIYa2xohJperEYhO3yNFhmCTdcbsEJLeO3ZPEQnv7hu24T1Ma/mOJFEuMypUskvKmAsrW7nd6X1kurP4+Ron7CB4X6j8gtpNyt5mb7R54P6GJlisW6wnCtAz4C+6hNN+t/PtAcdvYNIELRyOExgPALPZbydQoU02emQsK9py38PkkO5AXeTTpx40GsWJ69ffJZDVJpSO8X6nE3wKvTlhWpQQBs9OIemkNcCQodRzXad8IbzGS4a4HbY5Hl2Gg/Nc8+jXPPJupmzfo/QjTMW2R5DT3019NPLmeYL2RgDRxiH2J/8RdAOCk3RBKShqiKwIa39yNAN4w== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-HxqKk0txPIAgDx+z36SA" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4c0b51c-05c4-46c0-1983-08d78c65a1d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2019 13:47:22.9549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: khcaq1RO9OPTGr2oD1yWQyMSEyhqxh398ctbd6QXANgJbeHRd5oHgOGldKBLLwg0l+2LedaKd+dkWaYzIxFW6q0B5nazTZzC89CpzF4hvMw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6399 Archived-At: Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS) X-BeenThere: ace@ietf.org 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: Sun, 29 Dec 2019 13:47:31 -0000 --=-HxqKk0txPIAgDx+z36SA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Yes, it makes sense I think it is good enough and cleare than the old text.= =20 Thanks Magnus On Tue, 2019-12-24 at 14:49 +0000, Panos Kampanakis (pkampana) wrote: > Hi Magnus,=20 >=20 > This commit >=20 https://protect2.fireeye.com/v1/url?k=3Dd1144abb-8d9d9086-d1140a20-0cc47ad9= 3c0c-fd2a1bbef3212950&q=3D1&e=3D548577ce-1875-434e-8e9a-6ccd51a577bd&u=3Dht= tps%3A%2F%2Fgithub.com%2FSanKumar2015%2FEST-coaps%2Fcommit%2F37f6337a3b3896= 32c18b77d3c4d > b8f28aabe9b63 tries to address your feedback. Let us know if it does not > make sense.=20 >=20 > Rgs, > Panos >=20 >=20 > -----Original Message----- > From: Ace On Behalf Of Panos Kampanakis (pkampana) > Sent: Friday, December 20, 2019 12:19 PM > To: Magnus Westerlund = ; > iesg@ietf.org > Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; > ace-chairs@ietf.org; ace@ietf.org > Subject: Re: [Ace] Magnus Westerlund's Discuss on > draft-ietf-ace-coap-est-17: (with DISCUSS) >=20 > Hi Magnus, >=20 > I see your point about the confusion the word "support" could cause. Our > intention was to make Block1 and Block2 MTI for the server, Block2 MTI fo= r > the client and Block1 optional to implement for the client only if it nee= ds > it. RFC7959 says " Implementation of either Block option is intended to b= e > optional. ". So, I think it makes more sense to replicate this language > instead of support. We will use "implement" in place of "support" in our > draft. >=20 > Regarding what happens if a client wants to send a large request and it h= as > not implemented Block 1, I don't think we should define that in our draft= . > RFC7959 says when you see a Block message you MUST process it or reject t= he > message. It does not mandate what the sender application does if it has a > large message and does not have COAP Blocks implemented. The right behavi= or > in this case is to depend on the lower layer protocol. So if COAP does no= t > support it, then IP. I do not think we should interfere with that in our > draft, it falls in general TCP/IP layering. >=20 > Does the above sound reasonable? >=20 > Panos >=20 >=20 > -----Original Message----- > From: Ace On Behalf Of Magnus Westerlund > Sent: Friday, December 20, 2019 4:34 AM > To: iesg@ietf.org; Panos Kampanakis (pkampana) > Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; > ace-chairs@ietf.org; ace@ietf.org > Subject: Re: [Ace] Magnus Westerlund's Discuss on > draft-ietf-ace-coap-est-17: (with DISCUSS) >=20 > Hi, >=20 >=20 > On Fri, 2019-12-20 at 05:01 +0000, Panos Kampanakis (pkampana) wrote: > > Thanks Magnus. > >=20 > > > The EST-coaps client MUST support > > > Block1 only if it sends EST-coaps requests with an IP packet size=20 > > > that exceeds the Path MTU. > > >=20 > > > I think the requirement for when Block1 is required to be supported= =20 > > > in the above sentence is unclear. Is the intention to say: An=20 > > > EST-coaps MUST support > > > block1 to be capable to send requests that would otherwise result in= =20 > > > the reliance on IP level fragmentation? > >=20 > > Yes, that was the intention. We will rephrase it to say > >=20 > > [...] The EST-coaps client MUST support > > Block1 only if it sends large EST-coaps requests that would > > otherwise result to IP layer fragmentation. > >=20 >=20 > Is it support or use block1 when the request is to big? I think the > combination of support and only results in uncertainty towards what the > implementor. Based on this reformulation I have the impression you want t= o > make the implementation optional if the expected EST-coaps request size i= s > less than what the IP MTU can send without fragmentation. However, that > leads me to ask what is the behavior of a node that suddenly are faced wi= th > a request that is larger. Refuse to send it with an error or still rely o= n > IP fragmentation? There is always the potential for a request being to la= rge > unless implementation support of block1 is mandated. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-HxqKk0txPIAgDx+z36SA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTIyOTEzNDcyNFowLwYJKoZIhvcN AQkEMSIEICUcMxLiFXBs9n6s/3sEKJQKx/Eprc6u+nIcjQPIVB/SMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAOpWXX0QhSCz+ 88yTvGApsB7vIbDyQgjCBDTgqIDZ01nLoxsDrDergf9qFuRjfpaTudhZ9NF3bCFobq8+uWY6wioX HBxkhg2UNw+Jsnai6L6nKgisvrowdXGxyzrArGg31p75Y4UXlxsyzpbiMoWGoW05J44YXRHf3Jhc uIplwl2xRTBCK2jG72nCGLtA+JqaqhlULw5niuHh8gVQbLEWwfj8StWcHdLTeD9cPU3ATrG9oIU2 DuASHCudshImQSZTXpdnbYAN+Dip4jrLcbX49F/LdNJ+lN3Zu2GtMenjuYLlJU0jCV1rVRM5Lk6o ab8zroXopt1P0I7WjSKRDOEZTAAAAAAAAA== --=-HxqKk0txPIAgDx+z36SA-- From nobody Sun Dec 29 05:51:43 2019 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E644F12081F; Sun, 29 Dec 2019 05:51:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <157762749093.999.17639575492481181541.idtracker@ietfa.amsl.com> Date: Sun, 29 Dec 2019 05:51:30 -0800 Archived-At: Subject: [Ace] Magnus Westerlund's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 13:51:37 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for resolving my Discuss in the upcoming version. From nobody Tue Dec 31 12:53:52 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7939D120046; Tue, 31 Dec 2019 12:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DMJ-5d1YZGE3; Tue, 31 Dec 2019 12:53:50 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BF6120013; Tue, 31 Dec 2019 12:53:49 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBVKrb7f018578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 15:53:40 -0500 Date: Tue, 31 Dec 2019 12:53:37 -0800 From: Benjamin Kaduk To: Carsten Bormann Cc: Klaus Hartke , Alexey Melnikov , ace-chairs@ietf.org, Jim Schaad , Ace Wg , draft-ietf-ace-coap-est@ietf.org, The IESG Message-ID: <20191231205337.GU35479@kduck.mit.edu> References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT) X-BeenThere: ace@ietf.org 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, 31 Dec 2019 20:53:51 -0000 On Fri, Dec 20, 2019 at 06:16:34PM +0100, Carsten Bormann wrote: > On Dec 20, 2019, at 17:34, Klaus Hartke wrote: > > > > I would prefer if draft-ietf-ace-coap-est didn't say anything here, > > since the Uri-Host and Uri-Port options and whether they should be > > omitted or not is entirely specified by CoAP [RFC7252].* > > Klaus has an important point here. > > We need to be **much more** vigilant about specifications messing with their normative references. > Saying how they are used, yes, but re-stating (or, worse, re-interpreting) normative material from those references is prone to creating dialects that no longer interoperate with their unadulterated originals. Unless these are hopelessly broken(*) and this is the only way to fix them, this is a MUST NOT. Indeed; thank you Klaus and Carsten for reiterating it. -Ben From nobody Tue Dec 31 13:56:00 2019 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8329E120052; Tue, 31 Dec 2019 13:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 56gnJjpmLNKc; Tue, 31 Dec 2019 13:55:58 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96C2120013; Tue, 31 Dec 2019 13:55:57 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBVLtO9h031154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 16:55:26 -0500 Date: Tue, 31 Dec 2019 13:55:23 -0800 From: Benjamin Kaduk To: Brian Campbell Cc: Ludwig Seitz , oauth-ext-review@ietf.org, Roman Danyliw , Daniel Migault , Jim Schaad , "ace@ietf.org" , drafts-lastcall@iana.org Message-ID: <20191231215523.GY35479@kduck.mit.edu> References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org 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, 31 Dec 2019 21:56:00 -0000 On Mon, Dec 23, 2019 at 02:32:15PM -0700, Brian Campbell wrote: > The OAuth Token Introspection Response registry > > already has an entry for "cnf", which makes the first request in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4 > rather problematic. Indeed. It seems like the right thing to do is probably just to drop that entry from the registration request (even though the existing description of "Confirmation" is kind of lousy), since we are using it with the same semantics as from 7800 and mtls. Sorry for missing that initially! -Ben