Re: [saag] draft-farrell-decade-ni-09

[Stephen Farrell <[e-mail]>]

On 07/15/2012 04:10 PM, Hannes Tschofenig wrote:
> Hi Stephen, 
> 
> I would expect to find the NI and the NIH scheme in there and nothing more. The rest of feature creep (commonly found in EU funded projects - hint!).  
> 
> Nothing about binary encoding, base64 encoding of the URI, anything about certificate formats behind hashed with normative language, no authority field in the URI, no query parameter in the URI, no .well-known URI. 
> 
> The consequence: half the size and twice as useful. 

Actually, the draft was half the size early this year. The
functional additions were nih, the binary format and the
content type, due to requirements from the core wg and then
comments during IETF LC.

There were a lot of small pieces of additional text added
as a result of IETF LC and discussion on apps-discuss. While
that was a bit of a pain, to be honest, I can't point at any
and say it doesn't belong, nor did I see scope to make it
a lot shorter last time I went over it.

So in this case, any "creep" has been caused as a result
of IETF processes, (or "review" to put it more nicely:-)
and was nothing to do with (our) funding source.

I think you're mis-diagnosed this one to be honest.

S.


> 
> Ciao
> Hannes
> 
> On Jul 15, 2012, at 3:42 PM, Stephen Farrell wrote:
> 
>>
>> Hi Hannes,
>>
>> That seems like a bunch of non-actionable comments so
>> I don't know what response you were after.
>>
>> My guess is you were expecting to read some other
>> document, and were surprised when you saw the actual
>> content here. But I'm not sure that's a problem that's
>> fixable, nor ought be fixed via changes to this draft.
>>
>> On 07/15/2012 11:03 AM, Hannes Tschofenig wrote:
>>> Hi all, 
>>>
>>> I don't really know what the right place is to discuss this document. 
>>
>> It was discussed on apps-discuss before IETF LC, starting from
>> around the Paris IETF. During IETF LC it was discussed a lot
>> (well, I think a lot:-) on [e-mail] and IETF LC ended
>> last week. The document's on next week's telechat so if you
>> have specific concerns you might want to communicate them to
>> an AD as well.
>>
>>> Hence, I trying the saag mailing list.
>>
>> If you look at the apps-disucss or [e-mail] archives
>> you'll maybe get some useful background that covers some of
>> this.
>>
>>> I read through the document and my impression is that it tries to accomplish a little bit too too much. 
>>>
>>> As a high level comment you cannot make an assumption about what information is hashed. Another specification is needed to explain the semantic and these other documents exist. For example, I had asked on the TLS mailing list whether we should use this document to convey fingerprints of raw public keys (which come in form of a SubjectPublicKeyInfo in our case). 
>>
>> I have no idea what you mean. This draft can tell you how to
>> format hash outputs but can't specify inputs if its to be
>> useful. Part of the reason for the draft was that other
>> protocols that can specify the inputs and the use of the
>> outputs, were all doing it trivially differently, which
>> seems like a bad plan. (The document says that.)
>>
>>> This has an impact on the security consideration section, the hash algorithm registry, and various statements made in the document. 
>>>
>>> For example, the statement that "... the hash SHOULD be calculated over the public key in an X.509 SubjectPublicKeyInfo structure..." isn't really useful when the document aims to provide hashes of all sorts of objects and some might not even be X.509 certificates at all. 
>>
>> I disagree. For the case of public keys, we do know that that
>> format is useful in more than one case. MUST would be too
>> much since generally other specs define hash inputs. Hence
>> SHOULD. I think its correct as-is.
>>
>>> The encoding of the URI also seems a bit strange. It seems that you have started with the Web use case and then though "Cool. This could be useful in other protocols as well.". But the problem is that other protocols have their own encoding. For example, in the TLS out-of-band validation mechanism there is no internationalization issue nor a need to do a base64 encoding. The binary encoding falls into that category as well.  
>>
>> So use it or don't use it, but saying its "a bit strange" is... "a bit
>> strange."  If you want the binary format, then use that rather than
>> the ni format. That's all fine.
>>
>>> The .well-known seems to me pretty unrelated to this specification and may have sneaked into the document as part of the Web use case. 
>>
>> I don't know how to handle a "sneaked in" comment. I think its
>> a fine thing. (PHB's idea as it happens.)
>>
>>> The security consideration is a collection of random thoughts. 
>>
>> Again, that's not a comment I know how to process.
>>
>>> I have difficulty understanding what is being said there. There are in general two problems to come up with a meaningful text. The first problem is related to the generic nature of your document: it makes a difference what you hash. To pick the TLS oob validation document again there we have a hash of the public key. In other cases you are talking about hashing some file or other objects. Then, the second problem is that you do not know what is done with the hash as part of the overall protocol interaction of the application that is using your URI scheme. So, in the TLS oob validation draft the hash of the public key is associated with the public key cached from an earlier exchange and is also linked to the private key that is then used in the TLS handshake. In other applications the hash just be used to point to some state information that is retrieved. 
>>
>> The consequences of using these formats are IMO properly the
>> concern of other documents.
>>
>>> In a nutshell, there is room to simplify the document. 
>>
>> In a nutshell, I guess you were expecting something else.
>> Am I right? If so, then perhaps your comments are more about
>> that surprise rather than the content of the draft perhaps?
>>
>> S.
>>
>>>
>>> Ciao
>>> Hannes
>>>
>>> PS: I am not sure what you are trying to accomplish with the Content Type Query String. 
>>
>> See the discussion on [e-mail] where a whole bunch
>> of folks wanted that.
>>
>>
>>> _______________________________________________
>>> saag mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/saag
>>>
>>
> 
> 
>