ssh URI

['Steve Suehring']

Hello,

Attached is a draft to be submitted to the IETF for URI scheme related
to secure shell (ssh).  The draft was originally included in the secsh
Working Group which has since concluded.  

http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/

I recently received a request to pick this draft back up and the
co-author and I will be submitting it to the IETF under the Application
Area.

Please provide feedback as appropriate.

Thank you for your time.

Steve Suehring

Individual Submission                                         J. Salowey
Internet-Draft                                             Cisco Systems
Intended Status: Proposed Standard                           S. Suehring
Expires: April 15, 2010                                 October 12, 2009


   Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)
                      draft-suehring-sshuri-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes the Uniform Resource Identifiers used to
   locate resources for the Secure Shell (SSH) protocol.  The document
   describes the generic syntax involved in URI definitions as well as
   specific definitions for the protocol.  The specific definition
   may include user credentials such as username and also may include
   other parameters such as host key fingerprint.  In addition,
   security considerations and examples are also provided within this
   document.



Salowey & Suehring       Expires April 15, 2010                 [Page 1]

Internet-Draft             URI Scheme for SSH               October 2009



Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Conventions Used in This Document. . . . . . . . . . . . . .   3
   3.   General Syntax . . . . . . . . . . . . . . . . . . . . . . .   3
   4.   Secure Shell (SSH) URI . . . . . . . . . . . . . . . . . . .   3
     4.1  Scheme Name  . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2  Status . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.3  URI Scheme Syntax  . . . . . . . . . . . . . . . . . . . .   3
     4.4  URI Semantics  . . . . . . . . . . . . . . . . . . . . . .   4
     4.5  Encoding Considerations  . . . . . . . . . . . . . . . . .   4
     4.6  Protocols using this URI scheme  . . . . . . . . . . . . .   4
     4.7  Security Considerations  . . . . . . . . . . . . . . . . .   4
     4.8  Contact  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.   Parameters . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1  SSH connection parameters  . . . . . . . . . . . . . . . .   5
   6.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   6
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .   6
   9.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   6
   10.  References . .. . . . . . . . . . . . . . . . . . . . . . .    7
     10.1   Normative References . .. . . . . . . . . . . . . . . .    7
     10.2   Informative References .  . . . . . . . . . . . . . . .    7
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   7
        Intellectual Property and Copyright Statements . . . . . . .   8















Salowey & Suehring       Expires April 15, 2010                 [Page 2]

Internet-Draft             URI Scheme for SSH               October 2009


1.  Introduction

   This document describes the Uniform Resource Identifiers (URIs) to be
   used with the Secure Shell (SSH) [RFC4251] protocol.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119.

3.  General Syntax

   A hierarchical URI shall consist of the scheme and the scheme
   specific portion separated by a colon ":" followed by the
   hierarchical part, as discussed in [RFC3986].  This specification
   uses the definitions "port", "host", "scheme", "userinfo", "path-
   empty", "path-abempty" and "authority" from [RFC3986].  This document
   follows the ABNF notation defined in [RFC5234].

4.  Secure Shell (SSH) URI

   This section describes the SSH URI and contains the information
   necessary to register the URI according to the template in [RFC4395].

4.1  Scheme Name

   The Secure Shell scheme name is "ssh".

4.2  Status

   The requested status of the SSH URI is "permanent".

4.3  URI Scheme Syntax

   The Secure Shell (SSH) scheme shall consist of the scheme name "ssh"
   followed by a colon ":" followed by hier-part defined in [RFC3986].
   The SSH URI ABNF definition follows.


   sshURI        =  "ssh:" hier-part
   hier-part     =  "//" authority path-abempty
   authority     =  [ [ ssh-info ] "@" ] host [ ":" port ]
   host          =  <as specified in [RFC3986]>
   port          =  <as specified in [RFC3986]>
   path-abempty  =  <as specified in [RFC3986]>
   ssh-info      =  [ userinfo ] [";" c-param *("," c-param)]
   userinfo      =  <as specified in [RFC3986]>
   c-param       =  paramname "=" paramvalue
   paramname     =  *( ALPHA / DIGIT / "-" )
   paramvalue    =  *( ALPHA / DIGIT / "-" )



