Re: [Ace] Review draft-ietf-ace-coap-est
Peter van der Stok <stokcons@bbhmail.nl> Wed, 04 July 2018 08:53 UTC
Return-Path: <stokcons@bbhmail.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 4074D130ED7; Wed, 4 Jul 2018 01:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t3pVa8xCJXcM; Wed, 4 Jul 2018 01:53:12 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FA4130EFF; Wed, 4 Jul 2018 01:53:11 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id D7CF21821F424; Wed, 4 Jul 2018 08:53:10 +0000 (UTC)
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:1:2:41:72:152:355:379:582:599:960:962:967:968:973:982:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1606:1712:1730:1776:1792:2068:2069:2198:2199:2525:2527:2528:2553:2559:2564:2682:2685:2689:2691:2692:2693:2734:2736:2859:2894:2897:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3308:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4362:4425:5007:6117:6119:6261:6657:6678:7875:7903:8603:8985:9025:10004:10848:11657:11658:11854:11914:12043:12109:12114:12257:12295:12663:12679:12740:12895:13137:13138:13139:13149:13150:13161:13229:13230:13231:13439:13972:13991:14096:14149:21060:21063:21080:21324:21433:21451:21627:30003:30012:30041:30054:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netc
X-HE-Tag: group79_38d246c284d59
X-Filterd-Recvd-Size: 12135
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf13.hostedemail.com (Postfix) with ESMTPA; Wed, 4 Jul 2018 08:53:10 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_47c04602636eba4035f80f0e6fd8c98b"
Date: Wed, 04 Jul 2018 10:53:09 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-coap-est@ietf.org, 'ace' <ace@ietf.org>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <032f01d41140$20027c80$60077580$@augustcellars.com>
References: <032f01d41140$20027c80$60077580$@augustcellars.com>
Message-ID: <58f0553599ed74abd4b97db321cb5f1f@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [82.95.140.48]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/GZ6jOtxoJ_NuXoIPgOMDLtjnEsI>
Subject: Re: [Ace] Review draft-ietf-ace-coap-est
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
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, 04 Jul 2018 08:53:27 -0000
Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate doing new media-types in that event. You appear to be doing a CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there is any reason for doing this. I would expect that the payload would be the ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what the text says and this is what you say. <pvds> What I wanted to do, and did not express very well. Keep the ASN.1 structure of the payload; (re-using code) Use straight binary coding instead of the base64-encoded (30% payload reduction) Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with multipart) Not sure if this needs a new media type, the http content-coding and transfer-coding registries were not very helpful. </pvds> * In section 5.0 - As written, the example of doing a query against /.well-known/core does not match my understanding of what would be return. It should only return those resources which have the rt field set on them. I do not understand why you believe that the following lines MAY be returned. Clarification of why you think this is true would be appreciated. <pvds> Thanks for your reaction, I hesitated between two choices. * Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc. * Make them all ace.est. There are no structure guidelines on rt= value, which complicates things. Looking forward to your (and others) opinion. </pvds> * Section 6 - Is there a need to have all of this description around TLS-unique? Do you have a reason to believe that people are going get this implemented wrong? <pan> This come from experience. The implementation we had done in the past did not implement it correctly, that is why we expanded on the TLS-unique. We will see about shrinking the text in the draft. </pan> * Section 7 - I think the figure has an error associated w/ it. The CA should be tied to the EST Server and not to the Registrar <pan> Thank you, we will fix that in the next iteration. </pan> * Section 7 - Your language is a bit sloppy around the terms of POP and POP linking. Unless it is really badly behaved, POP should never be broken by an RA. The POP is the signature on the request and not tied to the TLS channel. The POP linking is tied to the TLS channel and is broken by the changing of the TLS sessions (client <-> RA, RA <-> CA) <pan> Very good catch. We will tighten the language in the next iteration. </pan> * Section 7 - It is not clear to me that the SHOULD on reassembly of fragmentation is not a MUST. I doubt that any EST server is going to be able to deal with getting fragments of requests from a registrar in separate messages. This would be compounded if the proxy is handling multiple sessions at the same time. <pan> I think that is reasonable. We will address it. </pan> * Section 7 - It should be possible that when doing key generation for the protection of the private key to be end-to-end and it should not be necessary for the Proxy to decrypt and then re-encrypt the private key. It should not matter for this if one does either symmetric or asymmetric encryption of the private key. <pvds> Proxy: you mean Registrar. The wish is understood, we'll look into it. </pvds> * Section 7 - It is very possible that the private key generation function would be hosted on the proxy and not at the CA. I think that you might want to describe this as a normal configuration. (Just spotted this in the Security considerations. I think it should be here as well.) <pan> Yes, right. We need to be crisper on the document that end to end or proxy can provide this functionality. We will make sure it is clear in the text. </pan> * Section 9.1 - application/multipart-core should not be in the table of items for IANA to register. This is being done in a different document. If you want this table as a whole then it needs to be moved out of IANA considerations. <pvds> Absolutely right. Content-format is also specified I multipart-ct; did not see that. Will remove the entry. </pvds> * Section 9.2 - please expand this text some. You might want to look at https://tools.ietf.org/html/rfc7390#section-6.1 for a template. <pvds> Will do </pvds> Thanks Jim, This really helps to improve the document Peter, Panos Jim Schaad schreef op 2018-07-01 15:33: >
- Re: [Ace] Review draft-ietf-ace-coap-est Jim Schaad
- Re: [Ace] Review draft-ietf-ace-coap-est Peter van der Stok
- [Ace] Review draft-ietf-ace-coap-est Jim Schaad
- Re: [Ace] Review draft-ietf-ace-coap-est Peter van der Stok
- Re: [Ace] Review draft-ietf-ace-coap-est Jim Schaad
- Re: [Ace] Review draft-ietf-ace-coap-est Panos Kampanakis (pkampana)
- Re: [Ace] Review draft-ietf-ace-coap-est Jim Schaad
- Re: [Ace] Review draft-ietf-ace-coap-est Panos Kampanakis (pkampana)