One document matched: draft-wouters-dane-openpgp-01.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 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">

<!--ENTITY I-D.draft-shaw-openpgp-hkp-00 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shaw-openpgp-hkp-00.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-wouters-dane-openpgp-01"
    category="std"
>

<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="2013"/>

<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>

<middle>

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

<t>
To encrypt a message to a target recipient using OpenPGP <xref target='RFC4880'/>, possession of
the recipient's OpenPGP public key is required. To obtain that public
key, two problems need to be solved by the sender's email client, MUA
or MTA. Where does one find the recipient's public key and how does
one trust that the found key actually belongs to the intended recipient.
</t>
<t>
Obtaining a public key is not a straightforward process as there are
no trusted standarized locations for publishing OpenPGP public keys indexed
by email address. Instead, OpenPGP clients rely on "well-known key servers"
that are accessed using the web based HKP protocol or manually by users
using a variety of differently formatted front-end web pages.
</t>
<t>
Currently deployed key servers have no method of validating any uploaded
OpenPGP public key. The key servers simply store and publish. 
Anyone can add public keys with any identities and anyone can add
signatures to any other public key using forged malicious identities.
Furthermore, once uploaded, public keys cannot be deleted. People who did
not pre-sign a key revocation can never remove their public key from these
key servers.
</t>

<t>
The lack of association of email address and public key lookup is
also preventing email clients, MTAs and MUAs from encrypting a received
message to the target receipient forcing the software to send the message
unencryped. Currently deployed MTA's only support encrypting the transport
of the email, not the email contents itself.
</t>
<t>
This document describes a mechanism to associate a user's OpenPGP public
key with their email address, using a new DNS RRtype. This is similar
to the SSHFP <xref target='RFC4255'/> RRType, except that this method
associates keys with users, not hosts.
</t>
<t>
The proposed new DNS Resource Record type is secured using DNSSEC. This
trust model is not meant to replace the "web of trust" model. However,
it can be used to encrypt a message that would otherwise have to be
sent out unencrypted, where it could be intercepted by a third party
in transit or located in plaintext on a storage or email server.
</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 favours
   receiving encrypted email instead of 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 anchor="openpgpkey_rr" title="The OPENPGPKEY Resource Record">
<t>
The OPENPGPKEY DNS resource record (RR) is used to associate an end entity
OpenPGP public key with an email address, thus forming a "OpenPGP public
key association".
</t>

<t>
The type value allocated for the OPENPGPKEY RR type is [TBD].  The OPENPGPKEY RR
is class independent.  The OPENPGPKEY RR has no special TTL requirements. If an
an OPENPGPKEY RR contains an expired OpenPGP public key, it MUST NOT be used
for encryption.
</t>

<section anchor="openpgpkey_loc" title="Location of the OpenPGPKEY record">
<t>Email addresses are mapped into DNS using the following method:
<list style="numbers">

<t>
The user name (the "left-hand side" of the email address,
called the "local-part" in the mail message format definition <xref target="RFC2822"/>
and the "local part" in the specification for internationalized email <xref target="RFC6530"/>), is
encoded with Base32 <xref target="RFC4648"/>, to become
the left-most label in the prepared domain name. This does not include
the at symbol ("@") that separates the left and right sides of the
email address but does include any trailing equal signs ("=") of base64 padding.
</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 2822) 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 address
is "hugh@example.com", you would use "nb2wo2a=._openpgpkey.example.com" in the
request. The corresponding RR in the example.com zone might look like:

<figure><artwork><![CDATA[
nb2wo2a=._openpgpkey.example.com. IN OPENPGPKEY <encoded public key>
]]></artwork></figure>
</t>

<t>
Design note: Encoding the user name with Base32 allows local parts that
have characters that would prevent their use in domain names. For example,
a period (".") is a valid character in a local part, but would wreak
havoc in a domain name. Similarly, RFC 6530 allows non-ASCII characters
in local parts, and encoding a local part with non-ASCII characters with
Base32 renders the name usable in the DNS. The equal sign ("=") is a valid
character for a DNS label, even though it is not a valid character for a DNS
hostname.
</t>
</section>

<section anchor="openpgpkey_rrdata" title="The OPENPGPKEY RDATA Format">
<t>
The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single
value consisting of a <xref target='RFC4880'/> formatted OpenPGP public
keyring encoded in base64 as specified in <xref target='RFC4648'/>. This is
not equivalent to an "ascii armor export" which adds a header,
a footer, and sometimes additional items, to the exported data.
</t>
</section>
</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 base32
encoding 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 (b2wo2a=._openpgpkey.example.com) yields
a CNAME to b2wo2a=._openpgpkey.example.net, and an OPENPGPKEY RR for
b2wo2a=._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='Public Key size and DNS record size'>
<t>
Although the reliability of the transport of large DNS Resoruce Records
has improved in the last few 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 the OpenPGP
keypair should not be modified to accomodate this section.
</t>
<t>
[Should a statement be made on the number of signatures left on the
key? Should there be _any_ signatures other than the self-signed one?]
</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.
</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 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>

<section title='IANA Considerations'>
<section anchor="ianarrtype" title='OPENPGPKEY RRtype'>
<t>
This document uses a new DNS RR type, OPENPGPKEY, whose value [TBD] 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='Generating OPENPGPKEY RRdata'>
<t>The commonly available GnuPG software can be used to generate the RRdata portion of
an OPENPGPKEY record:

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

gpg --export --export-options export-minimal \
    your@email.com | base64

]]></artwork></figure>

The --armor or -a option should NOT be used. While it also provides a base64 encoded copy
of the binary openpgk key data, it adds a header and footer to the output.
</t>
</section>


<section title='Acknowledgements'>
<t>
This document is based on RFC-4255 and draft-ietf-dane-smime whose authors
are Paul Hoffman, Jacob Schlyter and W. Griffin.
</t>
</section>

</middle>

<back>

<references title="Normative References">

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

</references>

<references title="Informative References">

<!-- &I-D.draft-shaw-openpgp-hkp-00; -->
&rfc2181;
&rfc2822;
&rfc4255;
&rfc6530;
&rfc6672;
&rfc6698;

</references>

</back>

</rfc>