One document matched: draft-ietf-dane-openpgpkey-09.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY rfc5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY rfc3597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml">

<!ENTITY rfc4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">

<!ENTITY rfc4398 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml">

<!ENTITY rfc4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">

<!ENTITY rfc4880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.xml">

<!ENTITY rfc5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">

<!ENTITY rfc5754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml">

<!ENTITY rfc6530 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6530.xml">
<!ENTITY rfc6672 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6672.xml">
<!ENTITY rfc6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY rfc6982 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict='yes'?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc ipr="trust200902"
    docName="draft-ietf-dane-openpgpkey-09"
    category="exp"
>

<front>
<title abbrev="DANE for OpenPGP public keys">
Using DANE to Associate OpenPGP public keys with email addresses
</title>

<author initials='P.' surname="Wouters" fullname='Paul Wouters'>
<organization>Red Hat</organization>
<address>
<email>pwouters@redhat.com</email>
</address>
</author>

<date month="April" year="2016"/>

<abstract>
<t>
OpenPGP is a message format for email (and file) encryption that lacks
a standardized lookup mechanism to securely obtain OpenPGP public
keys. DNS-Based Authentication of Named Entities ("DANE") is a method
for publishing public keys in DNS. This document specifies a DANE method
for publishing and locating OpenPGP public keys in DNS for a specific
email address using a new OPENPGPKEY DNS Resource Record. Security
is provided via Secure DNS, however the OPENPGPKEY record is not a
replacement for verification of authenticity via the "Web Of Trust"
or manual verification. The OPENPGPKEY record can be used to encrypt an
email that would otherwise have to be sent unencrypted.
</t>
</abstract>
</front>

<middle>

<section anchor="introduction" title="Introduction">

<t>
OpenPGP <xref target='RFC4880'/> public keys are used to encrypt or sign
email messages and files. To encrypt an email message, or verify a sender's
OpenPGP signature, the email client (MUA) or the email server (MTA) needs to
locate the recipient's OpenPGP public key.
</t>
<t>
OpenPGP clients have relied on centralized "well-known" key servers that
are accessed using the HTTP Keyserver Protocol <xref target='HKP'/>.
Alternatively, users need to manually browse a variety of different
front-end websites.  These key servers do not require a confirmation of
the email address used  in the User ID of the uploaded OpenPGP public
key. Attackers can - and have - uploaded rogue public keys with other
people's email addresses to these key servers.
</t>
<t>
Once uploaded, public keys cannot be deleted. People who did not pre-sign
a key revocation can never remove their OpenPGP public key from these key
servers once they have lost access to their private key. This results in
receiving encrypted email that cannot be decrypted.
</t>
<t>
Therefore, these keyservers are not well suited to support MUAs and
MTA's to automatically encrypt email - especially in the absence of an
interactive user.
</t>
<t>
This document describes a mechanism to associate a user's OpenPGP public
key with their email address, using the OPENPGPKEY DNS RRtype. These
records are published in the DNS zone of the user's email address.
If the user loses their private key, the OPENPGPKEY DNS record can simply
be updated or removed from the zone.
</t>
<t>
The OPENPGPKEY data is secured using Secure DNS <xref target='RFC4035'/>
</t>
<t>
The main goal of the OPENPGPKEY resource record is to stop passive attacks
against plaintext emails.  While it can also thwart some active attacks
(such as people uploading rogue keys to keyservers in the hopes that
others will encrypt to these rogue keys), this resource record is not
a replacement for verifying OpenPGP public keys via the web of trust
signatures, or manually via a fingerprint verification.
</t>

<section anchor="experiment" title="Experiment goal">
<t>
This specification is one experiment in improving access to public keys
for end-to-end email security. There are a range of ways in which this
can reasonably be done, for OpenPGP or S/MIME, for example using the DNS,
or SMTP, or HTTP.  Proposals for each of these have been made with various
levels of support in terms of implementation and deployment.  For each
such experiment, specifications such as this will enable experiments to
be carried out that may succeed or that may uncover technical or other
impediments to large- or small-scale deployments. The IETF encourages
those implementing and deploying such experiments to publicly document
their experiences so that future specifications in this space can benefit.
</t>

