Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-26: (with DISCUSS and COMMENT)
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 16 September 2019 19:11 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED161200B7; Mon, 16 Sep 2019 12:11:24 -0700 (PDT)
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 EfG3GkUuUsen; Mon, 16 Sep 2019 12:11:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E8512004A; Mon, 16 Sep 2019 12:11:17 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6E4D63897E; Mon, 16 Sep 2019 15:09:38 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B47D1BAE; Mon, 16 Sep 2019 15:11:16 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org
In-Reply-To: <156865094606.28176.939234039941542736.idtracker@ietfa.amsl.com>
References: <156865094606.28176.939234039941542736.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 16 Sep 2019 15:11:16 -0400
Message-ID: <18821.1568661076@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/I7RoAfnGJstJKrHRrRUeqQTT8DI>
Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-26: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 19:11:25 -0000
https://tinyurl.com/y2kmjqmm for diff. Alexey Melnikov via Datatracker <noreply@ietf.org> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > Thank you for this document. Despite comments/DISCUSSes raised, this was a good > read. > I agree with DISCUSS points from Alissa, Adam and Roman. > 1) Resolved > 2) Resolved > 3) Resolved > 4) In 5.8.1: > Format of different fields is not defined in enough details, so this is not > interoperable. Please specify what format is used for dates and nonces. Date now references rfc3339. (Why doesn't rfc8259 reference 3339?) <t> The date is in <xref target="RFC3339" /> format, which is consistent with typical JavaScript usage of JSON. </t> <t> The nonce is a string, as provided in the voucher-request, and used in the voucher. If no nonce was placed in the resulting voucher, then a value of null SHOULD be used in preference to omitting the entry. While the nonce is often created as a base64 encoded random series of bytes, this should not be assumed. </t> > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Some comments below are still applicable to -26, but some might be out of date. > The first mention of HTTP 1.1 needs a Normative reference. We now refer to HTTP persistent connections, and reference RFC7230 section 6.3. doc> As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in doc> this extension, including the scheme, iauthority, and ipath. As a doc> consideration to constrained systems, this MAY be reduced to only the doc> iauthority, in which case a scheme of "https://" and ipath of doc> "/.well-known/est" is to be assumed, as explained in section doc> Section 5. > This is not a problem per se, but mixing absolute URIs and iauthority in the > same field makes me rather uncomfortable. Maybe you can define ABNF for this > field to make it crystally clear what is allowed here. This would also avoid > the need to use SHOULD and MAY above. The field contains either: authority OR scheme //: authority / path As "/" is not legal in authority, which can be deduced, as explained: The registrar can assume that only the 'authority' is present in the extension, if there are no slash ("/") characters in the extension. I'm not sure that ABNF would make it clearer to implementers. > In 2.3.2: "https" URI scheme needs a Normative reference. Now references rfc7230 section 2.7.3 > 2.7. Cloud Registrar > If the pledge uses a well known URI for contacting a cloud registrar > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to > authenticate service as described in [RFC6125]. > Just referencing RFC 6125 is not clear enough, as there are lots of parameters > that need to be specified: > a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed > b) are wildcards allowed in any of these? I don't know, as we haven't defined how the cloud register would work, and did not intend to define that in this document. A very drafty draft, draft-friel-anima-brski-cloud-00 has recently been posted. The only reason we talk about this at all, is that we can it clear how this option would fit into the pledge state machine. We also say this because we want to make sure that a built-in trust anchor is used, and not some trust anchor that might have been received provisionally, or via the /cacerts EST method. The pledge would contain the logic to connect, and would know what name to use, and would know how to validate it. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima] Alexey Melnikov's Discuss on draft-ietf-a… Alexey Melnikov via Datatracker
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Michael Richardson