On Monday, August 04, 2014 17:52:52 Viktor Dukhovni wrote: > On Mon, Aug 04, 2014 at 10:08:36AM -0700, Dave Crocker wrote: > > Looks to me like they are listed as key management methods. > > Well, Wikipedia is not necessarily authoritative here. We do have > the term "key agreement" available, and it should be noted that in > many cases (including many cases with TOFU) even when long term > keys are not necessarily strongly authenticated in addition to the > long-term (managed) keys, there are typically also per-session > ephemeral keys obtained via a suitable key agreement scheme. > > We can spend a lot of time fine-tuning subtleties of wording that > only a few select initiates of the arts will appreciate. It is > reasonably clear from the context of the draft that key management > is about authentication keys, most commonly in the form of PKIX > X.509 certificates. > > > More generally, for this draft, I would expect the term 'key management' > > to have extremely broad and inclusive meaning, only barely qualifying as > > a technical definition, simply because I thought this document was > > intended for broad use. > > While the drafts intended audience is broad, the meaning of the > term key management is to be understood in context as the primary > barrier to universal adoption of authenticated active-attack > resistant protocols. Thus the intended meaning is not so broad as > to include cases that are [not] barriers to said adoption. > > It is hard to imagine an audience of non-specialists finding this > an issue to quibble over. It is rather secondary. Agreed. > > All of which leads to the basic question of who this draft is for? I > > thought it was for broad-based use among technicians, technical managers > > and others, including folk who are not security experts and folk who > > might not even be networking or computer experts. > > Yes, and therefore, subtle nuance, and overly precise definitions are > a distraction from the main thrust of the document: > > * Encrypt whenever possible, even when authentication is not an option. > * Do consider designs where authentication is employed when possible, > on a peer-by-peer basis. I think trying to be more specific, even if more theoretically correct, would be a source of confusion and harmful to the purpose of this document. > > It really would help to gain some rough consensus about the target > > audience for this document, so that that population can be referenced > > when attempting to evaluate choices, rather than having anyone attempt > > to rely on their personal preferences, here on the IETF. > > The document is a new security manifesto for the Internet at large. > > I personally welcome all clarifications of the core message. I'd > prefer to not get stuck in the weeds. If I am there already, please > help me out, if some weeds are required for a balanced diet by IETF > consensus, I'll add them in. The IETF consensus need only be rough, so some roughage is fine. Please leave it as is. Scott K