[Uri-review] Review request for gittorrent: URI scheme

[Chris Rebert <[e-mail]>]

Hello,

Per the advice of RFC 7595, I hereby present the following proposed
registration of the "gittorrent" provisional URI scheme for review.
Any feedback is greatly appreciated. Thanks.

Cheers,
Chris
****
http://chrisrebert.com
Browser 🐛 of the day: http://bugzil.la/1259972

********

Scheme name:  gittorrent

Status:  Provisional

Applications/protocols that use this scheme name:
  GitTorrent ("A decentralization of GitHub using BitTorrent and
  Bitcoin")

Contact:
  Scheme creator:
    Chris Ball <http://printf.net/>
  Registering party:
    Chris Rebert <[e-mail]>

Change controller:
  Either the scheme creator or the registering party.

References:
  Ball, C., "Announcing GitTorrent: A Decentralized GitHub", 29 May
  2015,
      <http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/>.
  Ball, C., "GitTorrent", 2016, <http://gittorrent.org/>.
  Ball, C., "GitTorrent", 2016, <https://github.com/cjb/GitTorrent>.
  Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and B. Yang,
      "Ed25519: high-speed high-security signatures", 27 September 2011,
      <https://ed25519.cr.yp.to/>.
  Bitcoin Project, "Bitcoin - Open source P2P money", 2016,
      <https://bitcoin.org/en/>.
  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange
      Format", RFC 7159, March 2014.
  Cohen, B., "BEP 3: The BitTorrent Protocol Specification", 11 October
  2013,
      <http://www.bittorrent.org/beps/bep_0003.html>.
  Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
  RFC 3174,
      September 2001.
  "Git", 2016, <https://git-scm.com/>.

Scheme syntax:
  This scheme uses a profile of the RFC 3986 generic URI syntax.
  The "fragment" URI component is never permitted.

  A gittorrent URI may come in one of three forms:

    0. Where the "authority" component is a domain name
      Example:  gittorrent://github.com/cjb/recursers
      The "path" and "query" components have no extra restrictions.

    1. Where the "authority" component is a 40-byte hexadecimal number
    (the
       conventional representation of a SHA-1 hash digest)
      Example: 
      gittorrent://81e24205d4bac8496d3e13282c90ead5045f09ea/recursers
      In this case, the "query" component is not permitted, and
      the "path" component consists of exactly one segment (the Git
      repository
      name).

    2. Where the "authority" is a username
      Example:  gittorrent://cjb/foo
      In this case, the "query" component is not permitted, and
      the "path" component consists of exactly one segment (the Git
      repository
      name).

  There may be further restrictions on the format of usernames and
  repository
  names.

Scheme semantics:
  See the GitTorrent project for details.  The following is a summary of
  read-only usage.

  gittorrent URIs represent Git repositories and specify the metadata
  necessary
  to clone a repository, to read the repository's commits, and, with the
  necessary cryptographic key, to write commits to the repository.

  In URIs of type (0), the SHA-1 hash identifier of the latest commit of
  the
  primary branch is fetched via the git protocol, as if this had been a
  git:
  URI.  The actual data for that commit is then downloaded via
  BitTorrent.

  In URIs of type (1), the SHA-1 hash in the "authority" component is
  used as a
  key for a lookup in a BitTorrent DHT (distributed hash table).  The
  value
  obtained from the lookup is a JSON object representing a GitTorrent
  user
  profile, which includes the names of that user's repositories, the
  names of
  those repositories' git refs, and the SHA-1 hash identifiers of the
  commits
  that those refs currently point to.  The "path" component is the name
  of the
  repository, and is used to look up the corresponding SHA-1 hash commit
  identifier for the repository in the user profile.  The actual data
  for that
  commit is then downloaded via BitTorrent.

  In URIs of type (2), the username in the "authority" component is used
  for an
  OP_RETURN transaction lookup in Bitcoin's blockchain.  If successful,
  this
  lookup yields a SHA-1 hash which is then used as a key for a lookup in
  a
  BitTorrent DHT (distributed hash table).  The value obtained from the
  lookup
  is a JSON object representing a GitTorrent user profile (as described
  in the
  previous paragraph).  The "path" component is the name of the
  repository, and
  is used to look up the corresponding SHA-1 hash commit identifier for
  the
  repository in the user profile.  The actual data for that commit is
  then
  downloaded via BitTorrent.

Encoding considerations:
  Unknown, use with care.

Interoperability considerations:
  Not fully known, use with care.

  The "fragment" URI component has no known meaning or usage.  Unless it
  becomes meaningful in the future, omitting it is strongly advised.

Security considerations:
  Not fully known, use with care.

  GitTorrent normally uses public BitTorrent swarms, and thus doesn't
  ensure
  confidentiality of the Git data it stores.  Therefore it's normally
  unsuitable
  for Git repositories which contain unencrypted private data.  The
  confidentiality of the data when in transit between peers depends on
  the
  particular flavor of the BitTorrent protocol being used by the peers.

  Git and BitTorrent use SHA-1 hashes to ensure the integrity of the
  data.  The
  general security considerations for SHA-1 thus also apply to
  GitTorrent.
  GitTorrent uses Ed25519 as its digital signature scheme for ensuring
  the
  integrity and ownership of GitTorrent user profiles, and thus inherits
  the
  security considerations of Ed25519.

  gittorrent: URIs of type (0) refer to hosts using domain names.  The
  domain
  name resolution process is subject to its own set of security
  considerations
  (see RFC 4033).
  gittorrent: URIs of type (2) use GitTorrent usernames, which use the
  Bitcoin
  protocol/network for their registration infrastructure, and are thus
  subject
  to Bitcoin's security considerations.  Users of type (2) URIs should
  keep in
  mind that GitTorrent usernames don't necessarily correspond to the
  usernames
  of other Git-related systems, other source code management systems, or
  other
  software project management systems in general.  Users should
  externally
  verify the identities associated with GitTorrent usernames before
  utilizing
  gittorrent: URIs involving those usernames.

  Beware of homograph attacks when dealing with gittorrent: URIs. 
  Attackers may
  register GitTorrent usernames which deliberately appear visually
  similar to
  other GitTorrent usernames in an attempt to fool unwary users. 
  Attackers may
  likewise upload Git repositories with names which deliberately appear
  visually
  similar to those of other Git repositories.

  It's currently unclear precisely how GitTorrent software
  differentiates
  between gittorrent: URIs of type (0) and type (2).  For example,
  without
  further restrictions on allowed domain names, the URI
  gittorrent://abc/xyz
  could potentially either reference the top-level domain "abc" or the
  GitTorrent username "abc".  Similarly, without further restrictions on
  allowed
  GitTorrent usernames, the URI gittorrent://abc.xyz/qwe could
  potentially
  either reference the domain "abc.xyz" or the GitTorrent username
  "abc.xyz".
  The usage of gittorrent: URIs with usernames that contain periods
  should
  therefore be avoided for the time being.
  Accessing GitTorrent URIs while on an untrusted network is thus
  potentially
  dangerous, since a malicious network operator might be able to
  influence which
  interpretation the GitTorrent software chooses by causing the
  "username" to
  unexpectedly resolve as a domain name or by causing the domain name to
  resolve
  to the IP address of an attacker-controlled server.
  Git's integrity assurance mechanisms may allow these attacks to be
  detected in
  certain cases, provided that the Git repository had been previously
  cloned via
  a trustworthy mechanism.