Toerless Eckert <[email protected]> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
