Re: [saag] New Version Notification for draft-richer-vectors-of-trust-07.txt

[Justin Richer <[e-mail]>]

Hi everyone,

I’ve uploaded a new version of Vectors of Trust that addresses all of Sean’s comments. 

Name:		draft-richer-vectors-of-trust
Revision:	08
Title:		Vectors of Trust
Document date:	2018-03-18
Group:		Individual Submission
Pages:		23
URL:            https://www.ietf.org/internet-drafts/draft-richer-vectors-of-trust-08.txt <https://www.ietf.org/internet-drafts/draft-richer-vectors-of-trust-08.txt>
Status:         https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/ <https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/>
Htmlized:       https://tools.ietf.org/html/draft-richer-vectors-of-trust-08 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-08>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-richer-vectors-of-trust <https://datatracker.ietf.org/doc/html/draft-richer-vectors-of-trust>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-richer-vectors-of-trust-08 <https://www.ietf.org/rfcdiff?url2=draft-richer-vectors-of-trust-08>


 — Justin

> On Mar 12, 2018, at 7:11 PM, Sean Turner <[e-mail]> wrote:
> 
> Messages related to draft-richer-vectors-of-trust.
> 
>> Begin forwarded message:
>> 
>> From: Justin Richer <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: New Version Notification for draft-richer-vectors-of-trust-07.txt
>> Date: March 12, 2018 at 19:09:35 GMT
>> To: Sean Turner <[e-mail] <mailto:[e-mail]>>
>> Cc: Leif Johansson <[e-mail] <mailto:[e-mail]>>
>> 
>>>> On Mar 12, 2018, at 18:07, Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Hi Sean, thanks so much. Responses inline:
>>>> 
>>>>> On Mar 12, 2018, at 1:46 PM, Sean Turner <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Sorry just found the gh repo in an old mail … I can put in PRs if you want on the nits.
>>>> 
>>>> Yes please, that would be great. Feel free to do it as just one PR or several, whatever’s your preference.
>>> 
>>> I will try my best to not screw up the xml.
>>> 
>>>>> spt
>>>>> 
>>>>>> On Mar 12, 2018, at 17:33, Sean Turner <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> Here’s my review of draft-richer-vectors-of-trust (should I send this someplace else too -secdir?):
>>>>>> 
>>>>>> tl;dr: I like the idea after I got over my RBAC flashbacks!
>>>> 
>>>> I totally get that, and since this work is meant to stand in contrast to RBAC if there’s a way we can make that clearer then that would be good.
>>> 
>>> After we exchanged those emails earlier I was wondering if the RBAC-flashback was a good thing or a bad thing.  I come to think it was a good thing because it definitely gets you thinking about what worked and what didn’t.
>>> 
>>>>>> I’ll be honest that at first I was like here we go again, but I do like that you managed to keep it to only 4 vectors initially and allow it to be expanded later.  I thought the recommendation for the second marker (alpha vs numeric) was pretty much what I would have done: P needs to have # the others not so much.  Not that for the same reasons you did C0 you could also do A0 - it is a “No”.
>>>> 
>>>> What would an A0 be, though? An unsigned assertion? C0 is something you might want to communicate (we did nothing in particular but there’s a user here maybe) but I’m not seeing the value in A0.
>>>> 
>>>> As another example of how this works, NIST’s implementation uses both alpha and numeric for all their categories, requiring numeric for base values and adding alpha values as optional additional info on top of the category the number represents. 
>>>> 
>>>> https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md <https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md>
>>> 
>>> I was simply thinking about 0 = None/No.  I don’t think you have to change it to make all of the ones with no checks 0.
>>> 
>>>>>> 
>>>>>> I was initially a little confused about it being standards track because it’s specifying a framework, but you are specifying a wire format so that seems okay in my book.
>>>> 
>>>> I’m fine with whatever target is recommended but it feels standards track to me. 
>>> 
>>> Like I said initially I was like oh it’s a framework, but once you started defining stuff that gets sent on the wire well I can go with standards track.
>>> 
>>>>>> Question in s3.4: When you say “such as a session cookie in a web browser” you talking about HTTP’s cookies right and not TLSs?
>>>> 
>>>> Yes, HTTP cookies. We can add text to make that more explicit. 
>>> 
>>> I can slap that in my PR.
>>> 
>>>>>> The IANA considerations section looks fine.  I assume you two would offer to the Des?
>>>> 
>>>> Yes. I volunteer and I’ll gladly volunteer Leif.
>>> 
>>> I guess this is more for the ADs to know there’s a pool of candidates waiting to that the lead :)
>>> 
>>>>>> I can see some asking for more information for the Sec/Priv sections, bit honestly what you got there is pretty much it: don’t send these things in the clear, bind them with cryptography, and don’t share too much otherwise you’ll give away something you might not have meant to.   So, in my book that’s probably good enough.
>>>> 
>>>> I found it hard to draw out much more than what we’ve got in there, especially in privacy because this is by its nature identifying information. Happy to expand if anyone’s got a good suggestion.
>>> 
>>> I think this is exactly the right way to play it.  You could write a novel here, but instead hit the hi points.  When somebody says what about blah you can point them at the gh repo and PRs welcome ;)
>>> 
>>>>>> Nits: 
>>>>>> 
>>>>>> 0) Update to match the new terminology paragraph:
>>>>>> 
>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>>>>>> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>>>>>> "MAY", and "OPTIONAL" in this document are to be interpreted as
>>>>>> described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>>>>>> appear in all capitals, as shown here.
>>>> 
>>>> Sounds fine.
>>> 
>>> Can do.
>>> 
>>>>>> 1) s5.1: vtr vs votr?  I know everybody loves the 3-letter once but it make more sense that vot is the request and votr is the response.  I’m in no way going any where near a mat to argue this point though.
>>>> 
>>>> The JWT community loves the three-letter fields so we went with this. If we were to change it (which I’d kinda rather not) I’d instead go with “vot_req” to expand it out. 
>>> 
>>> Ah I get that - no need to change it.
>>> 
>>>>>> 2) s8: sentence end abruptly:
>>>> 
>>>> I think it’s just missing a reference target which rendered funny
>>> 
>>> I’ll leave this one to you because I’m not sure where it’s supposed to point.
>>> 
>>>>>> 3) I think both SP-800 references are missing something.
>>>> 
>>>> Possibly, I wasn’t sure how to best pull those in.
>>> 
>>> I’ll see what I can dig up and put it in the PR.
>>> 
>>>>>> 4) I-D nits complains about two outdated references:
>>>>>> 
>>>>>> ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
>>>>>> 
>>>>>> ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
>>>> 
>>>> I had no idea there was a new JSON, again!
>>> 
>>> This bit me in the ass earlier this month.
>>> 
>>>> — Justin
>>>> 
>