On Thu, Feb 15, 2018 at 04:06:33PM +0000, Max Pritikin (pritikin) 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.
> "Keying material" is defined in RFC4949. Well... RFC4949: keying material 1. (I) Data that is needed to establish and maintain a cryptographic security association, such as keys, key pairs, and IVs. Can you explain to me how i should deduce from that explanation whether certificates are keying material or not ? IMHO, I need certificates to establish (authenticate) the cryptographic security association when i am using certificates. Likewise would a voucher be keying material because it is required for authentication. But the term itself "keying material" implies to a non-native english speaker that this is more likely something like a generalisation of "keys" in cypto algorithms: output = crypto_algorithm(data,keying_material) and in that sense certificates or vouchers are never keying material because they would always be classified as the data portion of any crypto_algorithm (used for establishment of a crypto association). > 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. Is this correct: brski keying material = public/private key pairs of IDevID of Pledge and certs of registrar, CA, MASA. Possible non-crypto speaker confusion: are certs/vouchers part of keying material ? (see above) brski keying entities = pledge + registrar + CA ( + MASA ?) Possible non-crypto speaker confusion: Is MASA part of keying entities ? If keying material is just the public key pairs, then probably not ? But would BRSKI without a following EST part even be "keying entities" ? brski keying protocols = BRSKI+ EST (pledge/registrar), EST (registrar/MASA), BRSKI-EST (registrar/MASA) brski keying infrastructure = brski keying entities + brski keying protocols Or whatever else is correct in the context of BRSKI. Better to just enumerate whats meant like i suggested above instead of trying generic definitions because those can fail on non-native crypto speakers like my above confusion with rfc4949. Also it wold be good if there was a clear understanding if BRSKI claims to expand the scope of any of these terms. Eg: If MASA or vouchers are now considered to be part of any prior existing terms such as keying material or keying infra. I guess that "keying protocols" are definitely expanded by BRSKI... Cheers Toerless > > - max > > > > >> c) (terminology) MASA definition: "A third-party Manufacturer...". Why > >> "third-party" ? > >> who are the first two parties ? If this is only slang and we can't explain > >> who the > >> first two parties are, delete "third-party" ? > > > > Fixed... The first party is the Pledge and manufacturer. > > The second party is the Domain Owner. > > The third party is the entity running the MASA, which may not be the > > manufacturer. > > > >> d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the > >> text mostly > >> uses "Domain Registrar" and very seldom "Join Registar". > > > > Yes, because we agreed that the term across WGs would be JRC, and we say > > in the terminology that we shorten it to Registrar. We say "Domain > > Registrar" because we want to link it to the PKI concept of a Registration > > Authority (RA). > > > >> JRC is used in exactly three places in the draft. I also can not find on > >> www.google.com > >> or wikipedia any example of "The term JRC is used in common with other > >> bootstrap > >> mechanisms" as the Terminology claims. Either provide a non-anima > >> reference for the > >> use of that term or eliminate it in the document. > > > > We agreed to use common terms. > > It was a thread on ANIMA and 6tisch a year ago. > > I can't get mailarchive to find it for me... > > Ah, I see because "JRC" was never used contracted in that thread. > > https://mailarchive.ietf.org/arch/msg/anima/iotBM0-kxsIB66t8hBo4XUtZLag > > > > As long as they Informative references. > > https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-6.1 > > https://tools.ietf.org/html/draft-ietf-6tisch-terminology-09 > > (yes, expired, but not forgotten, just not a priority) > > > >> e) Voucher > >> - misses ":" after term. > >> - please change "statement" to "artifact" so the terminology aligns with > >> both voucher > >> draft and voucher-request text which also uses artifact. See also section > >> 2.2 > >> where you use "cryptographically protected" instead of "signed" and figure > >> out > >> which term you want to use in all cases (hint: signed). > > > > I've changed it to: > > <t>A voucher is a cryptographically protected artifact (a digital > > signature) to the Pledge > > > > I feel that we need to say it's cryptographically signed at least once. > > > >> f) IMPORTANT: Please add/define the term "ANI" > > > >> ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI > >> and > >> Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). > >> ANI > >> systems (pledges, proxies, registrar) have specific requirements detailled > >> in > >> the document. > > > > <t hangText="ANI:">The Autonomic Network Infrastructure as > > defined by <xref target="I-D.ietf-anima-autonomic-control-plane" > > />. This document details specific requirements for pledges, > > proxies and registrars when they are part of an ANI.</t> > > > > Does this work for you? > > > >> Without this term we can not nail down the explicit requirements against > >> ANI Pledges, Proxies, Registrars that we need from the document (and > >> distinguish > >> from requirements against any non-ANI adaptation of BRSKI). I added > >> according > >> comments into other parts of the doc. > > > >> g) Please replace "MASA server" with "MASA service" everywhere. > > > > I prefer to just say "MASA" actually. > > Are you okay with that? > > > > Let me wrap up here for the moment so you can see the edits and > > I'll reply to the rest as Max and I digest it. It's a lot of comments. > > I'd like to push an -11 (if only to fix email for M. Behringer). > > > > https://github.com/anima-wg/anima-bootstrap/pull/42 > > > > https://github.com/anima-wg/anima-bootstrap/pull/42/commits/cb7af66344ad709aaf70287a40fa13a67bbf601c > > > > > > -- > > 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 > > _______________________________________________ > 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