< draft-mccain-keylist-04.txt   draft-mccain-keylist-05.txt >
Network Working Group M. McCain Network Working Group M. McCain
Internet-Draft FLM Internet-Draft FLM
Intended status: Standards Track M. Lee Intended status: Standards Track M. Lee
Expires: September 7, 2019 TI Expires: March 5, 2020 TI
N. Welch N. Welch
Google Google
March 6, 2019 September 2, 2019
Distributing OpenPGP Key Fingerprints with Signed Keylist Subscriptions Distributing OpenPGP Key Fingerprints with Signed Keylist Subscriptions
draft-mccain-keylist-04 draft-mccain-keylist-05
Abstract Abstract
This document specifies a system by which an OpenPGP client may This document specifies a system by which an OpenPGP client may
subscribe to an organization's public keylist to keep its keystore subscribe to an organization's public keylist to keep its keystore
up-to-date with correct keys, even in cases where the keys correspond up-to-date with correct keys from the correct keyserver(s), even in
to multiple (potentially uncontrolled) domains. Ensuring that all cases where the keys correspond to multiple (potentially
members or followers of an organization have their colleagues' most uncontrolled) domains. Ensuring that all members or followers of an
recent PGP public keys is critical to maintaining operational organization have their colleagues' most recent PGP public keys is
security. Without the most recent keys' fingerprints and a source of critical to maintaining operational security. Without the most
trust for those keys (as this document specifies), users must recent keys' fingerprints and a source of trust for those keys (as
manually update and sign each others' keys -- a system that is this document specifies), users must manually update and sign each
untenable in larger organizations. This document proposes a others' keys -- a system that is untenable in larger organizations.
experimental format for the keylist file as well as requirements for This document proposes a experimental format for the keylist file as
clients who wish to implement this experimental keylist subscription well as requirements for clients who wish to implement this
functionality. experimental keylist subscription functionality.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2019. This Internet-Draft will expire on March 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Note to Readers . . . . . . . . . . . . . . . . . . . . . 3 1.3. Note to Readers . . . . . . . . . . . . . . . . . . . . . 3
2. Functions and Procedures . . . . . . . . . . . . . . . . . . 4 2. Functions and Procedures . . . . . . . . . . . . . . . . . . 4
2.1. Subscribing to Keylists . . . . . . . . . . . . . . . . . 4 2.1. Subscribing to Keylists . . . . . . . . . . . . . . . . . 4
2.2. Automatic Updates . . . . . . . . . . . . . . . . . . . . 4 2.2. Automatic Updates . . . . . . . . . . . . . . . . . . . . 4
2.3. Cryptographic Verification of Keylists . . . . . . . . . 5 2.3. Cryptographic Verification of Keylists . . . . . . . . . 6
3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 6 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 6
3.1. Keylist . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Keylist . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Well-Known URL . . . . . . . . . . . . . . . . . . . . . 7 3.3. Well-Known URL . . . . . . . . . . . . . . . . . . . . . 8
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
5. Security Benefits . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Benefits . . . . . . . . . . . . . . . . . . . . . . 8
6. Relation to Other Technologies . . . . . . . . . . . . . . . 8 6. Relation to Other Technologies . . . . . . . . . . . . . . . 8
6.1. Web Key Directories . . . . . . . . . . . . . . . . . . . 8 6.1. Web Key Directories . . . . . . . . . . . . . . . . . . . 9
6.2. OPENPGPKEY DNS Records . . . . . . . . . . . . . . . . . 8 6.2. OPENPGPKEY DNS Records . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document specifies a system by which clients may subscribe to This document specifies a system by which clients may subscribe to
cryptographically signed 'keylists' of public key fingerprints. The cryptographically signed 'keylists' of public key fingerprints. The
skipping to change at page 3, line 22 skipping to change at page 3, line 22
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] . document are to be interpreted as described in [RFC2119] .
1.2. Terminology 1.2. Terminology
This document uses the terms "OpenPGP", "public key", "private key", This document uses the terms "OpenPGP", "public key", "private key",
"signature", and "fingerprint" as defined by OpenPGP Message Format "signature", and "fingerprint" as defined by OpenPGP Message Format
[RFC4880] . [RFC4880] (the fingerprint type SHOULD be V4).
The term "keylist" is defined as a list of OpenPGP public key The term "keylist" is defined as a list of OpenPGP public key
fingerprints and accessible via a URI. The exact format of this data fingerprints accessible via a URI in the format specified in
is specified in Section 3. Keylists SHOULD be treated as public Section 3. Keylists SHOULD be treated as public documents, however a
documents; although a system administrator MAY choose, for example, system administrator MAY choose, for example, to restrict access to a
to restrict access to a keylist to a specific subnet. keylist to a specific subnet or private network.
An "authority key" is defined as the OpenPGP secret key used to sign An "authority key" is defined as the OpenPGP secret key used to sign
a particular keylist. Every keylist has a corresponding authority a particular keylist. Every keylist has a corresponding authority
key, and every authority key has at least one corresponding keylist. key, and every authority key has at least one corresponding keylist.
A single authority key SHOULD NOT be used to sign multiple keylists. A single authority key SHOULD NOT be used to sign multiple keylists.
To be "subscribed" to a keylist means that a program will retreive To be "subscribed" to a keylist means that a program will retreive
that keylist on a regular interval. After retrieval, that program that keylist on a regular interval. After retrieval, that program
will perform an update to an internal OpenPGP keystore. will perform an update to an internal OpenPGP keystore.
skipping to change at page 4, line 6 skipping to change at page 4, line 6
keystore. keystore.
1.3. Note to Readers 1.3. Note to Readers
RFC Editor: please remove this section prior to publication. RFC Editor: please remove this section prior to publication.
Development of this Internet draft takes place on GitHub at Development of this Internet draft takes place on GitHub at
firstlookmedia/Keylist-RFC [1]. firstlookmedia/Keylist-RFC [1].
We are still considering whether this Draft is better for the We are still considering whether this Draft is better for the
Experimental or Informational track. Experimental or Informational track. All feedback is appreciated.
2. Functions and Procedures 2. Functions and Procedures
As new keys are created and other keys are revoked, it is critical As new keys are created and other keys are revoked, it is critical
that all members of an organization have the most recent set of keys that all members of an organization have the most recent set of keys
available on their computers. Keylists enable organizations to available on their computers. Keylists enable organizations to
publish a directory of OpenPGP keys that clients can use to keep publish a directory of OpenPGP keys that clients can use to keep
their internal keystores up-to-date. their internal keystores up-to-date.
2.1. Subscribing to Keylists 2.1. Subscribing to Keylists
skipping to change at page 5, line 15 skipping to change at page 5, line 15
When automatic background updates are provided, we RECOMMEND that When automatic background updates are provided, we RECOMMEND that
clients provide a default refresh interval of less than one day, clients provide a default refresh interval of less than one day,
however we also RECOMMEND that clients allow the user to select this however we also RECOMMEND that clients allow the user to select this
interval. The exact time at which updates are performed is not interval. The exact time at which updates are performed is not
critical. critical.
To perform an update, the client MUST perform the following steps on To perform an update, the client MUST perform the following steps on
each keylist to which it is subscribed. The steps SHOULD be each keylist to which it is subscribed. The steps SHOULD be
performed in the given order. performed in the given order.
1. Obtain a current copy of the keylist from its URI. 1. Obtain a current copy of the keylist from its URI. If a current
copy (i.e. not from local cache) cannot be obtained, the client
SHOULD abort the update for this keylist and notify the user.
The client SHOULD continue the update for other keylists to which
it is subscribed, notwithstanding also failing the criteria
described in this section.
2. Obtain a current copy of the keylist's signature data from its 2. Obtain a current copy of the keylist's signature data from its
URI, which is included in the keylist data format specified in URI, which is included in the keylist data format specified in
Section 3. Section 3. If a current copy cannot be obtained, the client
SHOULD abort the update and notify the user. The client SHOULD
continue the update for other keylists to which it is subscribed,
notwithstanding also failing the criteria described in this
section.
3. Using the keylist and the keylist's signature, cryptographically 3. Using the keylist and the keylist's signature, cryptographically
verify that the keylist was signed using the authority key. If verify that the keylist was signed using the authority key. If
the signature does not verify, the client MUST abort the update the signature does not verify, the client MUST abort the update
of this keylist and SHOULD alert the user. The client SHOULD NOT of this keylist and SHOULD alert the user. The client SHOULD NOT
abort the update of other keylists to which it is subscribed, abort the update of other keylists to which it is subscribed,
unless they too fail signature verification. unless they too fail signature verification.
4. Validate the format of the keylist according to Section 3 . If 4. Validate the format of the keylist according to Section 3 . If
the keylist is in an invalid format, the client MUST abort the the keylist is in an invalid format, the client MUST abort the
update this keylist and SHOULD alert the user. update this keylist and SHOULD alert the user. The client SHOULD
continue the update for other keylists to which it is subscribed,
notwithstanding also failing the criteria described in this
section.
5. For each fingerprint listed in the keyfile, if a copy of the 5. For each fingerprint listed in the keyfile, if a copy of the
associated public key is not present in the client's local associated public key is not present in the client's local
keystore, retrieve it from the keyserver specified by the keylist keystore, retrieve it from the keyserver specified by either the
(see Section 3) or, if the keylist specifies no keyserver, from key entry, the keylist (see Section 3) or, if the keylist
any keyserver. If the key is already present and not revoked, specifies no keyserver, from the user's default keyserver. If
refresh it from a keyserver. If it is present and revoked, do the public key cannot be found for a particular fingerprint, the
nothing. client MUST NOT abort the entire update process; instead, it
SHOULD notify the user that the key retrieval failed but
otherwise merely skip updating the key and continue. If the key
is already present and not revoked, refresh it from the keyserver
determined in the same manner as above. If it is present and
revoked, do nothing for that particular key.
2.3. Cryptographic Verification of Keylists 2.3. Cryptographic Verification of Keylists
To ensure authenticity of a keylist during an update, the client MUST To ensure authenticity of a keylist during an update, the client MUST
verify that the keylist's data matches its cryptographic signature, verify that the keylist's data matches its cryptographic signature,
and that the public key used to verify the signature matches the and that the public key used to verify the signature matches the
authority key fingerprint given by the user. authority key fingerprint given by the user.
For enhanced security, it is RECOMMENDED that keylist operators sign For enhanced security, it is RECOMMENDED that keylist operators sign
each public key listed in their keylist with the authority private each public key listed in their keylist with the authority private
skipping to change at page 6, line 24 skipping to change at page 6, line 40
defined below. Note that unless otherwise specified, 'key' in this defined below. Note that unless otherwise specified, 'key' in this
section refers to JSON keys -- not OpenPGP keys. section refers to JSON keys -- not OpenPGP keys.
To encode metadata, the keylist MUST have a "metadata" root key with To encode metadata, the keylist MUST have a "metadata" root key with
an object as the value ("metadata object"). The metadata object MUST an object as the value ("metadata object"). The metadata object MUST
contain a "signature_uri" key whose value is the URI string of the contain a "signature_uri" key whose value is the URI string of the
keylist's signature file. All metadata keys apart from keylist's signature file. All metadata keys apart from
"signature_uri" are OPTIONAL. "signature_uri" are OPTIONAL.
The metadata object MAY contain a "keyserver" key with the value of The metadata object MAY contain a "keyserver" key with the value of
the URI string of the keyserver from which the OpenPGP keys in the the URI string of a HKP keyserver from which the OpenPGP keys in the
keylist should be retrieved. keylist should be retrieved. Each PGP key listed in the keylist MAY
have a "keyserver" JSON key; if a PGP key in the keylist specifies a
HKP keyserver that is different from the one described in the
metadata object, the PGP key-specific keyserver should be used to
retrieve that particular key (and not the key listed in the metadata
object).
The metadata object MAY contain a "comment" key with the value of any The metadata object MAY contain a "comment" key with the value of any
string. The metadata object MAY also contain other arbitrary key- string. The metadata object MAY also contain other arbitrary key-
value pairs. value pairs.
The keylist MUST have a "keys" key with an array as the value. This The keylist MUST have a "keys" key with an array as the value. This
array contains a list of OpenPGP key fingerprints and metadata about array contains a list of OpenPGP key fingerprints and metadata about
them. Each item in the array MUST be an object. Each of these them. Each item in the array MUST be an object. Each of these
objects MUST have a "fingerprint" key with the value of a string that objects MUST have a "fingerprint" key with the value of a string that
contains the full 40-character hexadecimal public key fingerprint, as contains the full 40-character hexadecimal public key fingerprint, as
defined in OpenPGP Message Format [RFC4880] . Any number of space defined in OpenPGP Message Format [RFC4880] . Any number of space
characters (' ', U+0020) MAY be included at any location in the characters (' ', U+0020) MAY be included at any location in the
fingerprint string. These objects MAY contain "name", "email", and fingerprint string. These objects MAY contain "name" (the name of
"comment" key-value pairs, as well as any other key-value pairs the PGP key's owner), "email" (an email of the PGP key's owner),
relevant. "keyserver" (a HKP keyserver from which the key should be retrieved),
and "comment" key-value pairs, as well as any other key-value pairs.
The following is an example of a valid keylist. The following is an example of a valid keylist.
{ {
"metadata": { "metadata": {
"signature_uri": "https://www.example.com/keylist.json.asc", "signature_uri": "https://www.example.com/keylist.json.asc",
"comment": "This is an example of a keylist file" "comment": "This is an example of a keylist file"
}, },
"keys": [ "keys": [
{ {
"fingerprint": "927F419D7EC82C2F149C1BD1403C2657CD994F73", "fingerprint": "927F419D7EC82C2F149C1BD1403C2657CD994F73",
"name": "Micah Lee", "name": "Micah Lee",
"email": "micah.lee@theintercept.com", "email": "micah.lee@theintercept.com",
"comment": "Each key can have a comment" "comment": "Each key can have a comment"
}, },
{ {
"fingerprint": "1326CB162C6921BF085F8459F3C78280DDBF52A1", "fingerprint": "1326CB162C6921BF085F8459F3C78280DDBF52A1",
"name": "R. Miles McCain", "name": "R. Miles McCain",
"email": "0@rmrm.io" "email": "0@rmrm.io",
"keyserver": "https://keys.openpgp.org/"
}, },
{ {
"fingerprint": "E0BE0804CF04A65C1FC64CC4CAD802E066046C02", "fingerprint": "E0BE0804CF04A65C1FC64CC4CAD802E066046C02",
"name": "Nat Welch", "name": "Nat Welch",
"email": "nat.welch@firstlook.org" "email": "nat.welch@firstlook.org"
} }
] ]
} }
3.2. Signature 3.2. Signature
The signature file MUST be an ASCII-armored 'detached signature' of The signature file MUST be an ASCII-armored 'detached signature' of
the keylist file, as defined in OpenPGP Message Format [RFC4880] . the keylist file, as defined in OpenPGP Message Format [RFC4880] .
3.3. Well-Known URL 3.3. Well-Known URL
Keylists SHOULD NOT be well-known resources [RFC4880]. To subscribe Keylists SHOULD NOT be well-known resources [RFC4880]. To subscribe
to a keylist, the client must be aware not only of the keylist's to a keylist, the client must be aware not only of the keylist's
location, but also of the fingerprint of the authority public key location, but also of the fingerprint of the authority public key
used to sign the keylist. Furthermore, because keylists can used to sign the keylist. Furthermore, because keylists can
reference public keys from several different domains, the host of the reference public keys from several different domains, the expected
well-known location for a keylist may not always be clear. host of the well-known location for a keylist may not always be self-
evident.
4. Implementation Status 4. Implementation Status
GPG Sync, an open source program created by one of the authors, GPG Sync, an open source program created by one of the authors,
implements this experimental standard. GPG Sync is used by First implements this experimental standard. GPG Sync is used by First
Look Media and the Freedom of the Press Foundation to keep OpenPGP Look Media and the Freedom of the Press Foundation to keep OpenPGP
keys in sync across their organizations, as well as to publish their keys in sync across their organizations, as well as to publish their
employee's OpenPGP keys to the world. These organizations employee's OpenPGP keys to the world. These organizations
collectively employ more than 200 people and have used the system collectively employ more than 200 people and have used the system
described in this document successfully for multiple years. described in this document successfully for multiple years.
 End of changes. 19 change blocks. 
43 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/