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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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-06"
    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="October" year="2015"/>

<abstract>
<t>
OpenPGP is a message format for email (and file) encryption that lacks
a standardized lookup mechanism to securely obtain OpenPGP public
keys. This document specifies a 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
send 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 or 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 either 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 validate the email address 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>
Therefor, these keyservers are not well suited to support email clients
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.
</t>
<t>
The main goal of the OPENPGPKEY resource record is to stop passive attacks
against plaintext emails.  While it can also twart 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 document defines an Experimental RRtype. 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 generality 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. The OPENPGPKEY RR has no special
TTL requirements.
</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 then expected revocations.
    </t>
    <t>
     Strip away all but the most recent self-sig 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 textual zone files, 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"/>) should already be
encoded in UTF-8 (or its subset ASCII). If it is written in another
encoding it should be converted to UTF-8 and then 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. Truncation comes from the right-most
octets. This does not include the at symbol ("@") that separates the
left and right sides of the email address.
</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 RFC 5322) 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'>
<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. A client supporting OPENPGPKEY therefor MUST NOT perform any
kind of mapping rules based on the email address.
</t>
</section>

<section title='Application use of OPENPGPKEY '>
<t>
The OPENPGPKEY record allows an application or service to obtain or verify
an OpenPGP public key. The lookup result MUST pass DNSSEC validation;
if validation reaches any state other than "Secure", the verification
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
lookup MAY be performed to discover the OpenPGP public key that belongs
to a specific 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 that confirms the lack of an OPENPGPKEY record
SHOULD remember this for some time to avoid sending out a DNS request
for each email message that is sent out as this constitutes a privacy leak.
</t>
</section>
<section title='Confirming the validity of an OpenPGP key'>
<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 verifying a locally stored OpenPGP public key and the OpenPGP
public key found through DNS is different from the locally stored OpenPGP
public key, the verification MUST be treated as a failure. An application
that can interact with the user MAY ask the user for guidance. For privacy
reasons, an application MUST NOT attempt to validate a locally stored OpenPGP
key using an OPENPGPKEY lookup 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 should 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 are not exported to OpenPGP public keyrings that
are used to create OPENPGPKEY Resource Records. Some OpenPGP software,
for example GnuPG, have support for 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 humans. It is a solution aimed to ease
obtaining someone's public key, and without manual verification should be
treated as "better then plaintext" only. While this twarts 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 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
email client or software plugin, the sender's Mail User Agent (MUA)
or the sender's Mail Transfer Agent (MTA). Each of these have their
own characteristics. An email client can direct the human 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 programs should attempt to encrypt an
unencrypted received message whenever possible.
</t>

<t>
Organisations that are required to be able to read everyone's encrypted email
should publish the escrow key as the OPENPGPKEY record. Upon receipt, such
mail servers 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, the MTA MUST NOT sent 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 MUST NOT accept the message for delivery.
</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>
</section>

<section title='Email client behaviour'>
<t>
Email clients should adhere to the above listed MUA
behaviour. Additionally, an email client MAY interact with the user to
resolve any conflicts between locally stored keyrings and OPENPGPKEY
RRdata.
</t>
<t>
An email client that is encrypting a message SHOULD clearly indicate to
the user the difference between encrypting to a locally stored and humanly
verified public key and encrypting to an unverified (by the human sender)
public key obtained via an OPENPGPKEY resource record.
</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 verified 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 user name 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 an OPENPGPKEY record can only be
trusted as much as the DNS domain can be trusted, and is no substitute
for in-person key verification or verification via the "Web of Trust".
</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 and verify application DNS records 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 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">

&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-05.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>