Salowey & Suehring       Expires April 15, 2010                 [Page 3]

Internet-Draft             URI Scheme for SSH               October 2009


   The following reserved characters from [RFC3986] are used as
   delimiters within the SSH URI: ";", ",", ":", "=", and "/".  They
   must not be escaped when used as delimiters and must be escaped when
   the appear in other uses.

4.4  URI Semantics

   The intended usage of the SSH URI is to establish an interactive SSH
   terminal session with the host defined in the authority portion of
   the URI.  The only operation defined for the URI is to establish an
   SSH terminal session with a remote host.

   If the userinfo or connection parameters are present the at-sign "@"
   shall precede the authority section of the URI.  Optionally, the
   authority section MAY also include the port preceded by a colon ":".
   The host SHOULD be a non-empty string.  If the port is not included,
   the default port is assumed.

   The ssh-info portion of the URI MAY include credentials consisting of
   a username followed by optional parameters.  The convention of
   including the password separated from the username by a ":" in the
   URI is NOT RECOMMENDED and is deprecated in accordance with
   [RFC3986].

   One or more optional connection parameters (c-param) may be specified
   within the userinfo section of the URI.  These conn-parameters are
   separated from the userinfo by a semi-colon ";".  The only connection
   parameter defined in this document is for the host-key fingerprint
   described in Section 4.1.  It is possible that additional parameters
   be defined in the future.  If a connection parameter is not
   understood it SHOULD be ignored.

   The SSH URI does not define a usage for a non-empty path element.  If
   a non-empty path element is included in an SSH URI then it SHOULD be
   ignored.

4.5  Encoding Considerations

   The encoding of the "host" portion of the URI is as defined in
   [RFC3986].  The encoding of the connection parameters is described in
   Section 4.1

4.6  Protocols using this URI scheme

   This URI scheme is used by the SSH protocol version 2 defined in
   [RFC4251].

4.7  Security Considerations

   See Section 7.


Salowey & Suehring       Expires April 15, 2010                 [Page 4]

Internet-Draft             URI Scheme for SSH               October 2009


4.8  Contact

   This document is a product of the SSH working group.

5.  Parameters

5.1   SSH connection parameters

   The following parameters are associated with an SSH connection. All
   parameters are optional and MUST NOT overwrite configured defaults.  
   Individual parameters are separated by a comma (",").

   fingerprint

      The fingerprint parameter contains the fingerprint of the host key
      for the host specified in the URI.  The fingerprint is encoded as
      host-key-alg-fingerprint.  Host-key-alg is host public key
      algorithm defined in [RFC4253] and the fingerprint format is
      [RFC4716].  For use in a URI, the fingerprint shall use a single
      dash "-" as a separator instead of the colon ":" as described in
      [RFC4716].  This parameter MUST NOT overwrite a key that is
      already configured for the host.  The fingerprint MAY be used to
      validate the authenticity of the host key if the URI was obtained
      from an authenticated source with its integrity protected.  If
      this parameter is not included then the host key is validated
      using another method.  See Security Considerations section for
      additional considerations.  There MUST be only one fingerprint
      parameter present in a given URI.

6.  Examples

   The following section shows basic examples of URIs.  This section
   should not be considered to include all possible combinations of
   URIs for each protocol.

   An SSH connection to the host host.example.com on the standard port.

        ssh://host.example.com

   An SSH connection to the host host.example.com on the standard port
   using username user.

        ssh://user@...

   An SSH connection to the host host.example.com on port 2222 using
   username user.

        ssh://user@...:2222

   An SSH connection to the host having the specified host-key

Salowey & Suehring       Expires April 15, 2010                 [Page 5]

Internet-Draft             URI Scheme for SSH               October 2009


   fingerprint at host.example.com on the standard port using username
   user.

        ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-
             77-10-d7-46-41-63-87@...

7.  IANA Considerations

   Section 3 provides the information required in the URI registration
   template in accordance with [RFC4395].

