< draft-bhjl-x509-srv-01.txt   draft-bhjl-x509-srv-02.txt >
Network Working Group B. Haberman Network Working Group B. Haberman
Internet-Draft JHU APL Internet-Draft JHU APL
Intended status: Standards Track J. Levine Intended status: Standards Track J. Levine
Expires: January 20, 2017 Taughannock Networks Expires: January 23, 2017 Taughannock Networks
July 19, 2016 July 22, 2016
Using a DNS SRV Record to Locate an X.509 Certificate Store Using a DNS SRV Record to Locate an X.509 Certificate Store
draft-bhjl-x509-srv-01 draft-bhjl-x509-srv-02
Abstract Abstract
This document describes a method to allow parties to locate X.509 This document describes a method to allow parties to locate X.509
certificate stores with Domain Name System Service records in order certificate stores with Domain Name System Service records in order
to retrieve certificates and certificate revocation lists. The to retrieve certificates and certificate revocation lists. The
primary purpose of such retrievals is to facilitate the association primary purpose of such retrievals is to facilitate the association
of X.509 and PGP public keys with e-mail addresses to allow for of X.509 and PGP public keys with e-mail addresses to allow for
encrypted e-mail exchanges. encrypted e-mail exchanges.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 20, 2017. This Internet-Draft will expire on January 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 6 skipping to change at page 3, line 6
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Service Record Format 2. Service Record Format
The general format of a DNS SRV record is documented in [RFC2782] as: The general format of a DNS SRV record is documented in [RFC2782] as:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target _Service._Proto.Name TTL Class SRV Priority Weight Port Target
To support the advertisement of an X.509 certificate store, service To support the advertisement of an X.509 certificate store, service
providers will construct an SRV record with the appropriate providers publish an SRV record for the certificates service with the
parameters, as described in [RFC4387], section 3.2. An example of appropriate parameters, as described in [RFC4387], section 3.2. An
such an SRV record is: example of such an SRV record is:
_certificates._tcp 86400 IN SRV 0 0 443 certs.example.com _certificates._tcp 86400 IN SRV 0 0 443 certs.example.com
The parameters of the DNS SRV record are set based on the operational The parameters of the DNS SRV record are set based on the operational
needs of the service provider. The DNS SRV record SHOULD be signed needs of the service provider. The DNS SRV record SHOULD be signed
via DNSSEC [RFC4033][RFC4034]. The server MUST be an https server via DNSSEC [RFC4033][RFC4034]. The server MUST be an https server
and will typically use port 443. The certificate of the https server and will typically use port 443. The certificate of the https server
SHOULD be validated by a DNSSEC signed TLSA record, and MAY also be SHOULD be validated by a DNSSEC signed TLSA record, and MAY also be
validated by a certificate authority. validated by a certificate authority.
3. Certificate Store Queries 3. Certificate Store Queries
To retrieve an X.509 S/MIME certificate, the attribute type is "uri", To retrieve an X.509 S/MIME certificate, the attribute type is "uri",
and the URI is constructed using the path described in [RFC4387], and the URI is constructed using the path described in [RFC4387],
Section 3.3, specifically "/certificates/search.cgi". Using the SRV Section 3.3, specifically "/certificates/search.cgi". Using the SRV
record above to look up a certificate for bob@example.com, the URI record above to look up a certificate for bob@example.com, the URI
would be: would be:
https://certs.example.com/certificates/search.cgi?uri=bob%40example.com https://certs.example.com/certificates/search.cgi?uri=bob%40example.com
X.509 certificate stores MUST support the uri attribute MAY support X.509 certificate stores MUST support the uri attribute and MAY
other attributes. support other attributes.
To retrieve a PGP certificate, the attribute type is "email", and the To retrieve a PGP certificate, the attribute type is "email", and the
URI is constructed using the path described in [RFC4387], URI is constructed using the path described in [RFC4387],
Section 3.3, specifically "/pgpkeys/search.cgi". Using the SRV Section 3.3, specifically "/pgpkeys/search.cgi". Using the SRV
record above to look up a certificate for bob@example.com, the URI record above to look up a certificate for bob@example.com, the URI
would be: would be:
https://certs.example.com/pgpkeys/search.cgi?email=bob%40example.com https://certs.example.com/pgpkeys/search.cgi?email=bob%40example.com
PGP certificate stores MUST support the email attribute and MAY PGP certificate stores MUST support the email attribute and MAY
support other attributes. support other attributes.
4. Name Matching 4. Name Matching
SMTP [RFC5321] specifies that the local part of a mailbox is SMTP [RFC5321] specifies that the local part of a mailbox is
interpreted only by the mailbox domain itself. This document does interpreted only by the mailbox domain itself. This document does
not update or modify that RFC. not update or modify that document.
If a certificate store has no certificate with an e-mail address that If a certificate store has no certificate with an e-mail address that
matches the uri or email attribute in a retrieval request, but it matches the uri or email attribute in a retrieval request, but it
does have a certificate with an e-mail address that the mailbox does have a certificate with an e-mail address that the mailbox
domain treats similarly to the requested address, the server MAY domain treats similarly to the requested address, the server MAY
return that certificate. The definition of what is sufficiently return that certificate. The definition of what is sufficiently
similar is a matter of local policy, but the intention is that a similar is a matter of local policy, but the intention is that a
human correspondent would consider the same person or entity to human correspondent would consider the same person or entity to
receive mail at the two addresses. receive mail at the two addresses.
skipping to change at page 4, line 34 skipping to change at page 4, line 34
mixed. mixed.
X509 S/MIME certificates are validated by checking for a signature by X509 S/MIME certificates are validated by checking for a signature by
a Certificate Authority (CA) that is acceptable to the validating a Certificate Authority (CA) that is acceptable to the validating
party. This specification defines an additional validation party. This specification defines an additional validation
technique. The domain MAY publish validation certificates using TLSA technique. The domain MAY publish validation certificates using TLSA
records at the name _smimeca._tcp. The TLSA records MUST have PKIX- records at the name _smimeca._tcp. The TLSA records MUST have PKIX-
TA or DANE-TA usage[RFC7218]. TA or DANE-TA usage[RFC7218].
Since the relationship between a domain and its mailbox users is in Since the relationship between a domain and its mailbox users is in
general unknown to correspondents, a client MUST apply a local policy general unknown to correspondents, a client applies a local policy to
to decide whether to use a S/MIME certificate validated only by a decide whether to use a S/MIME certificate validated only by a
signing certificate published by the domain. signing certificate published by the domain.
PGP certificates are validated by the PGP web of trust. A domain may PGP certificates are validated by the PGP web of trust. A domain can
endorse the certificates it publishes by signing them with a endorse the certificates it publishes by signing them with a
signature of postmaster@<domain>. Since the relationship between a signature of postmaster@<domain>. Since the relationship between a
domain and its mailbox users is in general unknown to correspondents. domain and its mailbox users is in general unknown to correspondents.
a client MUST apply a local policy to decide whether to use a PGP a client applies a local policy to decide whether to use a PGP
certificate retrieved from a certificate server. This policy would certificate retrieved from a certificate server. This policy would
typically be the same one used to decide whether to use a certificate typically be the same one used to decide whether to use a certificate
retrieved from a traditional PGP key server. retrieved from a traditional PGP key server.
6. Certificate use and cacheing 6. Certificate use and cacheing
Clients SHOULD cache responses to queries as advised by http cache Clients SHOULD cache responses to queries as advised by http cache
headers. This includes both returned certificates, and 404 failures headers. This includes both returned certificates, and 404 failures
saying that an address (or other search key) has no certificate. saying that an address (or other search key) has no certificate.
S/MIME keys retrieved from the certificate store SHOULD NOT be used S/MIME keys retrieved from the certificate store SHOULD NOT be used
for validation of signatures on incoming mail without further for validation of signatures on incoming mail without further
validation of the certificate. S/MIME signed mail includes a copy of validation of the certificate. S/MIME signed mail includes a copy of
the signing certificate which, if it can be validated, typically the signing certificate which, if it can be validated, typically
should be used instead. would be used instead.
7. Security Considerations 7. Security Considerations
Certificate queries could be used to try to validate lists of e-mail
addresses. This is essentially the same problem that mail servers
face with RCPT TO probes, and the same countermeasures would apply,
such as rate limiting, blacklisting abusive clients, and returning
fake results for non-existent addresses.
DNSSEC signatures on the SRV record and the https server certificate DNSSEC signatures on the SRV record and the https server certificate
ensure that any keys retrieved by the technique described in this ensure that any keys retrieved by the technique described in this
document are the ones published by the domain's management. But document are the ones published by the domain's management. But
since the relationship between a domain and its mailbox users is in since correspondents often do not know the relationship between a
general unknown to correspondents, it would be imprudent to assume domain and its mailbox users, it would be imprudent to assume that
that such certificates are in fact ones issued to or used by mailbox such certificates are in fact ones issued to or used by mailbox
recipients or to assume that mail encrypted using the certificates recipients or to assume that mail encrypted using the certificates
will be readable only by the intended recipient. will be readable only by the intended recipient.
A domain could publish man-in-the-middle certificates that allowed it A domain could publish man-in-the-middle certificates that allowed it
to decode and read mail, and perhaps re-encrypt it using different to decode and read mail, and perhaps re-encrypt it using different
certificates used by the recipients. In some cases this would be certificates used by the recipients. In some cases this would be
entirely legitimate, e.g., a financial institution that is required entirely legitimate, e.g., a financial institution that is required
to log all of its employees's correspondence. In other cases, it to log all of its employees's correspondence. In other cases, it
could be improper surveillance of the contents of users' mail. could be improper surveillance of the contents of users' mail.
Identifying or describing the relationship between a domain and its Identifying or describing the relationship between a domain and its
 End of changes. 12 change blocks. 
18 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/