> On Feb 15, 2018, at 10:14 AM, Toerless Eckert <t...@cs.fau.de> wrote: > > 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 ?
Certificates are a data format for encoding public keys and associated certifications (e.g. the CA signature) etc. I think this could reasonably be called data needed to establish a cryptographic security association. > > 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. If we’re stretching like this then sure. A voucher is a certification of a public key (the new owner) along with additional data used to interpret the certification. If you keep going down that path you’re gonna end up claiming we should have simply had an X509 extension instead of a voucher format. There are reasons we didn’t go that way but I could see a world where that happened (thankfully not our reality though). > 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). They both include public key data. That key material. > >> 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) I think so. Anytime we talk about raw public keys, certificates, vouchers, etc we have to discuss all the same key management issues (updating them, lifetimes, revocations, etc). > > 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 ? Why not? Its all part of the key infrastructure in that these are the entities (and associated protocols!) needed to manage all the key material. There is something different about “authentication key material” and “certification key material” but is it necessary for us to get into those pedantic areas? Are you proposing an update to RFC4949? Where are we going with this? > But would BRSKI without a following EST part even be "keying entities” ?’ BRSKI and EST are protocols not “entities”. But yes, BRSKI is a part of the key infrastructure. It is the protocol for “bootstrapping [the] remote [portion of the] secure key infrastructure”. > 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… Based on the above I think its fair to say that: Voucher’s expand on the defined key material data types. BRSKI protocol and MASA entity expand on the defined types of key infrastructure elements. - max > > 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