8.  Security Considerations

   Passwords SHOULD NOT be included within the URI as doing so poses a
   security risk.  URIs are usually sent in the clear with no encryption
   or other security, any password or other credentials included in the
   userinfo could be seen by a potential attacker.

   Although the host-key fingerprint is not confidential information,
   care must be taken in handling fingerprints associated with URIs
   because URIs transmitted or stored without protection may be modified
   by an attacker.  In general an implementation cannot determine the
   source of a URI so a fingerprint received in a URI should have no
   more trust associated with it than a raw public key received in the
   SSH protocol itself.  If a locally configured key exists for the
   server already it MUST NOT be automatically overwritten with
   information from the URI.  If the host is unknown then the
   implementation should treat the fingerprint received with the same
   caution that it does with any unknown public key.  The client MAY
   offer the fingerprint and URI for external validation before allowing
   a connection based on this information.  If the client chooses to
   make a connection based on the URI information and it finds that the
   fingerprint in the URI and the public key offered by the server do
   not match then it SHOULD provide a warning and provide a means to
   abort the connection.  Sections 4.1 and 9.2.4 of [RFC4251] provide a
   good discussion of handling public keys received in the SSH protocol.

9.  Acknowledgements

   Ben Harris, Tom Petch and the members of the SSH working group have
   provided much useful feedback in the preparation of this document.



Salowey & Suehring       Expires April 15, 2010                 [Page 6]

Internet-Draft             URI Scheme for SSH               October 2009


10.  References

10.1  Normative References

   [RFC4716]
              Galbraith, J. and R. Thayer, "The Secure Shell (SSH)
              Public Key File Format", RFC 4716, November 2006.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, October 2005.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

10.2  Informative References

   [RFC4395]
              Hansen, T., "Guidelines and Registration Procedures for
              new URI Schemes", RFC 4395, February 2006.


Authors' Addresses

   Joseph Salowey
   Cisco Systems
   2901 3rd Ave
   Seattle, WA  98121
   US

   Email: jsalowey@...


   Steve Suehring
   PO BOX 1033
   Stevens Point, WI  54481
   US

   Email: suehring@...


Salowey & Suehring       Expires April 15, 2010                 [Page 7]

Internet-Draft             URI Scheme for SSH               October 2009

Copyright and License Notice
   
   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, IETF
   TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.




Salowey & Suehring       Expires April 15, 2010                 [Page 8]

[Křištof Želechovski]

  1. [4.4] Outdated internal references: The parameters are not described in
section 4.1.
  2. [4.4] The syntax does not forbid having a nonempty path component but a
semantic for one is not described.
  3. [5.1] I would rather have
ssh://user@...?fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-7
7-10-d7-46-41-63-87
for obvious reasons.
Please consider
Chris

['Steve Suehring']

Hello,

Thank you for the feedback.  Could you help me with #2 on your list?  We
have this in the draft now:

"The SSH URI does not define a usage for a non-empty path element.  If a
non-empty path element is included in an SSH URI then it SHOULD be
ignored."

Should that specific sentence be amended or is there some additional
clarification necessary?

Steve

On Fri, Oct 09, 2009 at 07:51:50PM +0200, K?i?tof ?elechovski wrote:

>   1. [4.4] Outdated internal references: The parameters are not described in
> section 4.1.
>   2. [4.4] The syntax does not forbid having a nonempty path component but a
> semantic for one is not described.
>   3. [5.1] I would rather have
> ssh://user@...?fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-7
> 7-10-d7-46-41-63-87
> for obvious reasons.
> Please consider
> Chris

[Křištof Želechovski]

Thanks for the clarification.  In this case, the specification should say
that the path component MUST be empty.  It is confusing to have a feature
that serves no purpose.
Chris

-----Original Message-----
From: 'Steve Suehring' [mailto:suehring@...]
Sent: Friday, October 09, 2009 10:43 PM
To: K?i?tof ?elechovski
Cc: uri-review@...; uri@...
Subject: Re: [Uri-review] ssh URI

Hello,

Thank you for the feedback.  Could you help me with #2 on your list?  We
have this in the draft now:

