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

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 ietf@ietf.org 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 ietf@ietf.org 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 ietf@ietf.org where a whole bunch
of folks wanted that.

> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 