<t>
This document defines an RRtype whose use is Experimental. The goal of
the experiment is to see whether encrypted email usage will increase if
an automated discovery method is available to MTA's and MUA's to help
the enduser with email encryption key management.
</t>
<t>
It is unclear if this RRtype will scale to some of the larger email
service deployments. Concerns have been raised about the size of the
OPENPGPKEY record and the size of the resulting DNS zone files. This
experiment hopefully will give the working group some insight into
whether this is a problem or not.
</t>

<t>
If the experiment is successful, it is expected that the findings of
the experiment will result in an updated document for standards track
approval.
</t>
<t>
The OPENPGPKEY RRtype somewhat resembles the generic CERT record defined in
<xref target="RFC4398"/>. However, the CERT record uses sub-typing
with many different types of keys and certificates. It is suspected
that its general application of very different protocols (PKIX versus OpenPGP)
has been the cause for lack of implementation and deployment. Furthermore,
the CERT record uses sub-typing, which is now considered to be a bad idea
for DNS.
</t>
</section>

<section anchor="terminology" title="Terminology">
<t>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 <xref target='RFC2119'/>.</t>

<t>This document also makes use of standard DNSSEC and DANE
terminology. See DNSSEC <xref target='RFC4033'/>,
<xref target='RFC4034'/>, <xref target='RFC4035'/>, and DANE <xref
target='RFC6698'/> for these terms.</t>
</section>
</section>