"The SSH URI does not define a usage for a non-empty path element.  If a
non-empty path element is included in an SSH URI then it SHOULD be
ignored."

Should that specific sentence be amended or is there some additional
clarification necessary?

Steve

On Fri, Oct 09, 2009 at 07:51:50PM +0200, K?i?tof ?elechovski wrote:
>   1. [4.4] Outdated internal references: The parameters are not described
in
> section 4.1.
>   2. [4.4] The syntax does not forbid having a nonempty path component but
a
> semantic for one is not described.
>   3. [5.1] I would rather have
>
ssh://user@...?fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-7
> 7-10-d7-46-41-63-87
> for obvious reasons.
> Please consider
> Chris

[David Booth-6]

I don't see a need to define a new URI scheme for this.  You can just
define an http URI prefix for this purpose, as described in
http://dbooth.org/2006/urn2http/

Furthermore, as Graham Klyne suggested during a similar discussion
earlier, "an HTTP URI can also retrieve a protocol [handler]
implementation"
http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
This could dramatically improve the adoption rate of a new protocol.

David Booth


On Fri, 2009-10-09 at 11:01 -0500, Steve Suehring wrote:

> Hello,
>
> Attached is a draft to be submitted to the IETF for URI scheme related
> to secure shell (ssh).  The draft was originally included in the secsh
> Working Group which has since concluded.  
>
> http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/
>
> I recently received a request to pick this draft back up and the
> co-author and I will be submitting it to the IETF under the Application
> Area.
>
> Please provide feedback as appropriate.
>
> Thank you for your time.
>
> Steve Suehring
> _______________________________________________
> Uri-review mailing list
> Uri-review@...
> https://www.ietf.org/mailman/listinfo/uri-review

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Dan Brickley-2]

On Mon, Oct 12, 2009 at 7:01 PM, David Booth <david@...> wrote:
> I don't see a need to define a new URI scheme for this.  You can just
> define an http URI prefix for this purpose, as described in
> http://dbooth.org/2006/urn2http/
>
> Furthermore, as Graham Klyne suggested during a similar discussion
> earlier, "an HTTP URI can also retrieve a protocol [handler]
> implementation"
> http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
> This could dramatically improve the adoption rate of a new protocol.

You'd really be advocating retrieval of SSH protocol handlers over
untrusted HTTP connections? That's brave or something!

Dan

[David Booth-6]

On Mon, 2009-10-12 at 19:07 +0200, Dan Brickley wrote:

> On Mon, Oct 12, 2009 at 7:01 PM, David Booth <david@...> wrote:
> > I don't see a need to define a new URI scheme for this.  You can just
> > define an http URI prefix for this purpose, as described in
> > http://dbooth.org/2006/urn2http/
> >
> > Furthermore, as Graham Klyne suggested during a similar discussion
> > earlier, "an HTTP URI can also retrieve a protocol [handler]
> > implementation"
> > http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
> > This could dramatically improve the adoption rate of a new protocol.
>
> You'd really be advocating retrieval of SSH protocol handlers over
> untrusted HTTP connections? That's brave or something!

Good point.  For this application one would presumably choose an HTTP
URI prefix that starts with "https:" rather than "http:".  :)



--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

['Steve Suehring']

I don't think that the http URI prefix is a good solution for the ssh
protocol.  There is too much room for userland confusion which is
undesirable due to the nature of ssh traffic.

Steve


On Mon, Oct 12, 2009 at 01:01:34PM -0400, David Booth wrote:

> I don't see a need to define a new URI scheme for this.  You can just
> define an http URI prefix for this purpose, as described in
> http://dbooth.org/2006/urn2http/
>
> Furthermore, as Graham Klyne suggested during a similar discussion
> earlier, "an HTTP URI can also retrieve a protocol [handler]
> implementation"
> http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
> This could dramatically improve the adoption rate of a new protocol.
>
> David Booth
>

[David Booth-6]

On Mon, 2009-10-12 at 19:50 +0200, Eliot Lear wrote:
> David,
>
> I see some definite negatives to what you are suggesting:
>
>      1. Requires some sort of consortia or legal framework.

