Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Wed, 25 September 2019 16:57 UTC

Return-Path: <pkampana@cisco.com>
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 6CA1812012E; Wed, 25 Sep 2019 09:57:04 -0700 (PDT)
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, 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=Bz/wDRi2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sZsoFBb7
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 dfFiJ9p15N3U; Wed, 25 Sep 2019 09:57:00 -0700 (PDT)
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 767211200CE; Wed, 25 Sep 2019 09:57:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9456; q=dns/txt; s=iport; t=1569430620; x=1570640220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yuTBjtG/Dgm14fFK6pWH8btJd9WvLqXmCEr4zA0SgCw=; b=Bz/wDRi2TSLzhnI0+F7Vvi3qltEw0NCxXjbyiTeMDlYIc4xFqp52gfwq TEfgjGLHf+5P6Qe1eKQaQZZ9lFYq89EueW6AGFuJO4EdYB0HQLYyjIikO b3lzjvZffE+EngStzBDUqHTgahHn0oSRohxbJ2OpSmzA88jvvf1NRzoS0 s=;
IronPort-PHdr: 9a23:z7xfRB1F6FMHSVQFsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQEU7yKebjaSUSF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAACim4td/5BdJa1bCg4MAQEBAQECAQEBAQwCAQEBAYFTBQEBAQELAYFKUANtViAECyqHaQOEUoYmglyXdIEuFIEQA1QJAQEBDAEBGA0IAgEBhD8CgyojNAkOAgMJAQEEAQEBAgEFBG2FLQyFSgEBAQEDAQEQFRMGAQEsCwELBAIBCBEEAQEBHhAnCx0IAgQOBQgagwGBagMdAQIMpQ4CgTiIYYFyM4J9AQEFgTMBg2EYghcDBoE0AYwLGIFAP4ERRoJMPoJhAQECgTQTAhiDO4ImiTaDNBqCH48IjmkKgiKHBVyEOIQbhHGCNodLhCiJJoFcj1eGV5ECAgQCBAUCDgEBBYFSOIFBDwhwFTuCbBM9EBSBTgkDF4NPhRSFBDtzCoEfjlgBAQ
X-IronPort-AV: E=Sophos;i="5.64,548,1559520000"; d="scan'208";a="623799939"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Sep 2019 16:56:59 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x8PGuwUX029614 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Sep 2019 16:56:59 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 25 Sep 2019 11:56:58 -0500
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; Wed, 25 Sep 2019 12:56:57 -0400
Received: from NAM01-BN3-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; Wed, 25 Sep 2019 11:56:57 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iH00uPuuWm2ss4q2yRTq6LDobrCyDrOUxUE0GmA3AbnHeI88/GZ7gpQ/4tV9kD02dDlWwE3FFKIwYcr7jSqUZGOcf0skWsf/2dBqMnSIHRTBkIxAmQ9ETQ18gYRye4uT31+Sryh8TL0BcUwMWm8W6Fk1LQwUbjCF4ZwKfPK2fsdUWofGtImrx37cgKbm9JfbWi1xESeVvGvhKex3gF27+pMlEGIauWwjBPVv19szb5lywR/CsiW5VE6Eo5/dq00D6Jrw0zayG9uHEMJ13XRRGOR5I5ABN4PtOzXmAq5F1vXlW8T9PJltlmGClVi4sCfbHrtbhKKnOKGoCNaLxSePDA==
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=EkuHKONS6cNzIAWg/OZleBeWVQqVBvMiATtEa+IC2L0=; b=HuiniGmXjNj4TVqQLiNbm3apsH7MtZzK5YXphOpH68IEwE0L8ChwnR9rqOon3aWCCx4iQkY1Ey/P/SXu45xVCyG0Vg1lSuJ3u4qZRS1wt/lte+qGJ6VzHBJfFbhGZh8XLE+zLQbW8NKSmsmbA0qV4VQ5UmYtsnWDR8AkJMrjyoZ2Zdq+RQzqCLbOJUfUiJgN9PzGfW9iEcXE5yuSz1BOqPuYIMIKMpOQ7RxGo2kMHvt2VpmIarWIVadvlX40PXjWomVZaVCrALYzw5VzqUKFyHtXWrSYUx1iVIozYkoShMd3GkSaQdNvjXnm7sWCMd2e9H+ijygpXLlu3Lhoph5mgA==
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=EkuHKONS6cNzIAWg/OZleBeWVQqVBvMiATtEa+IC2L0=; b=sZsoFBb7cicMdP4zSZ5iMw3CHpZZLtzB0K7tZamm3Ptlp4QMG/2mD15GH6qD66Mpxn/L+20BLnfplui93uPfrp7OUgpWZU3cEEE65jHTALkzmnlbZ4JcdMsRpuWAR2/KJRFrwAik9X5x7gWVOOf7bzZNo9fUqMgCR+C7MFp0Do4=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2673.namprd11.prod.outlook.com (52.135.247.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Wed, 25 Sep 2019 16:56:56 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20%7]) with mapi id 15.20.2284.023; Wed, 25 Sep 2019 16:56:56 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Peter van der Stok <stokcons@bbhmail.nl>, Jim Schaad <ietf@augustcellars.com>, "draft-ietf-ace-coap-est.all@ietf.org" <draft-ietf-ace-coap-est.all@ietf.org>, Michael Richardson <mcr@sandelman.ca>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
Thread-Index: AQHVYlHhW15JBzQJJ0uFzt6/ui+Gy6cjRfMAgAAvCYCAACBegIAAPTSAgAB5+oCAAAtwcIAKSlxggAtbEACAAq4gMA==
Date: Wed, 25 Sep 2019 16:56:56 +0000
Message-ID: <BN7PR11MB2547CBE8D73F14BBF29A97AEC9870@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <20190901204340.GG27269@kduck.mit.edu> <6b482aaed0ce510c503984dfbac7286c@bbhmail.nl> <7cd78133c263214be535ec36734f7ec1@bbhmail.nl> <30070.1568030052@dooku.sandelman.ca> <20190909144232.GH18198@kduck.mit.edu> <7801.1568047103@dooku.sandelman.ca> <007901d5674b$9bc75e00$d3561a00$@augustcellars.com> <008e01d56788$985bbda0$c91338e0$@augustcellars.com> <BN7PR11MB254736E735A5779C1223E324C9B60@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB2547CF79EFAF6D77BD48C607C98C0@BN7PR11MB2547.namprd11.prod.outlook.com> <20190923224828.GT6424@kduck.mit.edu>
In-Reply-To: <20190923224828.GT6424@kduck.mit.edu>
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:1005::189]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dad97862-082c-4a1d-b393-08d741d95fd5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN7PR11MB2673;
x-ms-traffictypediagnostic: BN7PR11MB2673:
x-ms-exchange-purlcount: 9
x-microsoft-antispam-prvs: <BN7PR11MB2673FDFED4D1EC64168FC008C9870@BN7PR11MB2673.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01713B2841
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(51444003)(189003)(199004)(13464003)(14444005)(966005)(81166006)(81156014)(6116002)(6506007)(8676002)(478600001)(99286004)(316002)(53546011)(305945005)(229853002)(102836004)(54906003)(7736002)(186003)(46003)(14454004)(74316002)(8936002)(256004)(2171002)(6246003)(7696005)(66446008)(71200400001)(476003)(9686003)(486006)(6306002)(6916009)(66946007)(66556008)(6436002)(86362001)(446003)(66476007)(5660300002)(76116006)(76176011)(64756008)(33656002)(4326008)(71190400001)(2906002)(55016002)(25786009)(52536014)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2673; 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-message-info: d/siusWL2hMlG9O0EjD9h1MvGabLPHIxfBYp8r8Y1QS5hlabiRVDv6xgUKcXq+AKkBl/0xHNpEEW6IdZIbwJv1TeyIi7ZO0ptsEn4jFrzMIwM1YjPIJ+u7w2yY/bCgvXivsLNAJJ1IyKROMMygJ+bqwY+9yEhC1aUSFowwHLrldHXsoUa84bhhUWpF7h5pzNCDRBBi3tZKhCjyI7gx4J1ABpLN8S2Tj/grp+2whe3kSBNqmCzhjeptwnkAy4g6HNHhYoZ/c9gGy9qiDHf+Bf/Cy7zpVesed6bxNp+hKvEBo4AFjZBjWMbg430jPgqT2TP9ApdPHDM/u8MZBzkbI3KrVVpyYBkf3ngmFrGCuvAOk4tOUfoKwly9fnEZwGoOpTV27Flw7sc9/KDurmKt+BmVe/rXFxFydaNv74P3R1pr4G3tAD1aSU0rC1iQa51OSWgy0QdU/OcgjrfyQ+7H9mnQ==
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: dad97862-082c-4a1d-b393-08d741d95fd5
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2019 16:56:56.5095 (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: wNLjEwTpYF3JnvDYwtEQuA48cGEoeWkqC9EyOINcotIuvB+UnJym/xNpXiSXap7zpMnkPzLMastSKkd6qc4syQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2673
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/T1RjnyCtXM-EdQpaGCeQnnU-xyw>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 16:57:05 -0000

Hi Ben,

Thank you again for the additional feedback. 

The changes are summarized in the git issue https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-535065314 I mostly made all the suggested text changes, summarized our discussion about extended-master-secret. I also made a change in Fig 2 and Fig 3 to address the issue you caught with the /128 blocks. 

The diff is here https://github.com/SanKumar2015/EST-coaps/commit/d16c53d3360430b5587021dc1a2d31f668c0c0fe . And a minor nit fix in https://github.com/SanKumar2015/EST-coaps/commit/ff5b303781231e34571352cb07fb895d5ecab791 

I will reupload early next week. Please check out the issue in case you have further comments. 

Panos


-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of Benjamin Kaduk
Sent: Monday, September 23, 2019 6:48 PM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Cc: Peter van der Stok <stokcons@bbhmail.nl>; Jim Schaad <ietf@augustcellars.com>; draft-ietf-ace-coap-est.all@ietf.org; Michael Richardson <mcr@sandelman.ca>; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Panos,

Sorry for the slow response here -- I was in telechat-prep mode last week.

This is in pretty good shape, and I wanted to especially thank you for the presentation in the github issue -- that format was extremely helpful for me.

I think we will probably need to upload one more minor revision before I initiate the IETF LC; please seem my comments below.


In Section 4, I think we need to put the "for" back in "requests for a trusted certificate list".

Also, refresh my memory: did we decide that there's no need to explicitly mandate the use of the "extended_master_secret" TLS extension?

I'd also change the note about supported_groups vs. Supported Elliptic Curves to read "In addition, in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups."

I think we can move /csrattrs to the bottom of Table 2 (thank you for changing Table 1!).

With the changes to the example in Figure 3, can you walk me through the block-size negotiation?  Quoting:

    POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
		      |
       ... Immediate response when certificate is ready ...
		      |
      <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
    POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128)           -->
      <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}

