Steve Suehring writes: > The reviewer suggested using this format for the fingerprint: > > ssh://user at host.example.com?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 at host.example.com > > 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.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.