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