It does require something, but it isn't much -- just the maintenance of
a URI domain.  You could even base your URI prefixes on purl.org PURLs,
if want to permit the resolution to move around over time:
http://purl.org/docs/index.html

>      1. Requires an additional resolution.  SSH is commonly used for
>         administration, and so I would be loathe to add that sort of
>         step.

No, it doesn't *require* an additional resolution.  The additional
resolution only comes into play as a fallback, if the client doesn't
know how to handle them as special SSH URIs.  

>      1. Requires ssh applications to understand HTTP URI schema.

No, they just need to know to recognize the special SSH HTTP URI prefix,
which might be something like "http://sshuri.org/".  This is no
different in principle from recognizing the special "ssh:" URI prefix if
a new scheme is used.

David Booth

> Or do I misread what you are suggesting?
>
> Eliot
>
>
>
> On 10/12/09 7:01 PM, David Booth wrote:
> > I don't see a need to define a new URI scheme for this.  You can just
> > define an http URI prefix for this purpose, as described in
> > http://dbooth.org/2006/urn2http/
> >
> > Furthermore, as Graham Klyne suggested during a similar discussion
> > earlier, "an HTTP URI can also retrieve a protocol [handler]
> > implementation"
> > http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
> > This could dramatically improve the adoption rate of a new protocol.
> >
> > David Booth
> >
> >
> > On Fri, 2009-10-09 at 11:01 -0500, Steve Suehring wrote:
> >  
> > > Hello,
> > >
> > > Attached is a draft to be submitted to the IETF for URI scheme related
> > > to secure shell (ssh).  The draft was originally included in the secsh
> > > Working Group which has since concluded.  
> > >
> > > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/
> > >
> > > I recently received a request to pick this draft back up and the
> > > co-author and I will be submitting it to the IETF under the Application
> > > Area.
> > >
> > > Please provide feedback as appropriate.
> > >
> > > Thank you for your time.
> > >
> > > Steve Suehring
> > > _______________________________________________
> > > Uri-review mailing list
> > > Uri-review@...
> > > https://www.ietf.org/mailman/listinfo/uri-review
> > >    
>

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Křištof Želechovski]

David, you do not see a need to define a new URI scheme for anything, do
you?.  If I you do, please enumerate the requirements for a protocol that
would save it from the http black hole.
SSH is not a new protocol, and the "adoption rate" does not depend on the
URI; it is an agreement between the owner and the user that counts.  This
agreement already provides all technical information the user needs, and
explaining it over HTTP would not be useful.
And how would you persuade the Web browser to send an HTTP SSH URI to an
external handler instead of navigating to it?  (Think Internet Explorer, for
clarity.)
Chris

-----Original Message-----
From: uri-review-bounces@... [mailto:uri-review-bounces@...] On
Behalf Of David Booth
Sent: Monday, October 12, 2009 7:02 PM
To: Steve Suehring
Cc: uri-review@...; uri@...
Subject: Re: [Uri-review] ssh URI

I don't see a need to define a new URI scheme for this.  You can just
define an http URI prefix for this purpose, as described in
http://dbooth.org/2006/urn2http/

Furthermore, as Graham Klyne suggested during a similar discussion
earlier, "an HTTP URI can also retrieve a protocol [handler]
implementation"
http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
This could dramatically improve the adoption rate of a new protocol.

David Booth

[Dan Brickley-2]

On 12 Oct 2009, at 21:35, Kristof Zelechovski <giecrilj@...>  
wrote:

> David, you do not see a need to define a new URI scheme for  
> anything, do
> you?.  If I you do, please enumerate the requirements for a protocol  
> that
> would save it from the http black hole.
> SSH is not a new protocol, and the "adoption rate" does not depend  
> on the
> URI; it is an agreement between the owner and the user that counts.  
> This
> agreement already provides all technical information the user needs,  
> and
> explaining it over HTTP would not be useful.
> And how would you persuade the Web browser to send an HTTP SSH URI  
> to an
> external handler instead of navigating to it?  (Think Internet  
> Explorer, for
> clarity.)

