One document matched: draft-wouters-dane-openpgp-00.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-00"
    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="July" year="2013"/>

<abstract>

<t>
OpenPGP is a message format for email (and file) encryption, that lacks
a standarized secure 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 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 different 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 name or email address and anyone
can add signatures to any other public key using forged malicious
identities. For example, bogus keys of prominent dissidents have been uploaded to
these well-known key servers in attempts to capture encrypted email.  Furthermore, once uploaded, public keys
cannot be deleted. People who did not pre-sign a key revocation and who
have lost access to their private key 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_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.
</t>

<section anchor="openpgpkey_loc" title="Location of the OpenPGPKEY record">
<t>Domain names are prepared for requests in the following manner.
<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 "@" character 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 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 "d1qmeq0._openpgpkey.example.com" in the
request.  The corresponding RR in the example.com zone might look like:

<figure><artwork><![CDATA[
d1qmeq0._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.
</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 base32 as specified in <xref target='RFC4648'/>.
</t>
</section>

</section> <!-- end of Resource Record -->

<section title='OpenPGP public key considerations'>
<t>
Once an OPENPGPKEY resource record has been found and the OpenPGP public keyring
has been base32 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 (d1qmeq0._openpgpkey.example.com) yields
a CNAME to d1qmeq0._openpgpkey.example.net, and an OPENPGPKEY RR for
d1qmeq0._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 interact with the user to make a decision
before continuing. The MUA can only accept or refuse a message. The
MTA must deliver the message, either as-is, or encrypted.
Each of these programs should ensure that an unencrypted received
email message will be encrypted whenever possible.
</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>
The same does not apply to OpenPGP encrypted messages. Users have an
expectation that their OpenPGP encrypted messages cannot be decrypted for
years or decades into the future. Changing to a new OpenPGP keypair is
also a costly and manual process that people tend to avoid when possible.
</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>
Therefore, 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 SHOULD NOT modify
the user's OpenPGP keyring.
</t>
<t>
An MTA sending an email SHOULD 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>
[What is the correct behaviour of an MTA when it receives an encrypted
message from a MUA that is encrypted to a different key then the one
listed in the recipient's OPENPGPKEY record? Encrypt the encrypted
message? Refuse to send out the message? Don't even look up the OPENPGPKEY
record and pass unmodified?]
</t>
<t>
If an OPENPGPKEY resource record is received without DNSSEC protection,
it MUST NOT be used. If the DNS request returned an "indeterminate"
or "bogus" answer, the MTA should queue the plaintext message and try
encryption and delivery again at a later time. 
</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 public keyring
differs from the recipient's OPENPGPKEY resource record, the MUA SHOULD NOT accept the
message for delivery. 
</t>
<t>
If a MUA detects that a locally stored public key is present in an
OPENPGPKEY resource record, and the OPENPGPKEY RR version of the public
key is revoked, the MUA SHOULD reject the message for delivery.
</t>
<t>
If multiple non-revoked OPENPGPKEY resource records are found, the MUA
should pick the most secure RR based on its local policy.
</t>
</section>

<section title='Email client behaviour'>
<t>
An email client MAY interact with a user to add the contents from an
OPENPGPKEY resource record into the user's permanent public keyring.
</t>
<t>
If the public key for a recipient obtained from the locally stored
public keyring differs from the recipient's OPENPGPKEY resource record,
the email client SHOULD ask the user which key to use for encryption. The
email cilent SHOULD allow encrypting to both public keys.
</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 manually
verified public key and encrypting to an automatically obtained public key
via an OPENPGPKEY resource record that has not been manually verified.
</t>
<t>
If a MUA detects that a locally stored and manually verified public key is
present in an OPENPGPKEY resource record, and the OPENPGPKEY RR version
of the public key is revoked, the MUA SHOULD warn the user and give them
the chance to not sent the message at all.
</t>
<t>
If multiple non-revoked OPENPGPKEY resource records are found, the MUA
should pick the most secure RR based on its local policy.
</t>
</section>

<section title='Subject: line encryption'>
<t>
Often, encrypting an email does not cause its Subject: line to be
encrypted. If the email client, MUA or MTA automatically encrypt an email
based on the existence of an OPENPGPKEY record, it should clear or replace
the Subject: header with a notification that does not expose the original
subject line. It should prepend the original Subject: line to the first
line of the body of the email message before encryption. This allows a
receiving email client to decrypt the message and replace the Subject:
line to its original decrypted form when presenting the user with the
decrypted email message.
</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='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>