OpenPGP fingerprints in the DNS

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 https://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 31 August 2024.¶

Copyright Notice

Copyright (c) 2024 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 (https://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.¶

Table of Contents

1. Introduction

The OpenPGP specification [RFC4880] defines message formats and cryptographic primitives with day-to-day use but does not specify a scheme for verifying the authenticity of a certificate containing an identity claim (i.e. a User ID with an email address of a particular domain). Organizations need a centralized solution for distributing trust data to their employees and as such require a place from which the trusted information flows to the clients. DNS is a natural place used by other similar specifications such as CAA Resource Records [RFC8659] and SSHFP [RFC4255].¶

The method described in this document allows defining trusted OpenPGP certificates through the centralized DNS system. The system is both lightweight, as it uses existing standardized mechanisms and secure, as it depends on DNS security [RFC4033] and OpenPGP certificates.¶

2. Definitions

3. openpgp4fpr URI scheme

The following defines a unified URI format which allows to reference OpenPGP v4 certificates using the openpgp4fpr scheme outlined below.¶

URI format:¶

openpgp4fpr:<fingerprint>

Where fingerprint represents exactly 40 characters of lower and upper-case letters A, B, C, D, E, F and digits (0-9).¶

The same can be formally defined using Augmented Backus-Naur Form:¶

openpgp4fpr-uri = "openpgp4fpr:" fingerprint
fingerprint     = 40*40HEXDIG

Example of an openpgp4fpr URI:¶

openpgp4fpr:653909A2F0E37C106F5FAF546C8857E0D8E8F074

URIs in the openpgp4fpr scheme are used to identify an OpenPGP key by its primary key fingerprint.¶

Applications using this scheme may use the OpenPGP fingerprints to retrieve OpenPGP certificates by implementation-defined methods (e.g. keyserver lookup using the HTTP Keyserver Protocol).¶

As a fingerprint contains only characters in the unreserved set [RFC3986] there is no need to encode the scheme specific part of the URI.¶

4. DNS TXT records for OpenPGP fingerprints

DNS records containing OpenPGP fingerprints are regular DNS TXT records (as specified in [RFC1034]) where the text content of the record is an openpgp4fpr URI defined in the previous section. Since a DNS hostname can contain multiple TXT records, the hostname can also contain multiple openpgp4fpr URIs.¶

5. Implications

This document combines trust anchor provisioning through DNS with OpenPGP's append-only data structures which capture the entire lifecycle of a certificate.¶

6. Security Considerations

It is paramount that the clients use only authenticated DNS responses. As such DNSSEC [RFC4033] usage is REQUIRED. The client MAY use additional logic to filter-out insecure algorithms and MUST properly handle revocation and expiration mechanisms already present in OpenPGP [RFC4880].¶

7. IANA Considerations

Since this specification reuses already specified elements such as the DNS TXT records [RFC1035] and OpenPGP certificates [RFC4880] there are no IANA actions requested at this time.¶

8. Related Work

This specification is similar to other, already existing ways to authenticate SSH hosts, most notably SSHFP records [RFC4255]. The primary difference is that SSHFP relies strictly on DNSSEC for authentication while this specification allows clients to use more sophisticated authentication mechanisms. One of them is the Web of Trust, as used in the OpenPGP CA project.¶

These additional verification procedures can be added together to form an even more secure path from the SSH user to the SSH server as evidenced by the ssh-openpgp-auth project.¶

Appendix A. Acknowledgements

The author wishes to thank and acknowledge all contributions of the following people: David Runge, Yarmo Mackenbach.¶

Author's Address