...which in turn would have rather awkward privacy characteristics.

A custom scheme makes sense to me.

Dan

[Sandro Hawke]

> On Mon, 2009-10-12 at 19:50 +0200, Eliot Lear wrote:
> > David,
> >
> > I see some definite negatives to what you are suggesting:
> >
> >      1. Requires some sort of consortia or legal framework.
>
> It does require something, but it isn't much -- just the maintenance of
> a URI domain.  You could even base your URI prefixes on purl.org PURLs,
> if want to permit the resolution to move around over time:
> http://purl.org/docs/index.html
>
> >      1. Requires an additional resolution.  SSH is commonly used for
> >         administration, and so I would be loathe to add that sort of
> >         step.
>
> No, it doesn't *require* an additional resolution.  The additional
> resolution only comes into play as a fallback, if the client doesn't
> know how to handle them as special SSH URIs.  
>
> >      1. Requires ssh applications to understand HTTP URI schema.
>
> No, they just need to know to recognize the special SSH HTTP URI prefix,
> which might be something like "http://sshuri.org/".  This is no
> different in principle from recognizing the special "ssh:" URI prefix if
> a new scheme is used.

David, the nice thing about distributed extensibility -- which I think
is the main argument in favor of what you're proposing -- is that you
don't need to convince the IETF.  Instead, you have to convince the
market.  Which is easier, I have no idea....  but you can go ahead (as
you did with t-d-b.org) and set up the service, and try to get people to
adopt it.  (Fortunately, you don't need to convince a consensus of the
market; the utility grows smoothly as more people adopt it.  I guess the
utility is linear until folks start recognizing that prefix, then it
jumps a bit.)  

    -- Sandro

[Sporkmonger]

> I don't think that the http URI prefix is a good solution for the ssh
> protocol.  There is too much room for userland confusion which is
> undesirable due to the nature of ssh traffic.
>
> Steve

I have to agree with Steve on this.  I'm already terribly confused by
David's suggestion.

-Bob Aman

[David Booth-6]

On Mon, 2009-10-12 at 21:35 +0200, Kristof Zelechovski wrote:
> David, you do not see a need to define a new URI scheme for anything, do
> you?.  If I you do, please enumerate the requirements for a protocol that
> would save it from the http black hole.

You are correct that I see very little need for new URI schemes.  Nearly
all of what would be done by defining a new URI scheme can be done
(better, IMO) by leveraging http URIs.  

However, there *are* some inherent differences that I see between using
a new URI scheme and using http URIs, as described in
http://dbooth.org/2006/urn2http/#differences
[[
 * URI Length.  HTTP URIs will generally be longer.
 * Governing Authority.  New URI schemes must be registered with IANA,
whereas specialized HTTP prefixes may be defined by any URI owner.  This
may be a concern, both because IANA may be perceived as being more
reputable than other organizations, and because IANA provides a single
place to look for scheme definitions.  However, if this concern is
important enough, a registry of specialized HTTP prefixes could be
created by a reputable organization -- potentially even IANA.
 * Expectations.  Users discovering an xyzscheme URI expect it to be
governed by a separate specification, whereas users discovering an HTTP
URI with a specialized prefix may not realize that there is a separate
specification governing it (over and above the http scheme
specification).  This can be mitigated by educating users, and one good
way to do so is to serve useful metadata (indirectly) via the URI, as
described above.
]]

I *do* think that these differences provide reasonable grounds for new
schemes in some cases.  But I think proposers of new URI schemes far too
often fail to adequately explore the possibilities (and bootstrapping
benefits) of using http URIs and, in some cases, HTTP protocol
extensions.  I think there is a strong tendency to assume (erroneously)
that http URIs are limited to the HTTP protocol and thus dismiss them.
This has been quite evident in past discussions about proposed new
schemes.

I don't think I could enumerate all of the considerations important in
deciding whether a new URI scheme is justified, but I do think it would
be appropriate to play out the scenario both ways and compare the
results.  

