Re: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 October 2019 18:23 UTC
Return-Path: <mcr@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 0672A12092C; Wed, 16 Oct 2019 11:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 32SDNGotIJ46; Wed, 16 Oct 2019 11:23:03 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F837120116; Wed, 16 Oct 2019 11:23:02 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:64:42:5650:5f0a:e07a:7e5f]) by relay.sandelman.ca (Postfix) with ESMTPS id 570051F455; Wed, 16 Oct 2019 18:23:00 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 13225E8B; Wed, 16 Oct 2019 20:23:53 +0200 (CEST)
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: <157122308193.7928.3899842894004508765.idtracker@ietfa.amsl.com>
References: <157122308193.7928.3899842894004508765.idtracker@ietfa.amsl.com>
Comments: In-reply-to Alexey Melnikov via Datatracker <noreply@ietf.org> message dated "Wed, 16 Oct 2019 03:51:21 -0700."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 16 Oct 2019 20:23:53 +0200
Message-ID: <30385.1571250233@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/gyfv2v5SyBudJD1ZPpvTiKb5dfU>
Subject: Re: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with 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: Wed, 16 Oct 2019 18:23:10 -0000
Alexey Melnikov via Datatracker <noreply@ietf.org> wrote: > Some comments below were still applicable to -27, but some might be out of date. > In 2.3.2: (I've updated the text below from the -28 version, which does not use IRLs) doc> A complete URI MAY be in this extension, including the 'scheme', doc> 'authority', and 'path', The complete URI will typically be used in doc> diagnostic or experimental situations. Typically, (and in doc> consideration to constrained systems), this SHOULD be reduced to only doc> the 'authority', in which case a scheme of "https://" ([RFC7230] doc> section 2.7.3) and 'path' of "/.well-known/est" is to be assumed, as doc> explained in 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 above reference to section 5 is vague, and I think it has gone lame, and I've removed it. There is a single sentence in 5.0 that probably used to say more. The logic here (on the Registrar): if(strchr(text, '/')) { /* WHOLE URL is present */ url = text; } else snprintf(somebuffer, sizeof(somebuffer), "https://%s/.well-known/est", text); url = somebuffer; } ruby: def self.canonicalize_masa_url(url) return nil unless url if !url.blank? and !url.include?("/") url = "https://" + url + "/.well-known/est/" end # always have a trailing / unless url[-1]=='/' url = url + '/' end url end I'll have to think about how to explain this in ABNF. I would need to reference the RFC7230 ABNF and create some hybrid item. It seems like a lot. > In 2.3.2: "https" URI scheme needs a Normative reference. I think that the new text deals with this already. > 2.7. Cloud Registrar doc> If the pledge uses a well known URI for contacting a cloud registrar doc> an Implicit Trust Anchor database (see [RFC7030]) MUST be used to doc> 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've added text:n The use of a DNS-ID for validation is appropriate, and it may include wildcard compnents on the left-mode side. {i.e. what browsers and curl does. I feel that surely this must be specified somewhere more precisely?} -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima] Alexey Melnikov's No Objection on draft-i… Alexey Melnikov via Datatracker
- Re: [Anima] Alexey Melnikov's No Objection on dra… Michael Richardson