[Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Alexey Melnikov via Datatracker <noreply@ietf.org> Thu, 11 July 2019 13:20 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73E120077; Thu, 11 Jul 2019 06:20:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com>
Date: Thu, 11 Jul 2019 06:20:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI0UtlJVZ9otY7M>
Subject: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Jul 2019 13:20:39 -0000
Alexey Melnikov has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this document. Despite comments/DISCUSSes raised, this was a good read. 1) In Section 5: o In the language of [RFC6125] this provides for a SERIALNUM-ID category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. The SERIALNUM-ID whitelist is collated according to manufacturer trust anchor since serial numbers are not globally unique. I think now you are just inventing things. Please define what exactly SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed. 2) In 5.6: assertion: The method used to verify assertion. See Section 5.5.5. Section 5.5.5 doesn't define syntax of this field in enough details to implement. Can it contain one of the allowed values (like C enum)? 3) In 5.8 This is done with an HTTP GET using the operation path value of "/.well-known/est/requestauditlog". Here you say to use HTTP GET. The registrar SHOULD HTTP POST the same registrar voucher-request as But you only define how to use POST. I think the first "GET" is supposed to be "POST". 4) In 5.8.1: Format of different fields is not defined, so this is not interoperable. 5) In 8.1: This document extends the definitions of "est" (so far defined via RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ well-known-uris.xhtml" registry as follows: o add /.well-known/est/requestvoucher (see Section 5.5 ) o add /.well-known/est/requestauditlog (see Section 5.7) The .well-known URIs IANA registry doesn't list anything below the first level (i.e. "est" in your case). So I think you really want to have 2 IANA actions here: a) Add the reference to this document as another reference for "est". b) create a new registry of "est" URIs and add your 2 URIs above to it and also populate other entries from the original EST RFC. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The first mention of HTTP 1.1 needs a Normative reference. 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices Upon successfully validating a voucher artiface, a status telemetry MUST be returned. See Section 5.7. "artiface" is an unfortunate typo. I think you meant "artifact" here. In 2.3.2: As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in this extension, including the scheme, iauthority, and ipath. As a consideration to constrained systems, this MAY be reduced to only the iauthority, in which case a scheme of "https://" and ipath of "/.well-known/est" is to be assumed, as explained in section 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. In 2.3.2: "https" URI scheme needs a Normative reference. 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? 4. Proxying details (Pledge - Proxy - Registrar) In order to permit the proxy functionality to be implemented on the maximum variety of devices the chosen mechanism SHOULD use the minimum amount of state on the proxy device. What does this mean? How can compliance with this SHOULD be evaluated? I think you want to use lower case "should" here. In 5.7 (and a similar issue elsewhere): { "version":"1", "Status":FALSE /* TRUE=Success, FALSE=Fail" This is not valid JSON, this is not even valid pseudo-JSON. Please move the comment: TRUE=Success, FALSE=Fail After this block to avoid confusion. Please add missing "," after each attribute value "Reason":"Informative human readable message" "reason-context": { additional JSON } }
- [Anima] Alexey Melnikov's Discuss on draft-ietf-a… Alexey Melnikov via Datatracker
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Michael Richardson
- [Anima] a note on the rfcdiff for draft-ietf-anim… Michael Richardson
- Re: [Anima] a note on the rfcdiff for draft-ietf-… Michael Richardson
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Michael Richardson
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Alexey Melnikov
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Alexey Melnikov
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Michael Richardson
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Michael Richardson
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Alexey Melnikov
- Re: [Anima] Alexey Melnikov's Discuss on draft-ie… Michael Richardson