Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
Esko Dijk <esko.dijk@iotconsultancy.nl> Thu, 14 February 2019 08:15 UTC
Return-Path: <esko.dijk@iotconsultancy.nl>
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 DA21613102D for <ace@ietfa.amsl.com>; Thu, 14 Feb 2019 00:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.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 7GvDWseO8Nbb for <ace@ietfa.amsl.com>; Thu, 14 Feb 2019 00:15:12 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150092.outbound.protection.outlook.com [40.107.15.92]) (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 A5F3C12D7F8 for <ace@ietf.org>; Thu, 14 Feb 2019 00:15:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FQj7pWC0fR5b6cN9Xk4eGl4gVGf+6F+s1CXovJDiuOM=; b=RLEiyE9mrwQ0va4XggxdLXdooZ5J4RLY3zVoOw30PQ4rXQJLv3g3is2gIqIhMlR3plEWGs1OoYMLeTbWHMdI5kOiMCrSRO+zGUee3qyz7fnlU1TyUx0p8+arODMeGGDdWg+gCelcGjTPf1wW+lZ+mKRtfwI1N+1wScnQ/T5SwSk=
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0181.EURP190.PROD.OUTLOOK.COM (10.172.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Thu, 14 Feb 2019 08:15:07 +0000
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::2d19:ef79:d153:7627%6]) with mapi id 15.20.1601.023; Thu, 14 Feb 2019 08:15:07 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Klaus Hartke <hartke@projectcool.de>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
Thread-Index: AdTC4NsGsEh+3phhQKaxfGxN5m15WwABW3AAAAwBqoAAASTPAAAqe3YAAB2oTRA=
Date: Thu, 14 Feb 2019 08:15:07 +0000
Message-ID: <DB6P190MB00542EA47E4BF9B619AB3916FD670@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
References: <DB6P190MB0054313C1BA6E125FA07813BFD650@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM> <CAAzbHvaMTXgzKtMbpVpbXfT1EKjJu4L3zM5hesrNPgG+BqfoJw@mail.gmail.com> <9594d00cd7bc43e496c2c5073481e637@XCH-ALN-010.cisco.com> <CAAzbHvbD0B0A6L4-YCXVRhmKMRCUmTWaOJrtSZOQkbRfhsQBuQ@mail.gmail.com> <e1ebbbe0dd4541778842878c93933f5d@XCH-ALN-010.cisco.com>
In-Reply-To: <e1ebbbe0dd4541778842878c93933f5d@XCH-ALN-010.cisco.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl;
x-originating-ip: [188.207.86.114]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ea0aabdc-0bb3-4bd5-4f80-08d6925487f5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0181;
x-ms-traffictypediagnostic: DB6P190MB0181:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DB6P190MB0181DA0293E1B5714FDE3802FD670@DB6P190MB0181.EURP190.PROD.OUTLOOK.COM>
x-forefront-prvs: 09480768F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(346002)(39830400003)(376002)(51444003)(189003)(199004)(13464003)(106356001)(3846002)(53546011)(6116002)(305945005)(74316002)(6506007)(33656002)(105586002)(110136005)(74482002)(6436002)(55016002)(7736002)(53936002)(6246003)(86362001)(229853002)(93886005)(66066001)(186003)(102836004)(25786009)(2906002)(44832011)(97736004)(14444005)(446003)(256004)(6306002)(476003)(486006)(11346002)(316002)(81156014)(966005)(8936002)(14454004)(68736007)(7696005)(71200400001)(81166006)(508600001)(71190400001)(561944003)(8676002)(26005)(76176011)(99286004)(9686003)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0181; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: 1;DB6P190MB0181;23:UkuY9banYgX7aYSy2cxpy44aJoS0bQfoCBwHDvDexvxmSDn9/3YklBiuH0HpOnFJnK8d91cNOyIv6VrTLVxvWEwR+NkDnF0Rc7hzGXV8ZmAU8QZxJp4R33vycFKdoZ8rw4clCpw+jag7lJg5qW+hdzDjPRZHrBmBA1zQnC8hEPxz1AtxOWFG23PnuTmvAMQjVEtrjQOWATvu+wumyEZRNkhtQKpDvQ8NuKdTQh+IMVceetvjDLJolRVhk8Vw34KUS5olFOT7jBROE4La50hP1C+XZ640FEFZnY8D7aOM6qi0u22g6t9JbS9WRhSgBpxf1kdd3WhED9tpA2jGCy2kKQEoRlSjXFik9yaiOsYlTEquTW5vu2sFycu/bEfqvAPhU4cPYhXcBb2C/+izICOEJ9fmTEbDiJMeQHyjDGFsgMX+EZjG5jyoH1gmz6iSeT8WCOXjGIEGrM+DTd8qdq+GgNX1la5uqNwltXrkEtPnowD62it3YUkW3mpbzy4bWMHhN1vIEdMUX4Zcl1vbB85+9d44er6plVuwzzBWUhfRKMfqed9Y3kbTa5SHmg06A+F5SjG4x7HG7jnNmXakGQoNvwiqArB06XFOYG2xMUVUU1RlkiZdTj9yn21aWidboLfNjCzddVI5oJthKsSm2hGbMu6ArrewaE72QYhcKiwRCnrOIhoj758eLQdm9XrMq2tnyFhFkd6CBsz7l3z4QFCOf6G5LNnJ06tRvUTKf23KUIQPKnHvv3HqTtVoaTWiQ3oE8hnX0Zbp1H7ms78FzTBQ4wwx5fHMiYyW4whYx8oJiNZUISyIGnIRF+nL5GdVIFEVazgklVYdeVrSV7uMOHuBsdP7QQddSZvnuLEeNjyQTctTHnJlpfqwhl1bVcTvmirmLDu5bne3GgTifO3g1Pf4/Xxifn3koJfe194md2kTFFu+zlXlZP6Y9wxMyLpZkAApKxa0QdX/5IG9cxn7boh9/VQIXr6GLeAZQ66/BGvIm2DpBI5urxciQIc0OKPx5J1NDufTovTVeQLODPCo1dkhhYPGrXwxgFDSHpe5Vu+iXe3WRZY+DWjzgDxjbcVBCidnmMzu3f7DKGs+Xr64D2auRivXHzaVrwNomd5IdkklNbdXchxK9NFzf8isuzQUw24mOkKmZC7lEAv017b+/X25KPJdx3NtkuywFO4fmH8HUHz5999opf/rYOcLF6+4h1hth8gCf3gh4MkVOvHIM/9FBiuS4Q2DRX6HvcAgFHhp0Vlq13MU9uF2/jPPslV/2pQ6I6BSfvMqGADmq219qw4yUX1PFOABQLST9YQzs1kcjsaTYg+U9qnbDDqPOQrM7mXhLl+zC5QihBmATUGqPlu1nQ==
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: +C1RMpMWfFfDOMfki6G4P1/KtQRBzgfUchq1ieV2S1EOvMBbAIpepxm4DXXG2hqcQCnJ+baPb9/SVJ9LXfK9+xO3vO6BFnkGuC72dQC5Nbqe7lJjjMz52nyg3WiSEIRrKuHwsmUa8Iil9epUK/3xEZOPkej6ncolH9hwnaXf1uUn2NQB4YC7sx5rAUjdyHZzDTanutxdjwINCGMnE0HwLk4oXV+9hVZIQsf3FuevqKn+HtQ6FFjoRrHAGh7YZgh+AJJe5v9caQZ4x7+aSh+qJgCMFzjoROd6VOI4LNeAIMX94XMVdfRCtwi+b06j5XxBDeTavbMJSsYXP3edV+Qte7ZG+h3Zn1BmnijomIPnl0++VBAkfWFJ5vrbwL4lP72dI2nLUuatjssAUjK9Ep7VsGvwoLQjHinLBPrY/G6hP/U=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-Network-Message-Id: ea0aabdc-0bb3-4bd5-4f80-08d6925487f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 08:15:07.3661 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0181
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/CZOvbfVIEB6-ijJ8V0jQqIBEtCQ>
Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287
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: Thu, 14 Feb 2019 08:15:15 -0000
Using a query is a good solution here; I would propose a query argument as short as possible because we deal with constrained networks and we want to avoid needless parsing in this case - the server only needs to select between two format choices here, returning X.509 cert or PKCS#7 with cert. The choice of encoding of the private key format PKCS#8 or CMS-EnvelopedData is depending on the payload the client sent in the /skg request, as written in the draft. So to request PKCS#7 format , the default: POST /est/skg And to request X.509 format, the alternative that the server MAY support: POST /est/skg?x The latter has the benefit of small Option size, and can easily scale to many more formats/parameters in the future if really needed. In light of this discussion thread we would need to update the "ct=....." link format descriptions in the draft also, e.g. OLD: </est/skg>;rt="ace.est.skg";ct="62 280 284 281 TBD287" NEW: </est/skg>;rt="ace.est.skg";ct=62 Note that this format is now CoAP-correct but has the drawback that the client can't see whether the optional TBD287 is supported or not in the /skg function. Best regards, Esko Esko Dijk IoT Consultancy | Email/Skype: esko.dijk@iotconsultancy.nl -----Original Message----- From: Panos Kampanakis (pkampana) <pkampana@cisco.com> Sent: Wednesday, February 13, 2019 18:52 To: Klaus Hartke <hartke@projectcool.de> Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>; ace@ietf.org Subject: RE: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287 > CoAP is not aware that the representation happens to contain embedded representations and therefore the content negotiation mechanism cannot be used directly to negotiate the formats of those. > The value of the Accept option in the request needs to be registered in the IANA registry and the value of the Content-Format option in the response must be the same as Accept value. > Of course, one possible solution is to drop the use of content format ID 62 entirely and just register one ID for each possible combination. (But then the client can still only include at most one Accept option in its request.) Hmm, that is a fair point. I don't think it is warranted to register four more content formats for all possible format combinations in the multipart response. It looks to me that your proposal of using Uri-Query in the request in order for the client to define the supported formats of the requested resource/response is a good one. -----Original Message----- From: Ace <ace-bounces@ietf.org> On Behalf Of Klaus Hartke Sent: Tuesday, February 12, 2019 4:36 PM To: Panos Kampanakis (pkampana) <pkampana@cisco.com> Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>; ace@ietf.org Subject: Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287 Panos Kampanakis wrote: > Well, RFC7252 refers to a singular content format. In our case we are talking about a dual content format (286 or 281 and 280 or 284) returned in a 62 multipart-content. Would it be a violation of RFC7252, since RFC7252's text had single content format responses in mind only? >From the point of view of CoAP, there is just a representation with content-format 62. A client can indicate that it accepts a representation with content-format 62; the server then is required to return either a representation with content-format 62 or an error. CoAP is not aware that the representation happens to contain embedded representations and therefore the content negotiation mechanism cannot be used directly to negotiate the formats of those. >> Maybe the draft-ietf-core-multipart-ct should extend the semantics of "Accept" to cover this case? A content format is not a protocol extension and cannot override the protocol definition. > I think that is good idea. The simplest way to do that would be encode the 3 content formats (for example 62, 286 and 280) into a single CF included in the Accept option which tells the server what combination of content formats to send back. Would that violate RFC7252 because the Content-Formats needs to be actual CFs defined in the IANA registry and not a combination of them? The value of the Accept option in the request needs to be registered in the IANA registry and the value of the Content-Format option in the response must be the same as Accept value. Of course, one possible solution is to drop the use of content format ID 62 entirely and just register one ID for each possible combination. (But then the client can still only include at most one Accept option in its request.) > From a previous thread with Jim S., I was under the impression that In the virtual CoAP WG meeting a month back we went through in some explicit detail that both Content-Format and Max-Age have no meaning when appearing on a request and therefore should not be there. Max-Age doesn't have a meaning in requests and therefore must not be there. I'm not sure where that about the Content-Format option comes from. If a POST request has a payload, then the format of that payload is described by a Content-Format option. (A GET request doesn't have a payload and therefore must not include a Content-Format option.) Klaus _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
- [Ace] ace-coap-est-08: using /skg with Accept Opt… Esko Dijk
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Klaus Hartke
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Panos Kampanakis (pkampana)
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Klaus Hartke
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Peter van der Stok
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Panos Kampanakis (pkampana)
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Esko Dijk
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Michael Richardson
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Michael Richardson
- Re: [Ace] ace-coap-est-08: using /skg with Accept… Esko Dijk