On Wed, Feb 21, 2018 at 02:45:12AM +0000, Max Pritikin (pritikin) wrote: > > 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.
Thank. I always hate good explanations go to waste. Sentence like the following would be lovely for readers whose first attempt at survival in a sea of security is to figure out what the terminology means: (at end of PKI def in termonology). Note: The definition of PKI preceeds the MASA and Voucher concepts and any evolution of the definition of the term PKI is outside the scope of this document. Therefore they are not considered to be part of a PKI. Cheers Toerless > 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 -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