<section anchor="openpgpkey_rr" title="The OPENPGPKEY Resource Record">
<t>
The OPENPGPKEY DNS resource record (RR) is used to associate an end entity
OpenPGP Transferable Public Key (see Section 11.1 of <xref target='RFC4880'/>
with an email address, thus forming a "OpenPGP public key association". A user
that wishes to specify more than one OpenPGP key, for example because they are
transitioning to a newer stronger key, can do so by adding multiple OPENPGPKEY
records. A single OPENPGPKEY DNS record MUST only contain one OpenPGP key.
</t>

<t>
The type value allocated for the OPENPGPKEY RR type is 61. The
OPENPGPKEY RR is class independent.
</t>

<section anchor="openpgpkey_rrdata" title="The OPENPGPKEY RDATA component">
<t>
The RDATA portion of an OPENPGPKEY Resource Record contains a single
value consisting of a <xref target='RFC4880'/> formatted Transferable Public Key.
</t>
<section anchor="openpgpkey_rrdata_content" title="The OPENPGPKEY RDATA content">
<t>
An OpenPGP Transferable Public Key can be arbitrarily large. DNS records
are limited in size. When creating OPENPGPKEY DNS records, the OpenPGP
Transferable Public Key should be filtered to only contain appropriate
and useful data. At a minimum, an OPENPGPKEY Transferable Public Key
for the user hugh@example.com should contain:

<figure><artwork><![CDATA[
        o The primary key X
          o One User ID Y, which SHOULD match 'hugh@example.com'
            o self-signature from X, binding X to Y
]]></artwork></figure>

If the primary key is not encryption-capable, a relevant subkey should
be included resulting in an OPENPGPKEY Transferable Public Key containing:

<figure><artwork><![CDATA[
        o The primary key X
          o One User ID Y, which SHOULD match 'hugh@example.com'
            o self-signature from X, binding X to Y
          o encryption-capable subkey Z
            o self-signature from X, binding Z to X
          o [ other subkeys if relevant ... ]
]]></artwork></figure>

The user can also elect to add a few third-party certifications which they
believe would be helpful for validation in the traditional Web Of Trust. The
resulting OPENPGPKEY Transferable Public Key would then look like:

<figure><artwork><![CDATA[
        o The primary key X
          o One User ID Y, which SHOULD match 'hugh@example.com'
            o self-signature from X, binding X to Y
            o third-party certification from V, binding Y to X
            o [ other third-party certifications if relevant ... ]
          o encryption-capable subkey Z
            o self-signature from X, binding Z to X
          o [ other subkeys if relevant ... ]
]]></artwork></figure>
</t>
</section>
<section anchor="openpgpkey_rrdata_filter" title="Reducing the Transferable Public Key size">
<t>
When preparing a Transferable Public Key for a specific OPENPGPKEY RDATA format
with the goal of minimizing certificate size, a user would typically want to:
    <list style="symbols">
    <t>
     Where one User ID from the certifications matches the looked-up address,
     strip away non-matching User IDs and any associated certifications
     (self-signatures or third-party certifications).
    </t>
    <t>
     Strip away all User Attribute packets and associated certifications.
    </t>
    <t>
     Strip away all expired subkeys. The user may want to keep revoked subkeys
     if these were revoked prior to their preferred expiration time to ensure
     that correspondents know about these earlier than expected revocations.
    </t>
    <t>
     Strip away all but the most recent self-signature for the remaining user IDs and subkeys.
    </t>
    <t>
    Optionally strip away any uninteresting or unimportant third-party
    User ID certifications.  This is a value judgment by the user that
    is difficult to automate.  At the very least, expired and superseded
    third-party certifcations should be stripped out. The user should attempt
    to keep the most recent and most well connected certifications in the
    Web Of Trust in their Transferable Public Key.
    </t>
    </list>
</t>
</section>
</section>

<section anchor="openpgpkey_wformat" title="The OPENPGPKEY RDATA wire format">
<t>
The RDATA Wire Format consists of a single OpenPGP Transferable Public Key
as defined in Section 11.1 of <xref target="RFC4880"/>. Note that this format is
without ASCII armor or base64 encoding.
</t>
</section>

<section anchor="openpgpkey_pformat" title="The OPENPGPKEY RDATA presentation format">
<t>
The RDATA Presentation Format, as visible in master files <xref target="RFC1035"/>,
consists of a single OpenPGP Transferable Public Key as defined in Section 11.1 of
<xref target='RFC4880'/> encoded in base64 as defined in Section 4 of
<xref target="RFC4648"/>.
</t>
</section>
</section>

<section anchor="openpgpkey_loc" title="Location of the OPENPGPKEY record">
<t>
The DNS does not allow the use of all characters that are supported in the
"local-part" of email addresses as defined in <xref target="RFC5322"/>
and <xref target="RFC6530"/>. Therefore, email addresses are mapped into
DNS using the following method:
<list style="symbols">

<t>
The user name (the "left-hand side" of the email address, called
the "local-part" in the mail message format definition <xref
target="RFC5322"/> and the local-part in the specification for
internationalized email <xref target="RFC6530"/>) is encoded in UTF-8
(or its subset ASCII). If the local-part is written in another encoding
it MUST be converted to UTF-8.
</t>

<t>
The local-part is hashed using the SHA2-256 <xref target="RFC5754"/> algorithm,
with the hash truncated to 28 octets and represented in its hexadecimal
representation, to become the left-most label in the prepared domain
name.
</t>

<t>
The string "_openpgpkey" becomes the second left-most label in the
prepared domain name.
</t>

<t>
The domain name (the "right-hand side" of the email address, called the
"domain" in <xref target="RFC5322"/>) is appended to the result of step
2 to complete the prepared domain name.
</t>
</list></t>

<t>
For example, to request an OPENPGPKEY resource record for a user whose email address
is "hugh@example.com", an OPENPGPKEY query would be placed for the following QNAME:
"c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c1afd6._openpgpkey.example.com".
The corresponding RR in the example.com zone might look like (key shortened for
formatting):

<figure><artwork><![CDATA[
c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>
]]></artwork></figure>
</t>
</section>

<section title='Email address variants and internationalization considerations'>
<t>
Mail systems usually handle variant forms of local-parts. The most
common variants are upper and lower case, often automatically
corrected when a name is recognized as such.  Other variants include
systems that ignore "noise" characters such as dots, so that local
parts johnsmith and John.Smith would be equivalent. Many systems
allow "extensions" such as john-ext or mary+ext where john or mary is
treated as the effective local-part, and the ext is passed to the
recipient for further handling. This can complicate finding the
OPENPGPKEY record associated with the dynamically created email address.
</t>
<t>
<xref target="RFC5321"/> and its predecessors have always made it clear
that only the recipient MTA is allowed to interpret the local-part of
an address. MUA's and MTA's supporting OPENPGPKEY therefore MUST NOT
perform any kind of mapping rules based on the email address.
</t>
<t>
<xref target="openpgpkey_loc"/> above defines how the local-part is
used to determine the location in which one looks for an OPENPGPKEY
record. Given the variety of local-parts seen in email, designing a good
experiment for this is difficult as: a) some current implementations
are known to lowercase at least US-ASCII local-parts, b) we know from
(many) other situations that any strategy based on guessing and making
multiple DNS queries is not going to achieve consensus for good reasons,
and c) the underlying issues are just hard - see Section 10.1 of
<xref target="RFC6530"/> for discussion of just some of the issues that
would need to be tackled to fully address this problem.
</t>
<t>
However, while this specification is not the place to try to address these
issues with local-parts, doing so is also not required to determine the
outcome of this experiment.  If this experiment succeeds then further
work on email addresses with non-ASCII local-parts will be needed and
that would be better based on the findings from this experiment, rather
than doing nothing or starting this experiment based on a speculative
approach to what is a very complex topic.
</t>
</section>

