Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    >> "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.

Huh, good point/question.

It might be part of the Manufacturers' PKI, but it's not part of the domain's
PKI, and that's the one that we are speaking about in the title.

I think that it's worth describing the manufacturer's situation at some
point; I would prefer to leave to another document that explained it in terms
of a BCP... "MASAOPS" or some such concepts.

    >> +   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.

Yes, that in the thread, where I referred to a thread back in January 2017,
in which you were involved in coming up with the names.

    >> +   , 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.

Circuit proxy is a MTI for the JRC, and requires *NO* special support in the JRC.
If the Registrar doesn't support listening on port 443, then it's not a registrar :-)

    >> > 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" ?

If someone is using BRSKI in a non-ANI situation, then that entity should
explain what kinds of things can occur after voucher.  So I prefer to remain mute.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-