RE: Feedback from uri list

["Joseph Salowey (jsalowey)" <jsalowey%cisco.com@localhost>]

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Jacob Nevins
> Sent: Sunday, October 11, 2009 1:53 PM
> To: ietf-ssh%netbsd.org@localhost
> Subject: Re: Feedback from uri list
> 
> Steve Suehring writes:
> > The reviewer suggested using this format for the fingerprint:
> > 
> >        
> ssh://user%host.example.com@localhost?fingerprint=ssh-dss-c1-b1-30-29-d7-
> >            b8-de-6c-97-77-10-d7-46-41-63-87
> > 
> > Whereas the previous drafts had used this format:
> > 
> >         ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-
> >              77-10-d7-46-41-63-87%host.example.com@localhost
> > 
> > The suggestion seems to make sense to me
> 
> Me too. I don't know the rationale from the URI people, but 
> the host key fingerprint isn't a property of the user, so 
> doesn't really belong in userinfo.
> 
> (From the list archives, I think it was originally moved into 
> userinfo from a position similar to the proposal because the 
> syntax originally used -- delimited with a semicolon -- was 
> illegal in URIs, or something like that. Using a question 
> mark sidesteps this, I think.)
> 
[Joe] I don't remember why we went with this format, but I agree that
the fingerprint does not belong with user info.  The suggested format
looks OK to me.  

> > but I'm unsure if there are implementations that have adopted the 
> > original format and what the implications of moving forward with a 
> > draft using the suggested format would be.  Can anyone shed 
> light on 
> > whether they have or know of an implementation using the 
> fingerprint 
> > in the 'userinfo' section?
> 
> I'd also be interested to know whether there are any extant 
> implementations; I don't know of any, and a quick Google 
> didn't turn any up.
> 
> The reason for my interest is a theoretical ambiguity in the 
> "host-key-alg-fingerprint" parameter format, which I alluded 
> to in my other post (but now wish I hadn't, for reasons that 
> will become clear).
> 
> The octets within the fingerprint are delimited by hyphens, 
> as is the separation between algorithm name and fingerprint. 
> I've just realised that this isn't ambiguous with 
> fingerprints as currently defined by RFC4716, since there are 
> exactly 16 octets and you can thus work backwards to get the 
> algorithm name.
> 
> To attempt to salvage this post :) I'll bring up the 
> possibility of a different number of octets being used to 
> represent the fingerprint in future, for instance as a result 
> of switching to a hash other than MD5.
> Even then it's hard to come up with examples where the 
> ambiguity would matter (especially as such a representation 
> would presumably either only be usable with new 
> host-key-algs, or would require definition of new connection 
> parameters).
> 
> Convenient characters other than hyphen for 
> delimiting/separation appear to be the other "unreserved" URI 
> characters -- "." / "_" / "~". (All of these are valid in 
> host key algorithm names.)
> 
> In any case, I think none of this would be worth disturbing 
> existing implementations for.

[Joe] I don't know of any existing implementations, however this thread
does bring out some issues.  In addition to the one you raised its not
clear that we could move to a hash other than MD5.  This is hard coded
in RFC 4716.  While this probably isn't a problem know it could be a
weakness in the future.  I'm pretty sure I've run into SSH
implementations that display SHA-1 fingerprints as well.   I suppose we
could have an encoding that was something like
host-key-alg-hash-alg-fingerprint.  In order to parse this you would
have to have a list of known host-key-algs and hash-algs.  If you didn't
recognize them then you would ignore the finger print.  There still is a
problem in that there could be some ambiguity where host-key-algs or
hash-algs derive from a common prefix.  At this point, I'm not sure what
to do here or how big of a problem this is. 

>