<section title='Application use of OPENPGPKEY '>
<t>
The OPENPGPKEY record allows an application or service to obtain an
OpenPGP public key and use it for verifying a digital signature or
encrypting a message to the public key. The DNS answer MUST pass
DNSSEC validation; if DNSSEC validation reaches any state other than
"Secure" (as specified in <xref target='RFC4035'/>), the DNSSEC validation MUST be
treated as a failure.
</t>
<section title='Obtaining an OpenPGP key for a specific email address'>
<t>
If no OpenPGP public keys are known for an email address, an OPENPGPKEY
DNS lookup MAY be performed to seek the OpenPGP public key that corresponds
to that email address. This public key can then be used to verify
a received signed message or can be used to send out an encrypted email
message. An application whose attempt fails to retrieve a DNSSEC verified
OPENPGPKEY RR from the DNS should remember that failure for some time
to avoid sending out a DNS request for each email message the
application is sending out; such DNS requests constitute a privacy
leak

</t>
</section>
<section title='Confirming that an OpenPGP key is current'>
<t>
Locally stored OpenPGP public keys are not automatically
refreshed.  If the owner of that key creates a new OpenPGP
public key, that owner is unable to securely notify all
users and applications that have its old OpenPGP public
key.  Applications and users can perform an OPENPGPKEY
lookup to confirm the locally stored OpenPGP public key is
still the correct key to use.  If the locally stored
OpenPGP public key is different from the DNSSEC validated
OpenPGP public key currently published in DNS, the
confirmation MUST be treated as a failure unless the
locally stored OpenPGP key signed the newly published
OpenPGP public key found in DNS.  An application that can
interact with the user MAY ask the user for guidance,
otherwise the application will have to apply local policy.
For privacy reasons, an application MUST NOT attempt to
lookup an OpenPGP key from DNSSEC at every use of that key.
</t>
</section>
<section title='Public Key UIDs and query names'>
<t>
An OpenPGP public key can be associated with multiple email addresses
by specifying multiple key uids.  The OpenPGP public key obtained
from a OPENPGPKEY RR can be used as long as the query and resulting data
form a proper email to uid identity association.
</t>
<t>
CNAME's (see <xref target='RFC2181'/>) and DNAME's (see <xref
target='RFC6672'/>) can be followed to obtain an OPENPGPKEY RR,
as long as the original recipient's email address appears as one
of the OpenPGP public key uids. For example, if the OPENPGPKEY RR
query for hugh@example.com (8d57[...]b7._openpgpkey.example.com) yields
a CNAME to 8d57[...]b7._openpgpkey.example.net, and an OPENPGPKEY RR for
8d57[...]b7._openpgpkey.example.net exists, then this OpenPGP public key can
be used, provided one of the key uids contains "hugh@example.com". This
public key cannot be used if it would only contain the key uid
"hugh@example.net".
</t>
<t>
If one of the OpenPGP key uids contains only a single wildcard as the
LHS of the email address, such as "*@example.com", the OpenPGP public
key may be used for any email address within that domain. Wildcards at
other locations (eg hugh@*.com) or regular expressions in key uids are not
allowed, and any OPENPGPKEY RR containing these MUST be ignored.
</t>
</section>
</section>

