Hi, As this is the last call, it may not be to late to ask the question. I read the draft a couple of times and was stumbling upon the following:
In Figure 1 of the BRSKI draft, for the communication between the Domain Registrar (RA) and the Key Infrastructure (CA), EST is stated. >From my understanding of the description EST as enrollment protocol between an >RA and the CA is meant exemplary but not prescriptive? From the protocol flow >for the enrollment itself I understood BRSKI describes the flow until the >Domain Registrar but is open regarding the protocol applied between the domain >registrar and the CA. It may be EST. Is my understanding right? If yes, would it be appropriate to state "e.g., EST (RFC 7030)" in the figure to make clear it is an example? Best regards Steffen > -----Original Message----- > From: Anima <[email protected]> On Behalf Of The IESG > Sent: Dienstag, 21. Mai 2019 23:21 > To: IETF-Announce <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > 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 [email protected] mailing lists by 2019-06-04. Exceptionally, > comments may be sent to [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
