Internet Engineering Task Force                            V. Breitmoser
Internet-Draft
Intended status: Experimental                             April 24, 2015
Expires: October 26, 2015


                     Linked Identities for OpenPGP
                     draft-vb-openpgp-linked-ids-01

Abstract

   This document introduces a URI scheme for Linked Identitites to be
   used in URI Attributes in OpenPGP keys compatible to [RFC4880] and
   [URIATTR].  A Linked Identity then links the key to a resource on the
   internet in a mutual and verifiable way.  The assumed authorization
   required to publish the resource forms a limited basis of trust for
   the key.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on October 26, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Breitmoser              Expires October 26, 2015                [Page 1]


Internet-Draft        Linked Identities for OpenPGP           April 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   2
   2.  Linked Identities . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Linked Attibutes  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Certification . . . . . . . . . . . . . . . . . . . . . .   4
   4.  The openpgpid+cookie Linked Identity Scheme . . . . . . . . .   4
     4.1.  Scheme Definition . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Scheme Semantics  . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Linked Resource Cookies . . . . . . . . . . . . . . . . .   5
       4.3.1.  Alternative Cookie Formats  . . . . . . . . . . . . .   6
     4.4.  Verification  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     5.1.  Trust Model Implications  . . . . . . . . . . . . . . . .   7
     5.2.  Linked Resource Verification  . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Registration Template  . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The OpenPGP specification [RFC4880] allows primary keys to associate
   themselves with identities in the form of User ID and User Attribute
   packets.  User IDs consist of a readable string in UTF-8 format,
   which contains the name and email address of the key holder.
   However, the content of those identity types is only convention,
   leaving the user with only the raw content as a basis for trust
   decisions.

   This document introduces a Linked Identity URI scheme to be used in
   URI Attributes as defined in URI Attributes for OpenPGP [URIATTR].
   The purpose of such identity is to mutually connect the key to a
   resource on the internet, which has some type of established
   credibility, thereby providing an ad-hoc method of authentication.

1.1.  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 [RFC2119].  Any



Breitmoser              Expires October 26, 2015                [Page 2]


Internet-Draft        Linked Identities for OpenPGP           April 2015


   implementation that adheres to the format and methods specified in
   this document is called a compliant application.  Compliant
   applications are a subset of the broader set of OpenPGP applications
   described in [RFC4880].  Any [RFC2119] keyword within this document
   applies to compliant applications only.

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC2234], including the following core ABNF syntax rules
   defined by that specification: ALPHA (letters), CR (carriage return),
   DIGIT (decimal digits), DQUOTE (double quote), HEXDIG (hexadecimal
   digits), LF (line feed), and SP (space).

2.  Linked Identities

   A Linked Identity is a type of identity in an OpenPGP key akin to
   User IDs and JPEG Attributes, and shares all fundamental properties
   of those identity types including self-certification lifecycle,
   foreign certifications and distribution mechanisms.  Unlike those
   types though, a Linked Identity consists not only of the Linked
   Attribute distributed with the key (see Section 3), but is also
   linked to an external resource known as the Linked Resource.  The
   only required property of a Linked Resource is that it must be
   uniquely identifiable by a URI, it is otherwise an abstract concept.
   As a more concretely specified type of Linked Identities, this
   document introduces the Cookie-Type Linked Identity (Section 4).

   As part of a key, a Linked Identity constitutes a verifiable claim of
   control by the key owner over the Linked Resource.  The verification
   of this link is intended to require little or no user interaction.
   Differently from User IDs, the meaning of a Linked Identity Attribute
   is not based on itself, but instead on the connection between the
   Linked Attribute and Linked Resource, providing evidence that the
   owner of the key also controls the referenced resource.  This
   information can then be presented to the user as supporting
   information.

3.  Linked Attibutes

   A Linked Attribute is a URI Attribute as specified in URI Attributes
   for OpenPGP [URIATTR] where the scheme of the contained URI has a
   defined meaning in terms of a Linked Identity.  The general semantics
   of a Linked Attribute are defined by the scheme of its URI, which
   should have a well-defined VERIFY operation.

   The VERIFY operation on a Linked Identity URI verifies the link
   between the Linked Attribute (or its key) and its Linked Resource.
   The semantics of this operation are defined by its scheme but may,
   for the sake of flexibility, not have a generic mechanism even for a



Breitmoser              Expires October 26, 2015                [Page 3]


Internet-Draft        Linked Identities for OpenPGP           April 2015


   defined scheme.  Because of this, the URI format was chosen as a
   human readable representation to allow for a generic way of
   displaying unsupported Linked Identity types, and to aid developer
   dialogue.

3.1.  Certification

   Certifications on Linked Attributes are slightly more defined than on
   other packets: A compliant implementation MUST NOT issue a
   certificate over a Linked Attribute without a positive result from a
   VERIFY operation performed on its URI, but it MAY issue one based on
   the result of a VERIFY operation exclusively.  Conversely, an
   implementation SHOULD NOT assume that certificates make any statement
   about the genuineness of the Linked Resource or the key itself other
   than the success of the VERIFY operation on the certified User
   Attribute from the perspective of the issuer.

   This definition has implications on trust models based on Linked
   Identities, see Section 5.