<section title='OpenPGP Key size and DNS'>
<t>
Due to the expected size of the OPENPGPKEY record, applications SHOULD
use TCP - not UDP - to perform queries for the OPENPGPKEY Resource Record.
</t>

<t>
Although the reliability of the transport of large DNS Resource Records
has improved in the last years, it is still recommended to keep the DNS
records as small as possible without sacrificing the security properties
of the public key. The algorithm type and key size of OpenPGP keys should
not be modified to accommodate this section.
</t>

<t>
OpenPGP supports various attributes that do not contribute to the
security of a key, such as an embedded image file. It is recommended
that these properties not be exported to OpenPGP public keyrings that
are used to create OPENPGPKEY Resource Records. Some OpenPGP software,
for example GnuPG, support a "minimal key export" that is well
suited to use as OPENPGPKEY RDATA. See <xref target='AppendixA'/>.
</t>
</section>

<section anchor="security" title='Security Considerations'>
<t>
DNSSEC is not an alternative for the "web of trust" or for manual
fingerprint verification by users. DANE for OpenPGP as specified in this
document is a solution aimed to ease obtaining someone's public key.
Without manual verification of the OpenPGP key obtained via DANE, this
retrieved key should only be used for encryption if the only other alternative
is sending the message in plaintext.  While this thwarts all passive
attacks that simply capture and log all plaintext email content, it is
not a security measure against active attacks. A user who publishes an
OPENPGPKEY record in DNS still expects senders to perform their due
diligence by additional (non-DNSSEC) verification of their public key via
other out-of-band methods before sending any confidential or sensitive
information.
</t>
<t>
In other words, the OPENPGPKEY record MUST NOT be used to send sensitive
information without additional verification or confirmation that the
OpenPGP key actually belongs to the target recipient.
</t>

<t>
Various components could be responsible for encrypting an email message to
a target recipient.  It could be done by the sender's MUA or a MUA plugin
or the sender's MTA. Each of these have their own characteristics. A
MUA can ask the user to make a decision before continuing. The MUA can
either accept or refuse a message. The MTA must deliver the message as-is,
or encrypt the message before delivering. Each of these components should
attempt to encrypt an unencrypted outgoing message whenever possible.
</t>

<t>
In theory, two different local-parts could hash to the same value. This
document assumes that such a hash collision has a negliable chance of happening.
</t>

<t>
Organisations that are required to be able to read everyone's encrypted email
should publish the escrow key as the OPENPGPKEY record. Mail servers of such
organizations MAY optionally re-encrypt the message to the individual's
OpenPGP key.
</t>

<section title='MTA behaviour'>
<t>
An MTA could be operating in a stand-alone mode, without access to the
sender's OpenPGP public keyring, or in a way where it can access the
user's OpenPGP public keyring. Regardless, the MTA MUST NOT modify the
user's OpenPGP keyring.
</t>
<t>
An MTA sending an email MUST NOT add the public key obtained from an
OPENPGPKEY resource record to a permanent public keyring for future
use beyond the TTL.
</t>
<t>
If the obtained public key is revoked, the MTA MUST NOT use the key for
encryption, even if that would result in sending the message in plaintext.
</t>
<t>
If a message is already encrypted, the MTA SHOULD NOT re-encrypt the
message, even if different encryption schemes or different encryption
keys would be used.
</t>
<t>
If the DNS request for an OPENPGPKEY record returned an Indeterminate or
Bogus answer as specified in <xref target='RFC4035'/>, the MTA MUST NOT
send the message and queue the plaintext message for encrypted delivery
at a later time. If the problem persists, the email should be returned
via the regular bounce methods.
</t>
<t>
If multiple non-revoked OPENPGPKEY resource records are found, the MTA
SHOULD pick the most secure RR based on its local policy.
</t>
</section>

