> On Feb 20, 2018, at 7:38 PM, Toerless Eckert <t...@cs.fau.de> wrote: > > Thanks, Michael > Can't see a commit on github since 6 dyays ago, maybe in different branch ? > Comments for now therefore inline against your email. > > On Tue, Feb 20, 2018 at 07:54:40PM -0500, Michael Richardson wrote: >> >> Toerless Eckert <t...@cs.fau.de> wrote: >>> Overall: >> >>> a) Requirements about EST: >> >>> - The introduction says: "Integration with a complete EST enrollment is >>> optional but trivial" >>> - 5.8.3 says "The Pledge MUST request a new client certificate". >>> - 1.4 says "bootstrapped devices have a common trust anchor and a >>> certificate >>> has optionally been issued from a local PKI >> >>> a) The text needs to be made consistent across all places where requirements >>> are defined. I have in general no strong opinion how "optional" the text >>> should >>> say EST operations are, BUT consider he following points: >> >>> b) We need a complete list of BRSKI requirements for ANI devices, where EST >>> operation requirements are made stronger. I suggest a separate subsection >>> at an >>> appropriate place so that "ANI requirements" shows up in the table of >>> contents: >> >>> Section X.Y.Z Requirements for ANI devices: >> >>> For BRSKI on ANI Devices (ANI = BRSKI + ACP), EST operations is mandator. >>> The ANI pledge MUST perform >>> - "CA Certificates Request", >>> - "CSR Attributes" >>> - "Client Certificate Request" >>> - "Enrollment status Telemetry" >>> The ANI registrar MUST support BRSKI and these EST operations. >>> All ANI devices SHOULD support the BRSKI proxy function. >> >> I've done the following: > [...]> > >> 1.1. Other Bootstrapping Approaches >> >> To literally "pull yourself up by the bootstraps" is an impossible >> @@ -233,9 +237,10 @@ Internet-Draft BRSKI >> February 2018 >> without external help is also an impossibility. Today it is commonly >> accepted that the initial connections between nodes are insecure, >> until key distribution is complete, or that domain-specific keying >> - material is pre-provisioned on each new device in a costly and non- >> - scalable manner. Existing mechanisms are known as non-secured 'Trust >> - on First Use' (TOFU) [RFC7435], 'resurrecting duckling' >> + material (often pre-shared keys, including mechanisms like SIM cards) >> + is pre-provisioned on each new device in a costly and non-scalable >> + manner. Existing mechanisms are known as non-secured 'Trust on First >> + Use' (TOFU) [RFC7435], 'resurrecting duckling' >> [Stajano99theresurrecting] or 'pre-staging'. > > Nice. > >> Another approach is to try and minimize user actions during >> >> @@ -358,6 +364,13 @@ Internet-Draft BRSKI >> February 2018 >> "Registrar". The term JRC is used in common with other bootstrap >> mechanisms. >> >> + (Public) Key Infrastructure: The collection of systems and processes >> + that sustain the activities of a public key system. In an ANIMA >> + Autonomic system, this includes a Domain Certification Authority >> + (CA), (Join) Registrar which acts as an [RFC5280] Registrar, as >> + well as appropriate certificate revocation list (CRL) distribution >> + points and/or OCSP ([RFC6960]) servers. > > I had interpreted Max'es response on the mail discussion to indicate that > MASA would also be considered to be part of the PKI. I am fine either way. > Just checking. If as you propose above it's not part of the PKI, a simple > sentence explaining why not would be great.
The MASA is a certifier of vouchers. A voucher isn’t really a PKI construct today. Its more of a distribution of trust-anchor or “pinned cert” construct used to bootstrap a PKI because the PKI’s don’t have such a concept. I think it could be argued either way but its probably most accurate at this time to talk about the MASA as being distinct from the PKI if only because this isn’t the PKIX working group and therefore it isn’t in our charter to add anything to the public key infrastructure. Which highlights the absurdity of trying to draw this distinction. :) I’m good with Michael’s excellent text. - max > >> + >> Join Proxy: A domain entity that helps the Pledge join the domain. >> A Proxy facilitates communication for devices that find themselves >> in an environment where they are not provided connectivity until >> >> +1.5. Requirements for Autonomic Network Infrastructure (ANI) devices >> >> + The BRSKI protocol can be used in a number of environments. Some of >> + the flexibility in this document is the result of users out of the >> + ANI scope. This section defines the base requirements for ANI >> + devices. >> >> + For devices that intend to become part of an Autonomic Network >> + Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes >> + an Autonomic Control Plane >> + ([I-D.ietf-anima-autonomic-control-plane]), the following actions are >> + required and MUST be performed by the Pledge: >> >> + o BRSKI: Request Voucher >> >> + o EST: CA Certificates Request >> >> + o EST: CSR Attributes >> >> + o EST: Client Certificate Request >> >> + o BRSKI: Enrollment status Telemetry >> >> + The ANI Registrar (JRC) MUST support all the BRSKI and above listed >> + EST operations. > > > Can't remember conclusion on redundant terminology re. JRC vs. the other terms > used. Personal preference would be to eliminate JRC as a term, but i'll wait > for the final doc. re. minimum necessary terminology. > >> + All ANI devices SHOULD support the BRSKI proxy function, using >> + circuit proxies. Other proxy methods are optional > > Overall 1.5 nice.1 > >> + , and may be >> + enabled only if the JRC indicates support for them in it's >> + announcement. (See Section 4.4) > > IMHO: sentence eend after "optional". Followed by "all proxy functionally > needs to ... be enabled... > > Aka: circuit proxy is a no-op too if the proxy does not discover a registrar > supporting it. Not specific to advanced options. > > >>> II) This leaves the option that EST to install trust anchor is mandatory, >>> but >>> enrolment with a certificate is optional (except for ANI case). >> >>> Aka: would be good to write a sentence/paragraph exactly outlining what is >>> permitted to happen after a voucher and if any, what parts of EST are >>> deemed to >>> be necessary by BRSKI (outside of ANI devices. the requirements for ANI >>> devices >>> are listed above). >> >> I think that this should be left to other users. > > Rephrase ? Don't understand what this means (especially users). "other > authors" ? "other docs" ? > > Maybe just: > > BRSKI does not mandate EST client certificate enrolment except for ANI > devices. > Considerations for complete solutions using Pledges that only perform Request > Voucher > and CA Certificates request, but no EST client certificate enrolment are > outside the scope of this document / subject to future work. > > >> I am going to push the -11 with these changes, and the ones from last week. > > Thanks! > > Cheers > Toerless > >> I acknowledge that I still have a bunch of edits from the rest of your >> message. >> >> >> -- >> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > > >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > > -- > --- > t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