4.  The openpgpid+cookie Linked Identity Scheme

   The openpgpid+cookie scheme in a Linked Attribute describes a claim
   of control over a Linked Resource which is synchronously accessible
   for its target audience.  To this end, it requires the creator to
   place a Linked Resource Cookie at the site referenced by a wrapped
   URI, which may then be accessed and verified independently from the
   key owner at any point in time after its creation.  This synchronous
   accessibility is the only requirement to make a resource suitable for
   use as a Linked Resource of this type.  Exemplary use cases are
   connecting a key to its owner's website, profiles on social media, or
   owned domain names.

4.1.  Scheme Definition

   The openpgpid+cookie scheme is defined as follows:

       linked-uri = scheme ":" [options] "@" <absolute-URI>
       scheme = "pgpid+cookie"
       options = ( option / flag ) [";" options]
       option = key "=" value
       flag = key
       key = *(<unreserved>)
       value = *(<unreserved> / <pct-encoded> / ",")

   Where the grammar for <absolute-URI>, <unreserved> and <pct-encoded>
   are defined as in [RFC3986].  The scheme includes a wrapped, absolute
   URI plus any number of flags and/or pairs of key-value options.



Breitmoser              Expires October 26, 2015                [Page 4]


Internet-Draft        Linked Identities for OpenPGP           April 2015


   Resulting from the definition of the URI Attribute, the encoding of
   the URI is fixed to UTF-8 (see [URIATTR]).  While the flag and option
   part of the URI use a restricted character set from which no encoding
   issues should arise, considerations of the wrapped URI must be taken
   into account.  It is generally the job of the issuer of a Linked
   Attribute to make sure the encoding is compatible, others who process
   it may safely treat encoding errors in a fail-fast manner.

   Examples of openpgpid+cookie URIs:

       openpgpid+cookie:@https://social.example.net/account/message
       openpgpid+cookie:@dns:example.org?TYPE=TXT
       openpgpid+cookie:@dns:example.org?TYPE=OPENPGPKEY
       openpgpid+cookie:generic@https://example.com/pgpkey.txt

4.2.  Scheme Semantics

   The usual semantics and operations of the wrapped URI explicitly do
   not apply.  Instead, the scheme defines the VERIFY operation (see
   Section 3), which if successful yields a result on the validity of
   the Linked Identity.  This operation is defined in the context of its
   key, and parametrized by the flags and options.  If any flag or
   option is unknown to an implementation, the entire Linked Identity
   URI MUST be treated as not supported.  For details on the VERIFY
   operation, see Section 4.4.

   The definition of semantics for specific wrapped URIs is out of scope
   for this document.

4.3.  Linked Resource Cookies

   To create a Linked Identity of the openpgpid+cookie scheme, the owner
   of a key publishes a Linked Identity Cookie at the desired site.  The
   usual format for this cookie is a simple string in plain text format,
   although others are possible (see Section 4.3.1).  The text format
   begins with an opening bracket, followed by the string "Verifying my
   OpenPGP key ", followed by a URI and a closing bracket.  The
   contained URI refers back to the key.

       cookie = "[" "Verifying my OpenPGP key " cookieuri  "]"
       cookieuri = "openpgp4fpr" ":" fingerprint
       fingerprint = 40<HEXDIG>

   The cookieuri follows the openpgp4fpr scheme, which unambiguously
   identifies an OpenPGP key by its fingerprint.  Example of a Linked
   Identity Cookie:

    [Verifying my OpenPGP key openpgp4fpr:d4ab192964f76a7f8f8a9b357bd18320deadfa11]



Breitmoser              Expires October 26, 2015                [Page 5]


Internet-Draft        Linked Identities for OpenPGP           April 2015


   Because publishing a cookie may not be perceived as a security-
   critical operation, the cookie format is chosen to imply its meaning,
   reducing the risk of social engineering attacks.  It stands to reason
   that a user could more easily be manipulated into publishing a bare
   openpgp4fpr URI than a cookie with the text snippet included.

4.3.1.  Alternative Cookie Formats

   If for some reason a cookie cannot be placed at a site in this format
   - for example due to a restricted available character set - it may be
   encoded in a simple encoding scheme.  There are no restrictions on
   this encoding, but it is RECOMMENDED to retain human readability, for
   example by trivially (but unambiguously) translating restricted
   characters.  It is NOT RECOMMENDED to insert more whitespace or
   newlines.

   For resource sites which are not human readable by nature, an
   implementation MAY accept Linked Resource Cookies which consist of
   the encoded fingerprint only.  Because of the aforementioned risk of
   social engineering attacks, this should only be done with careful
   consideration.

