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

[Toerless Eckert <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> > 
> > 
> > 
> > _______________________________________________
> > Anima mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]