Skip to main content

Last Call Review of draft-richer-vectors-of-trust-11
review-richer-vectors-of-trust-11-secdir-lc-wierenga-2018-06-21-00

Request Review of draft-richer-vectors-of-trust
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-06-26
Requested 2018-05-29
Authors Justin Richer , Leif Johansson
I-D last updated 2018-06-21
Completed reviews Genart Last Call review of -11 by Dale R. Worley (diff)
Genart Telechat review of -12 by Dale R. Worley (diff)
Secdir Last Call review of -11 by Klaas Wierenga (diff)
Assignment Reviewer Klaas Wierenga
State Completed
Request Last Call review on draft-richer-vectors-of-trust by Security Area Directorate Assigned
Reviewed revision 11 (document currently at 15)
Result Has nits
Completed 2018-06-21
review-richer-vectors-of-trust-11-secdir-lc-wierenga-2018-06-21-00
Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the  IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is: "ready with nits"

The document defines a method of signaling multiple relevant aspects of a
digital identity transaction instead of a single "level of assurance" that is
supposed to capture all of those aspects into one single value. The document is
well written and provides clear guidance as to how the various aspects of an
identity transaction can be expressed, without exploding the solution space.
The majority of the comments I have are to do with assuming too much prior
knowledge from the reader and two more subtsntial comments:

chapter 1, page 3: the second paragraph describes the vectors rather abstract
which may prove difficult to the reader, I would recommend to add here
something like "for example identity proofing, credential strength etc.)
instead of in the 4th paragraph

chapter 1.1: I thought some of that terminology had been defined in another
RFC, but unfortunately I couldn't find it

chapter 1.2: The main thing I am missing here is a reference to Attribute
Authorities (AAs). I do realise that introducing AAs complicates the trust
model big time, and am totally ok with declaring that out of scope, but I don't
think you can just pretend they don;t exist, especially since we are seeing a
movement towards it.

chapter 2.2: I am not crazy about the word "Usage", I think you are looking for
a word that expresses something akin to "strength" (without wanting to imply
ordering)

chapter 2.2, paragraph 2: You write that no ordering should be implied, and I
presume that is why you distinguish between vectors that use numbers and those
that use letters. I find that not very convincing, letters equally imply order,
so i see no compelling reason to not use either numbers or letters in all cases
instead of mixing up

chapter 3.2: have you considered adding also a SAML example, since that is
widely used as well?

chapter 8.1: it is unclear to me what meeting the criteria means (and what is
good, what is bad, and what the treshold should be)

chapter 9: isn't it true that the "strength" of the assertion of a vector can
only be as good as the cryptographical protection in transit?

Cheers,

Klaas