Hi, Late feedback, but its ambiguous in the draft how vendor default Cloud Registrar https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-2.7 and redirects as described in https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.6 should interact. Should the cloud registrar redirect immediately in response to the voucher request, so that the pledge then sends the voucher request via a local domain RA? Should the cloud registrar issue a voucher, and then the redirect happens during the EST enrol flow? When redirected, what trust anchor database should the pledge use? It seems like: - the cloud registrar should redirect to the local Registrar immediately and not issue a voucher (and this assumes a level of sales channel integration / ownership tracking so that the cloud registrar knows which registrar owns the pledge) - the pledge should use the implicit trust anchor database for the initial connection to the cloud registrar, but then revert to standard provisional TLS connection for the initial connection to the local Registrar - the pledge may include a proximity-registrar-cert in the new voucher request to the local Registrar Doing the redirect immediately facilitates proximity assertions in the voucher request and associated audit logs in the MASA, and allows the MASA to discover the local domain CA from the voucher request signature. Maybe a clarifying sentence in section 2.7 would help? Regards, Owen -----Original Message----- From: Anima <anima-bounces@xxxxxxxx> On Behalf Of The IESG Sent: 21 May 2019 22:21 To: IETF-Announce <ietf-announce@xxxxxxxx> Cc: ibagdona@xxxxxxxxx; draft-ietf-anima-bootstrapping-keyinfra@xxxxxxxx; anima@xxxxxxxx; anima-chairs@xxxxxxxx; tte+ietf@xxxxxxxxx Subject: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed Standard This is a second Last Call. IoT Directorate review was done after the ANIMA WG Last Call and consensus to request the publication, and that review resulted in substantial changes to the document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxxx mailing lists by 2019-06-04. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2816/ https://datatracker.ietf.org/ipr/3233/ https://datatracker.ietf.org/ipr/2463/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (Informational - IETF stream) _______________________________________________ Anima mailing list Anima@xxxxxxxx https://www.ietf.org/mailman/listinfo/anima