For example, suppose an HTTP URI prefix were defined, such as
"http://sshuri.org?" (and as of this writing, that domain is available,
BTW).  And suppose that site were set up such that dereferencing one of
those URIs in a browser redirected to a page containing:

 - A brief explanation of SSH URIs, and pointers to tutorials and
specifications.

 - Downloadable software that would cause the browser to recognize such
URIs in the future, and handle them appropriately (i.e., by opening a
secure shell, rather than by fetching a page from sshuri.org).
Furthermore, such software might even be programmed to recognize and
handle the "ssh:" URI scheme as well.

How quickly would user clients implement SSH URIs this way versus if a
new scheme (only) had been used?

Basically, instead of *guessing* that the market would accept and
implement SSH URIs (through a new URI scheme), the HTTP URI approach
would provide a means to demonstrate that the market *had* accepted and
implemented support for SSH URIs.

> SSH is not a new protocol, and the "adoption rate" does not depend on the
> URI; it is an agreement between the owner and the user that counts.  This
> agreement already provides all technical information the user needs, and
> explaining it over HTTP would not be useful.

I was referring to the adoption rate for clients (such as browsers)
recognizing these new SSH URIs and using them for their intended
purpose.  A browser encountering a URI beginning "ssh:..." will not be
able to do anything useful with it until it knows the special semantics
assigned to the "ssh:" prefix.  But a browser encountering a URI
beginning "https://sshuri.org/..." could try to dereference that URI and
could be led to software that, once installed, *would* know to open an
SSH connection when encountering such a URI.  This could dramatically
improve the rate at which browsers learn how to handle these SSH URIs.
Make sense?

> And how would you persuade the Web browser to send an HTTP SSH URI to an
> external handler instead of navigating to it?  (Think Internet Explorer, for
> clarity.)

The same way you would persuade it to launch an SSH connection when an
"ssh:" URI is encountered: the browser needs to know about the semantics
associated with that URI prefix.

David Booth

> Chris
>
> -----Original Message-----
> From: uri-review-bounces@... [mailto:uri-review-bounces@...] On
> Behalf Of David Booth
> Sent: Monday, October 12, 2009 7:02 PM
> To: Steve Suehring
> Cc: uri-review@...; uri@...
> Subject: Re: [Uri-review] ssh URI
>
> I don't see a need to define a new URI scheme for this.  You can just
> define an http URI prefix for this purpose, as described in
> http://dbooth.org/2006/urn2http/
>
> Furthermore, as Graham Klyne suggested during a similar discussion
> earlier, "an HTTP URI can also retrieve a protocol [handler]
> implementation"
> http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
> This could dramatically improve the adoption rate of a new protocol.
>
> David Booth
>
>
>
>
>

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[David Booth-6]

On Mon, 2009-10-12 at 19:51 -0400, Daniel R. Tobias wrote:
> On 12 Oct 2009 at 21:35, Kristof Zelechovski wrote:
>
> > David, you do not see a need to define a new URI scheme for anything, do
> > you?.  If I you do, please enumerate the requirements for a protocol that
> > would save it from the http black hole.
>
> It does seem to be an ideological position for some.

Excuse me?  By piggy-backing on http URIs, you can get easier, faster
adoption with more user-friendly fallback behavior.   To my mind that's
an engineering concern -- not an idealogical position.  

 

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Sporkmonger]

>  - Downloadable software that would cause the browser to recognize such
> URIs in the future, and handle them appropriately (i.e., by opening a
> secure shell, rather than by fetching a page from sshuri.org).
> Furthermore, such software might even be programmed to recognize and
> handle the "ssh:" URI scheme as well.

I have a problem with this in the general case because I don't think
there's currently a way for such a URI to be registered to a specific
application in any major browser.  And for the specific case, I can
think of at least one use case where you might want to link to an ssh
URI in a browser:  HTTP-based admin interfaces to machines.

And I'll also repeat my previous comment for emphasis:  This concept
is just confusing.

-1 to the concept of using anything under the http/https scheme to
formally represent an ssh identifier.

-Bob Aman

[David Booth-6]

