Re: [secdir] review of draft-richer-vectors-of-trust-11

[Justin Richer <[e-mail]>]

Hi Klaas, thanks for the review. I’ve replied inline and have addressed your comments in the working copy where applicable. 

> On Jun 19, 2018, at 10:46 AM, Klaas Wierenga <[e-mail]> wrote:
> 
> 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

The paragraph prior to the one mentioned here has just such an aside, and repeating it in the next paragraph would be redundant in my opinion. 

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

Most of these are terms of industry but if there’s a specific external reference that we can include informatively I’d be happy to add 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.

I really don’t want to go into that depth — as stated in the intro, we are trying to avoid the complexities of all-attribute-all-the-time systems. We distinctly do not want to get into attribute metadata here, which is where the attribute authority model really starts to come into play. 

> 
> 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)

We originally started with “strength” but that implies more than we wanted it to in terms of one being “better” than the other. The real bit is “what does the person need to do in order to make the credential do its thing with the server they’re trying to authenticate to” but that’s a bit long. :) In the end, we felt this category captured “how do you use this credential” and went with “usage” in order to stay neutral.

> 
> 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

This is a good point, and I’ll try to make the wording here clearer. You can of course assign letters to things with natural ordering, but it also often makes sense to not necessarily use the letters as an ordered list. In the NIST implementation, for example, “Pi” means “in person”, “Pr” means “remote”, “Pt” means “trusted referee”, etc. 

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

As Ben mentioned, yes, and it’s gone now. I’d be happy for someone to make a SAML binding to VoT but at this point I think it would make more sense in another document. 

> 
> 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)

The intent is in the guidance to the DEs in the second paragraph: 

 - It shouldn’t be a duplicate of something that’s already out there
 - It should be clear whether it’s of general applicability or something very case-specific (and if it can be the former, that’s preferred)
 - The definition of the category should be clear enough for a trust framework to define values for it and for people to use those values

If you have suggested text for making that set clearer I’m happy to incorporate it.

> 
> 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?

That’s one limiting factor, but there are others including the amount of trust that can be put in the IdP making the assertion in the first place. 

> 
> Cheers,
> 
> Klaas
> 

Thank you,

 — Justin