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