I always welcome, support and root for removal, avoidance and rephrasing of redundant, unnecessary, confusing, contradicting or otherwise irritating words, sentences, phrases or other elements of IETF drafts.
I just reserve the right to be pretty bad at it myself, given how i was raised with a language that is defective in this regard. See also: https://www.cs.utah.edu/~gback/awfgrmlg.html Cheers Toerless On Tue, Feb 20, 2018 at 03:26:57PM -0500, Michael Richardson wrote: > > Max Pritikin (pritikin) <priti...@cisco.com> wrote: > >>> b) Key infrastructure > >> > >>> There is no definition/reference for this term. Please describe on > >>> first use and in terminology. Is there a difference > >>> between "key infrastructure" and "keying material" ? If not, then > >>> maybe remove one term otherwise pls. describe difference. > >> > >> The term is in the title and in section 1. > >> And you are right that it does not appear again, nor is it defined. > >> I think it generally refers to the mechanism of PKI, but I'm not sure > what to do. > > > An ???infrastructure??? is the basic entities and protocols necessary > for > > the operations of key management. I think it comes from the common > > language term and can???t find a normative definition within IETF > > document. As a native english speaker who has used the concept in IETF > > interactions for eons it feels silly to try and define it. Odd. > > The words "keying material" is used in the "Other Bootstrapping Approaches" > only. In that paragraph, it refers to some "other" stuff... I'm loath to > boil the ocean to define what we aren't doing... > > I suggest the insertion of the marked text: > > 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 > *new* (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 > > Now, to the term Key Infrastructure: > > <t hangText="(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 > <xref target="RFC5280" /> Registrar, as well as appropriate > certificate revocation list (CRL) distribution points and/or OCSP > (<xref target="RFC6960" />) servers.</t> > > I note that RFC6960 doesn't bother to define Key Infrastructure at all, or > even use the term except in the title... > > -- > 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