<section title='MUA behaviour'>
<t>
If the public key for a recipient obtained from the locally stored
sender's public keyring differs from the recipient's OPENPGPKEY RR,
the MUA SHOULD halt processing the message and interact with the user
to resolve the conflict before continuing to process the message.
</t>
<t>
If the public key for a recipient obtained from the locally stored
sender's public keyring contains contradicting properties for the same
key obtained from an OPENPGPKEY RR, the MUA SHOULD NOT accept the message
for delivery.
</t>
<t>
If multiple non-revoked OPENPGPKEY resource records are found, the MUA
SHOULD pick the most secure OpenPGP public key based on its local policy.
</t>

<t>
The MUA MAY interact with the user to resolve any conflicts between
locally stored keyrings and OPENPGPKEY RRdata.
</t>

<t>
A MUA that is encrypting a message SHOULD clearly indicate to the user
the difference between encrypting to a locally stored and previously
user-verified public key and encrypting to public key obtained via an
OPENPGPKEY resource record that was not manually verified by the user
in the past.
</t>
</section>

<section title='Response size'>
<t>
To prevent amplification attacks, an Authoritative DNS server MAY wish to
prevent returning OPENPGPKEY records over UDP unless the source IP address
has been confirmed with <xref target="EDNS-COOKIE"/>. Such servers MUST
NOT return REFUSED, but answer the query with an empty Answer Section
and the truncation flag set ("TC=1").
</t>
</section>

<section title='Email address information leak'>
<t>
The hashing of the local-part in this document is not a security feature.
Publishing OPENPGPKEY records however, will create a list of hashes of
valid email addresses, which could simplify obtaining a list of valid
email addresses for a particular domain. It is desirable to not ease
the harvesting of email addresses where possible.
</t>
<t>
The domain name part of the email address is not used as part of the
hash so that hashes can be used in multiple zones deployed using DNAME
<xref target="RFC6672"/>. This does makes it slightly easier and cheaper
to brute-force the SHA2-256 hashes into common and short user names, as
single rainbow tables can be re-used across domains. This can be somewhat
countered by using NSEC3.
</t>
<t>
DNS zones that are signed with DNSSEC using NSEC for denial of existence
are susceptible to zone-walking, a mechanism that allows someone to
enumerate all the OPENPGPKEY hashes in a zone. This can be used in
combination with previously hashed common or short user names (in
rainbow tables) to deduce valid email addresses. DNSSEC-signed zones
using NSEC3 for denial of existence instead of NSEC are significantly
harder to brute-force after performing a zone-walk.
</t>
</section>

<section title='Storage of OPENPGPKEY data'>
<t>
Users may have a local key store with OpenPGP public keys. An application
supporting the use of OPENPGPKEY DNS records MUST NOT modify the local
key store without explicit confirmation of the user, as the application
is unaware of the user's personal policy for adding, removing or updating
their local key store. An application MAY warn the user if an OPENPGPKEY
record does not match the OpenPGP public key in the local key store.
</t>
<t>
Applications that cannot interact with users, such as daemon
processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY
up to their DNS TTL value. This avoids repeated DNS lookups that third
parties could monitor to determine when an email is being sent to a
particular user.
</t>
</section>

<section title='Security of OpenPGP versus DNSSEC'>
<t>
Anyone who can obtain a DNSSEC private key of a domain name via coercion,
theft or brute force calculations, can replace any OPENPGPKEY record
in that zone and all of the delegated child zones. Any future messages
encrypted with the malicious OpenPGP key could then be read.
</t>
<t>
Therefore, an OpenPGP key obtained via a DNSSEC validated OPENPGPKEY record
can only be trusted as much as the DNS domain can be trusted, and is no
substitute for in-person OpenPGP key verification or additional Openpgp
verification via "Web Of Trust" signatures present on the OpenPGP in question.
</t>
</section>
</section>

<section title="Implementation Status">
<t>[RFC Editor Note: Please remove this entire seciton prior to publication
   as an RFC.]