4.4.  Verification

   To perform the VERIFY operation on a typical openpgpid+cookie URI,
   the resource is requested as referred to by the wrapped URI.  From
   this reply, the cookie is extracted and possibly decoded, and then
   matched against the cookie expected for the Linked Identity packet.
   The particular mechanisms for requesting and extracting the cookie
   may be specific to the entire Linked Identity URI, including flags
   and options.  For the Linked Identity to be considered valid, the
   extracted cookie text must match the expected value.  An
   implementation MAY allow some flexibility in the cookie matching
   routine, but such decisions should be made with care.  See
   Section 5.2.

   An implementation SHOULD NOT perform verification based on a generic
   mechanism, unless specifically instructed to do so.  While it is
   possible to retrieve the contents of a wrapped URI with a https
   scheme in a generic way, a proper VERIFY operation might require
   additional insight.  For example, profiles on social media websites
   may include comment sections or other parts which are not entirely
   user-controlled, and thus require extraction of the specific, owner-
   controlled part.  The use case of a website retrieved in a generic
   way is a special case of Linked Resource and should be indicated with
   a flag.





Breitmoser              Expires October 26, 2015                [Page 6]


Internet-Draft        Linked Identities for OpenPGP           April 2015


   For certification, see the general notes on certification of Linked
   Identities in Section 3.1.

5.  Security Considerations

   The specification of Linked Identities in this document includes
   implications on a trust model which is based on Linked Attributes.
   This is unlike the general practice of [RFC4880], which strictly
   sticks to a technical description of the data exchange format.

5.1.  Trust Model Implications

   Linked Identities diverge from established certification practices,
   since the assumptions which can be drawn from foreign certifications
   issued for Linked Identities have a defined upper bound;
   Specifically, an implementation MUST NOT assume a certification to
   have any more meaning than the success of the VERIFY operation from
   the issuer's perspective (see Section 3.1).  This affects a possible
   trust model in two ways: Firstly, the certificates issued by foreign
   keys should only be regarded as evidence for the validity of the
   Linked Identity, not of the genuineness of the Linked Resource or the
   key owner.  Secondly, it allows automated services to issue
   certifications for Linked Identities which are verifiable from their
   perspective.

   As a means of authentication, Linked Identities are a vector for Man-
   in-the-Middle attacks.  The difference between the verification of a
   Linked Identity and the authentication of the owner of a key in
   particular may be non-obvious to users.  While a certificate may be
   issued and published based on the VERIFY operation alone, the
   decision of whether the key as a whole is trustworthy must at some
   point take into account the genuineness of the Linked Resource.  An
   implementation should take care to provide the user with sufficient
   guidance on this matter.

5.2.  Linked Resource Verification

   The security properties of a Linked Identity depend on the
   reliability of the URI-specific mechanism for verification.  For this
   reason, it is very important that this mechanism is robust against
   false positives.  An implementation should be very conservative about
   what is accepted as a valid Linked Resource.  This especially
   includes acceptance of any sort of alternative cookie format (see
   Section 4.3.1).

   In the case of Linked URIs with a https scheme, scraping the content
   of the linked site during verification should be avoided if possible.
   For example, if the service used in the URI provides an API, and the



Breitmoser              Expires October 26, 2015                [Page 7]


Internet-Draft        Linked Identities for OpenPGP           April 2015


   URI contains information like a message id which can be parsed and
   used to access the content directly via the API, this method should
   be preferred.

6.  IANA Considerations

   The IANA is asked to register the openpgp+cookie URI scheme as a
   provisional scheme according with [RFC2717].  See the registration
   template in Appendix A.

7.  Acknowledgements

   This document was created with substantial feedback from Dominik
   Schuermann and Daniel Kahn Gillmor.  The general concept of Linked
   Identities for OpenPGP (albeit in a centralized and out-of-band
   fashion) was first deployed by the founders and contributors of
   [keybase], whose work this document is heavily inspired by.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2717]  Petke, R. and I. King, "Registration Procedures for URL
              Scheme Names", BCP 35, RFC 2717, November 1999.

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

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [URIATTR]  Breitmoser, V., "URI Attributes for OpenPGP", 2015,
              <http://www.ietf.org/id/
              draft-vb-openpgp-uri-attribute-00.txt>.

8.2.  Informative References

   [keybase]  Krohn, and Coyne, "Keybase", <https://keybase.io>.






Breitmoser              Expires October 26, 2015                [Page 8]


Internet-Draft        Linked Identities for OpenPGP           April 2015


Appendix A.  Registration Template

   URI scheme name: openpgpid+cookie

   URI scheme syntax: See Section 4.1

   URI scheme semantics: See Section 4.2

   Intended usage: See Section 4

   Encoding considerations: See Section 4.1

   Applications/protocols that use this URI scheme name: The
   openpgpid+cookie scheme appears in URI Packets of OpenPGP compliant
   keys.

   Interoperability considerations: None.

   Security considerations: Section 5

   Contact: V.  Breitmoser, see below

   Author/Change controller: IESG

Author's Address

   Vincent Breitmoser
   Braunschweig
   DE

   Email: v.breitmoser@my.amazin.horse




















Breitmoser              Expires October 26, 2015                [Page 9]