So the ACK to the final fragment of the POST includes (2:0/1/256), or the first fragment of a 256-byte-fragmented version of the response.
The client then goes and asks for (2:1/0/128), which is the second fragment of a 128-byte-fragmented version of the response.  Is that just going to be the last 128 bytes of the thing it already got from the server?  If so, is that something it would actually do (e.g., if it had to drop part of the server's response due to a buffer-size limitation) or is it not possible to only have part of a fragment (so it would need to either ask for (2:0/0/128) or (2:2/0/128)?

It looks like you removed the text about "[the two representations] do not have to be in a particular order since each representation is preceded by its Content-Format ID" based on my remark about core-multipart-ct; that document has since been approved by the IESG and is explicitly confirming that there is no specific ordering requirement (in contrast to multipart/mixed), so we could put that clause back in this document if desired.

I consider it more likely than not that a directorate reviewer will want to tweak the added language at the end of Section 5.8 explaining our divergence from RFC 7030; if you want to preemptively reword, my suggestion would be "Although [RFC7030] strongly recommends that clients request the use of CMS encryption on top of the TLS channel's protection, this document does not make such a recommendation; CMS encryption can still be used when mandated by the use case."

Thanks!

-Ben


On Mon, Sep 16, 2019 at 05:38:59PM +0000, Panos Kampanakis (pkampana) wrote:
> Hi Ben,
> 
> I think we have now addressed all your feedback from the AD review. A big chunk of the changes were agreed upon in the list emails threads. 
> 
> The iteration that we are planning to upload that includes all the 
> changes is at 
> https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c
> oap-est.txt
> 
> The summary of all your comments and what went into the text is in the 
> git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To 
> break it down
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has most of the changes agreed on the list.
> -  https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 has an answer to your question about addressing the tls-unique issue in a new draft. 
> - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 has the last changes in response to your feedback that went into the draft after Peter uploade the -13 iteration. 
> 
> Two places to pay attention to is that I removed the
> >   It is strongly RECOMMENDED that the clients request that the returned
> >   private key be afforded the additional security of the Cryptographic
> >   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
> >   security to protect against unauthorized disclosure."
> and the
> >   The corresponding longer URIs from [RFC7030] MAY be supported."
> The rationale behind that is in the git issue. 
> 
> Please have a look and let us know if there is anything missing. Otherwise we will upload at the end of the week. 
> 
> Rgs,
> Panos
> 
> 
> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Panos Kampanakis 
> (pkampana)
> Sent: Tuesday, September 10, 2019 12:18 AM
> To: Jim Schaad <ietf@augustcellars.com>; 'Michael Richardson' 
> <mcr+ietf@sandelman.ca>
> Cc: draft-ietf-ace-coap-est.all@ietf.org; 'Benjamin Kaduk' 
> <kaduk@mit.edu>; ace@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
> Hi Jim,
> 
> We are tracking all of Ben's feedback here 
> https://github.com/SanKumar2015/EST-coaps/issues/150
> 
> The fixes that have gone in the draft so far are after each comment. There are still some that we still need to update after the threads converged. 
> 
> Panos
> 
> 
> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Jim Schaad
> Sent: Monday, September 09, 2019 11:34 PM
> To: 'Michael Richardson' <mcr+ietf@sandelman.ca>
> Cc: draft-ietf-ace-coap-est.all@ietf.org; 'Benjamin Kaduk' 
> <kaduk@mit.edu>; ace@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
> Authors,
> 
> Are we ready to produce a new draft that addresses most, if not all, of Ben's comments?  Do we have a pull request to deal with this that we can point to?
> 
> Jim
> 
> 
> -----Original Message-----
> From: Jim Schaad <ietf@augustcellars.com>
> Sent: Monday, September 9, 2019 1:17 PM
> To: 'Michael Richardson' <mcr+ietf@sandelman.ca>; 'Benjamin Kaduk'
> <kaduk@mit.edu>
> Cc: draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org
> Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
> 
> 
> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Monday, September 9, 2019 9:38 AM
> To: Benjamin Kaduk <kaduk@mit.edu>
> Cc: draft-ietf-ace-coap-est.all@ietf.org; ace@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
> 
> Benjamin Kaduk <kaduk@mit.edu> wrote:
>     >> So, on a constrained device, I'd like to know what to expect (what to
>     >> code for).  While I do'nt particularly care for 
> server-generated keys,
>     >> it should probably be specified correctly.  I see that the complexity
>     >> of sorting this means that I think that Content-Format 284
>     >> (unprotected) will get used most often.
> 
>     > Your constrained device is probably only going to implement one cipher
>     > [mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
>     > otherwise, classic EnvelopedData.
> 
> Yes, but each constrained device type might have a different set, and 
> the EST server for such an installation has to figure out how to send 
> the right thing.
> 
> [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says 
> that the DecryptKeyIdentifier must be present.  This will provide the 
> EST server a method to identify the correct key and the correct 
> symmetric encryption algorithm.
> 
>     >> I think that we could go to TLS Exporter right now, but it would take
>     >> some work.
> 
>     > I'd rather have both classic-EST and coap-EST benefit than just
>     > coap-EST.
> 
> So you'd agree to deferring this to a document (maybe in LAMPS?) that 
> would
> Updates: 7030 and this document.

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