<?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 rfc2822 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.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 rfc4255 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4255.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 rfc5891 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.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">

]>

<?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-usage-01"
    category="std"
>

<front>
<title abbrev="BCP for OPENPGPKEY">Best Common Practise for using OPENPGPKEY records</title>

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

<date month="October" day="27" year="2014"/>

<abstract>

<t>
The OPENPGPKEY DNS Resource Record can be used to match an email address
to an OpenPGP key.  This document specifies a Best Common Practise ("BCP") for
email clients, MUA's and MTA's for using the OPENPGPKEY DNS Resource Record.
</t>

</abstract>

</front>

<middle>

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

<t>
This document describes a Best Current Practise ("BCP") for using
OPENPGPKEY DNS Resource Records xref target="OPENPGPKEY"/
in email clients, MUA's and MTA.
</t>

<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_ind" title="The OPENPGPKEY record presence">
<t>A user who publishes an OPENPGPKEY record in DNS explicitly prefers
   receiving encrypted email over receiving unencrypted email.</t>
<t>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 in DNS, without any additional
   verification, should be used only as an alternative to sending plaintext
   email. It SHOULD NOT be used to change one's opinion on whether it is
   safe or appropriate to sent the content via email in the first place.</t>
</section>

<section title='OpenPGP public key considerations'>
<t>
Once an OPENPGPKEY resource record has been found and the OpenPGP public keyring
has been decoded, the right public key must be located inside the keyring. For
a public key in the keyring to be usable, the public key has to have a key uid
as specified in <xref target='RFC4648'/> that matches the email address for which
the OPENPGPKEY RR lookup was performed.
</t>

<section title='Public Key UIDs and email addresses'>
<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 target recipient's email
address appears as one of the OpenPGP public key uids. The name part
(left of the @) should appear in the native format, not its SHA2-224
hash that was used to lookup the OPENPGPKEY RR.
</t>
</section>

<section title='Public Key UIDs and IDNA'>
<t>
Internationalized domains that use non-ascii characters (U-label) are
encoded in DNS using IDNA <xref target='RFC5891'/> - also referred to
as punycode or A-label. When matching OpenPGP public key uids, both the
email address specified using U-label and A-label should be considered as
valid public key uids.
</t>
</section>

<section title='Public Key UIDs and synthesized DNS records'>
<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 title='OpenPGP Key size and DNS'>
<t>
Although the reliability of the transport of large DNS Resoruce 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 accomodate 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.
</t>
</section>
</section>

<section anchor="security" title='Security Considerations'>
<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>

<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 ensure that the security of
an email message is never downgraded, and that an unencrypted received
message will be encrypted whenever possible.
</t>

<t>
Organisations that require to be able to read everyone's encrypted email should
publish the escrow key as the OPENPGPKEY record. Upon receipt, such mail servers
can optionally re-encrypt the message to the individual's OpenPGP key.
</t>

<section title='Email address information leak'>
<t>
DNS zones that are signed with DNSSEC using NSEC for denial of
existence are susceptible to zone-walking, a mechanism that allow
someone to enumerate all the names in the zone. Someone who wanted
to collect email addresses from a zone that uses OPENPGPKEY might use such
a mechanism. DNSSEC-signed zones using NSEC3 for denial of existence
are significantly less susceptible to zone-walking. Someone could still
attempt a dictionary attack on the zone to find OPENPGPKEY records, just
as they can use dictionary attacks on an SMTP server or grab the entire
contents of existing PGP key servers to see which addresses are valid.
</t>
</section>

<section title='OpenPGP security and DNSSEC'>
<t>
DNSSEC key sizes are chosen based on the fact that these keys can be
rolled with next to no requirement for security in the future. If one
doubts the strength or security of the DNSSEC key for whatever reason,
one simply rolls to a new DNSSEC key with a stronger algorithm or larger
key size.
</t>
<t>
This effectively means that 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,
irrespective of the key length strength of the OpenPGP keypair.
</t>
<t>
Therefor, 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.
</t>
</section>

<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 were used.
</t>
<t>
If an OPENPGPKEY resource record is received without DNSSEC protection,
it MAY still be used for encryption.
</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 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.
[or should it encrypt to both?]
</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>

</middle>

<back>

<references title="Normative References">

&rfc2119;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc4648;
&rfc4880;
&rfc5891;

   <reference anchor='OPENPGPKEY'> 
      <front> 
      <title>DANE for OpenPGP public keys</title>
      <author initials='P' surname='Wouters' fullname='P. Wouters'> 
      <organization>Red Hat</organization>
      </author> 
      <date month='October' day='27' year='2014' /> 
      <abstract><t>
      OpenPGP is a message format for email (and file) encryption, that lacks a
      standarized lookup mechanism to obtain OpenPGP public keys. This document
      specifies a standarized method for securely publishing and locating
      OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record.
       </t></abstract> 
      </front> 
      <seriesInfo name='Internet-Draft' value='draft-ietf-dane-openpgp' /> 
      <format type='TXT' 
            target='http://www.ietf.org/internet-drafts/draft-ietf-dane-openpgp-01.txt' /> 
   </reference> 

</references>

<references title="Informative References">

&rfc2181;
&rfc2822;
&rfc4255;
&rfc6530;
&rfc6672;
&rfc6698;

</references>

</back>

</rfc>

