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

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2012 13:03:16 +0300

Hi all, 

I don't really know what the right place is to discuss this document. Hence, I trying the saag mailing list. 

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

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. 

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.  

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. 

The security consideration is a collection of random thoughts. 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. 

In a nutshell, there is room to simplify the document. 

Ciao
Hannes

PS: I am not sure what you are trying to accomplish with the Content Type Query String.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jul 2012 13:42:14 +0100

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 [email-masked] 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 [email-masked] archives
you'll maybe get some useful background that covers some of
this.

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

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

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

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

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.

> PS: I am not sure what you are trying to accomplish with the Content Type Query String. 

See the discussion on [email-masked] where a whole bunch
of folks wanted that.

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2012 18:10:54 +0300

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. 

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jul 2012 16:30:57 +0100

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