Re: Feedback from uri list

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

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

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