</t>
<t>
   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in <xref target='RFC6982'/>.
   The description of implementations in this section is
   intended to assist the IETF in its decision processes in progressing
   drafts to RFCs.  Please note that the listing of any individual
   implementation here does not imply endorsement by the IETF.
   Furthermore, no effort has been spent to verify the information
   presented here that was supplied by IETF contributors.  This is not
   intended as, and must not be construed to be, a catalog of available
   implementations or their features.  Readers are advised to note that
   other implementations may exist.

   According to RFC 6982, "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit."
</t>
           <section title="The GNU Privacy Guard (GNUpg)">
            <t>
            <list style="hanging">
               <t hangText="Implementation Name and Details:">
               The GNUpg software, more commonly known as "gpg", is is available at https://gnupg.org/
               </t>

               <t hangText="Brief Description:">Support has been added to
               gnupg in their git repository. This code is expected to be part of the next official release.
               </t>

               <t hangText="Level of Maturity:">The implementation has just been added and has not seen
               widespread deployment.
               </t>

               <t hangText="Coverage:">The implementation follows the latest draft with the exception that it
               first performs a lowercase of the local-part before hashing. This is done because other parts
               in the code that perform a lookup of uid already performed a localcasing to ensure case insensitivity.
               The implementors are tracking the development of this draft in particular with respect to the lowercase issue.
               </t>
               <t hangText="Licensing:">All code is covered under the GNU Public License version 3 or later.</t>
               <t hangText="Implementation Experience:">Currrent experience limited to small test networks only</t>
               <t hangText="Contact Information:">https://gnupg.org/</t>
               <t hangText="Interoperability:">No report.</t>
           </list>
            </t>
            </section>
           <section title="hash-slinger">
            <t>
            <list style="hanging">
               <t hangText="Implementation Name and Details:">
               The hash-slinger software is a collection of tools to generate, download and verify application public
               keys and application fingerprints. It uses DNSSEC validation. The tool is written by the author of
               this document. It is available at http://people.redhat.com/pwouters/
               </t>

               <t hangText="Brief Description:">Support has been added
               in the form of an "openpgpkey" command that can generate,
               fetch, validate the DNSSEC authentication and verify
               OPENPGPKEY records.
               </t>

               <t hangText="Level of Maturity:">The implementation has been around for a few months but has not seen widespread
               deployment.
               </t>

               <t hangText="Coverage:">The implementation follows the latest draft with the exception that it
               first performs a lowercase of the local-part before hashing.
               </t>
               <t hangText="Licensing:">All code is covered under the GNU Public License version 3 or later.</t>
               <t hangText="Implementation Experience:">Currrent experience limited to small test networks only</t>
               <t hangText="Contact Information:">pwouters@redhat.com</t>
               <t hangText="Interoperability:">No report.</t>
           </list>
            </t>
            </section>
           <section title="openpgpkey-milter">
            <t>
            <list style="hanging">
               <t hangText="Implementation Name and Details:">
               The openpgpkey-milter is a Postfix and Sendmail Mail server plugin (milter) that automatically encrypts
               email before sending further to other SMTP servers. It is written by the author of this document. It is
               available at http://github.com/letoams/openpgpkey-milter/
               </t>

               <t hangText="Brief Description:">Before forwarding an unencrypted email, the plugin looks for the presence
               of an OPENPGPKEY record. When available, it will encrypt the email message and send out the encrypted email.
               </t>

               <t hangText="Level of Maturity:">The implementation has been around for a few months but has not seen widespread
               deployment.
               </t>

               <t hangText="Coverage:">The implementation follows the latest draft with the exception that it
               first performs a lowercase of the local-part before hashing.
               </t>
               <t hangText="Licensing:">All code is covered under the GNU Public License version 3 or later.</t>
               <t hangText="Implementation Experience:">Currrent experience limited to small test networks only</t>
               <t hangText="Contact Information:">pwouters@redhat.com</t>
               <t hangText="Interoperability:">No report.</t>
           </list>
            </t>
            </section>
</section>


<section title='IANA Considerations'>
<section anchor="ianarrtype" title='OPENPGPKEY RRtype'>
<t>
This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has
been allocated by IANA from the Resource Record (RR) TYPEs subregistry
of the Domain Name System (DNS) Parameters registry.
</t>
</section>
</section>