On Mon, 2009-10-12 at 21:16 -0400, Bob Aman wrote:
> >  - Downloadable software that would cause the browser to recognize such
> > URIs in the future, and handle them appropriately (i.e., by opening a
> > secure shell, rather than by fetching a page from sshuri.org).
> > Furthermore, such software might even be programmed to recognize and
> > handle the "ssh:" URI scheme as well.
>
> I have a problem with this in the general case because I don't think
> there's currently a way for such a URI to be registered to a specific
> application in any major browser.  

Take a look at greasemonkey:
https://addons.mozilla.org/en-US/firefox/addon/748 
Greasemonkey is based on recognizing URI patterns and performing special
functions when such patterns are recognized.

David Booth

> And for the specific case, I can
> think of at least one use case where you might want to link to an ssh
> URI in a browser:  HTTP-based admin interfaces to machines.
>
> And I'll also repeat my previous comment for emphasis:  This concept
> is just confusing.
>
> -1 to the concept of using anything under the http/https scheme to
> formally represent an ssh identifier.
>
> -Bob Aman
>
>

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Sporkmonger]

>> I have a problem with this in the general case because I don't think
>> there's currently a way for such a URI to be registered to a specific
>> application in any major browser.
>
> Take a look at greasemonkey:
> https://addons.mozilla.org/en-US/firefox/addon/748
> Greasemonkey is based on recognizing URI patterns and performing special
> functions when such patterns are recognized.

I'm familiar with greasemonkey.  Last I checked, greasemonkey didn't
launch applications so much as rewrite pages in place, and even if it
could, that's not even remotely user-friendly.  Beyond that, it's not
something that really applies outside of the Firefox ecosystem.  The
point isn't that it's not technically feasible, the point is that it's
a path that has way more technical and psychological hurdles to
overcome than getting a scheme registered with the IANA.

-Bob Aman

[Conrad Parker-4]

2009/10/13 David Booth <david@...>:

>
> I was referring to the adoption rate for clients (such as browsers)
> recognizing these new SSH URIs and using them for their intended
> purpose.  A browser encountering a URI beginning "ssh:..." will not be
> able to do anything useful with it until it knows the special semantics
> assigned to the "ssh:" prefix.  But a browser encountering a URI
> beginning "https://sshuri.org/..." could try to dereference that URI and
> could be led to software that, once installed, *would* know to open an
> SSH connection when encountering such a URI.  This could dramatically
> improve the rate at which browsers learn how to handle these SSH URIs.
> Make sense?

Encouraging end-users to download ssh client software from a random
web site specified by a third-party web-page author, and then
(automatically) using that software to connect to the desired ssh
server ... and hoping that this is somehow secure by using an SSL/TLS
connection to access that software?

No, this does not make sense. It encourages use of untrusted ssh
client software (eg. not sourced from your operating system vendor,
unsigned etc.) so the scheme could be easily exploited by a third
party to serve an ssh client with a backdoor. Using https to access
that info/software does nothing to secure the initiation of the ssh
connection.

If anything, ssh provides a good use-case for a custom uri scheme.

Conrad.

[David Booth-6]

On Mon, 2009-10-12 at 21:55 -0400, Bob Aman wrote:

> >> I have a problem with this in the general case because I don't think
> >> there's currently a way for such a URI to be registered to a specific
> >> application in any major browser.
> >
> > Take a look at greasemonkey:
> > https://addons.mozilla.org/en-US/firefox/addon/748
> > Greasemonkey is based on recognizing URI patterns and performing special
> > functions when such patterns are recognized.
>
> I'm familiar with greasemonkey.  Last I checked, greasemonkey didn't
> launch applications so much as rewrite pages in place, and even if it
> could, that's not even remotely user-friendly.  Beyond that, it's not
> something that really applies outside of the Firefox ecosystem.  The
> point isn't that it's not technically feasible, the point is that it's
> a path that has way more technical and psychological hurdles to
> overcome than getting a scheme registered with the IANA.

Getting a scheme registered is the *easy* part.  The hard part is
getting millions of installed clients to implement the special
recognition of that scheme.


--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.