<section title='Acknowledgments'>
<t>
This document is based on RFC-4255 and draft-ietf-dane-smime whose authors
are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur Gudmundsson
provided feedback and suggested various improvements. Willem Toorop
contributed the gpg and hexdump command options. Daniel Kahn Gillmor
provided the text describing the OpenPGP packet formats and filtering
options. Edwin Taylor contributed language improvements for various
iterations of this document. Text regarding email mappings was taken
from draft-levine-dns-mailbox whose author is John Levine.
</t>
</section>

</middle>

<back>

<references title="Normative References">

&rfc1035;
&rfc2119;
&rfc2181;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc4648;
&rfc4880;
&rfc5754;

</references>

<references title="Informative References">

&rfc4398;
&rfc5322;
&rfc3597;
&rfc5321;
&rfc6530;
&rfc6672;
&rfc6698;
&rfc6982;

   <reference anchor='HKP'>
      <front>
      <title>The OpenPGP HTTP Keyserver Protocol (HKP)</title>
      <author initials='D' surname='Shaw' fullname='D. Shaw'>
      <organization>Huawei</organization>
      </author>
      <date month='March' year='2013' />
      <abstract><t>
       This document specifies a series of conventions to implement an
       OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP).  As
       this document is a codification and extension of a protocol that is
       already in wide use, strict attention is paid to backward
       compatibility with these existing implementations.
       </t></abstract>
      </front>
      <seriesInfo name='Internet-Draft' value='draft-shaw-openpgp-hkp' />
      <format type='TXT'
            target='https://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt' />
            <!-- cannot use link on www.ietf.org/id/ because draft expired -->
   </reference>

   <reference anchor='EDNS-COOKIE'>
      <front>
      <title>Domain Name System (DNS) Cookies</title>
      <author initials='Donald' surname='Eastlake' fullname='Donald Eastlake'>
      <organization>Huawei</organization>
      </author>
      <date month='August' day='1' year='2015' />
      <abstract><t>
       DNS cookies are a lightweight DNS transaction security mechanism that
       provides limited protection to DNS servers and clients against a
       variety of increasingly common denial-of-service and amplification /
       forgery or cache poisoning attacks by off-path attackers. DNS Cookies
       are tolerant of NAT, NAT-PT, and anycast and can be incrementally
       deployed.
       </t></abstract>
      </front>
      <seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-cookies' />
      <format type='TXT'
            target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-cookies-10.txt' />
   </reference>

</references>

    <section title="Generating OPENPGPKEY records" anchor="AppendixA">
    <t>The commonly available GnuPG software can be used to generate a minimum
       Transferable Public Key for the RRdata portion of an OPENPGPKEY record:

<figure><artwork align="left"><![CDATA[

gpg --export --export-options export-minimal,no-export-attributes \
    hugh@example.com | base64

]]></artwork></figure>

The --armor or -a option of the gpg command should NOT be used, as it
adds additional markers around the armored key.
</t>

<t>When DNS software reading or signing the zone file does not yet
support the OPENPGPKEY RRtype, the Generic Record Syntax of
<xref target='RFC3597'/> can be used to generate the RDATA. One needs to
calculate the number of octets and the actual data in hexadecimal:

<figure><artwork align="left"><![CDATA[

gpg --export --export-options export-minimal,no-export-attributes \
    hugh@example.com | wc -c

gpg --export --export-options export-minimal,no-export-attributes \
    hugh@example.com | hexdump -e \
       '"\t" /1 "%.2x"' -e '/32 "\n"'

]]></artwork></figure>

These values can then be used to generate a generic record (line break
has been added for formatting):

<figure><artwork align="left"><![CDATA[

<SHA2-256-trunc(hugh)>._openpgpkey.example.com. IN TYPE61 \# \
    <numOctets> <keydata in hex>

]]></artwork></figure>

</t>

<t>The openpgpkey command in the hash-slinger software can be used to
generate complete OPENPGPKEY records

<figure><artwork align="left"><![CDATA[

~> openpgpkey --output rfc hugh@example.com
c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]

~> openpgpkey --output generic hugh@example.com
c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...]

]]></artwork></figure>

</t>
</section>


</back>

</rfc>