< draft-bhjl-x509-srv-02.txt   draft-bhjl-x509-srv-03.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 23, 2017 Taughannock Networks Expires: July 20, 2017 Taughannock Networks
July 22, 2016 January 16, 2017
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-02 draft-bhjl-x509-srv-03
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 23, 2017. This Internet-Draft will expire on July 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Service Record Format . . . . . . . . . . . . . . . . . . . . 2 2. Service Record Format . . . . . . . . . . . . . . . . . . . . 2
3. Certificate Store Queries . . . . . . . . . . . . . . . . . . 3 3. Certificate Store Queries . . . . . . . . . . . . . . . . . . 3
4. Name Matching . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Name Matching . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4 5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4
6. Certificate use and cacheing . . . . . . . . . . . . . . . . 4 6. Certificate use and cacheing . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8.1. Certificates service . . . . . . . . . . . . . . . . . . 5 8.1. Certificates service . . . . . . . . . . . . . . . . . . 6
8.2. Smimeca service . . . . . . . . . . . . . . . . . . . . . 6 8.2. Smimeca service . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6 10. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
X.509 and PGP public keys can be used to encrypt or sign e-mail X.509 and PGP public keys can be used to encrypt or sign e-mail
messages. In order to verify a sender's signature or encrypt an messages. In order to verify a sender's signature or encrypt an
e-mail, the e-mail client needs to locate the appropriate public key. e-mail, the e-mail client needs to locate the appropriate public key.
The X.509-based Public Key Infrastructure (PKI) [RFC5280] provides The X.509-based Public Key Infrastructure (PKI) [RFC5280] provides
the necessary services to allow for the retrieval of certificates and the necessary services to allow for the retrieval of certificates and
certificate revocation lists, but lacks the discovery mechanism certificate revocation lists, but lacks the discovery mechanism
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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.
5. Certificate Validation 5. Certificate Validation
The certificate is returned as a blob of binary data. If multiple The certificate is returned as a blob of binary data. If multiple
certificates are returned, the response is encoded as multipart/ certificates are returned, the response is encoded as multipart/mixed
mixed. as described in [RFC4387] section 2.
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]. A validation certificate published by
a domain MUST NOT be used to validate certificates other than those
with e-mail addresses in that domain.
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 applies a local policy to general unknown to correspondents, a client applies a local policy 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 can 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.
skipping to change at page 5, line 15 skipping to change at page 5, line 21
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
would 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 Certificate queries could be used to try to validate lists of e-mail
addresses. This is essentially the same problem that mail servers addresses. This is essentially the same problem that mail servers
face with RCPT TO probes, and the same countermeasures would apply, face with VRFY, EXPN, and RCPT TO probes, and the same
such as rate limiting, blacklisting abusive clients, and returning countermeasures would apply, such as rate limiting, blacklisting
fake results for non-existent addresses. 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 correspondents often do not know the relationship between a since correspondents often do not know the relationship between a
domain and its mailbox users, it would be imprudent to assume that domain and its mailbox users, it would be imprudent to assume 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' correspondence. In other cases, it
could be improper surveillance of the contents of users' mail. could be intrusive or improper surveillance of the contents of users'
Identifying or describing the relationship between a domain and its mail. Identifying or describing the relationship between a domain
mail users is beyond the scope of this document. and its mail users is beyond the scope of this document.
8. IANA Considerations 8. IANA Considerations
[Note to IANA, to be removed prior to publication.] IANA is requested to update two entries in the Service Name and
IANA is requested to add two entries to the Service Name and
Transport Protocol Port Number Registry. Transport Protocol Port Number Registry.
8.1. Certificates service 8.1. Certificates service
Service Name: certificates Service Name: certificates
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG Assignee: IESG
skipping to change at page 6, line 4 skipping to change at page 6, line 14
8.1. Certificates service 8.1. Certificates service
Service Name: certificates Service Name: certificates
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG Assignee: IESG
Contact: <chair@ietf.org> Contact: <chair@ietf.org>
Description: Server for S/MIME and PGP certificates Description: Server for S/MIME and PGP certificates
Reference: [this document] Reference: [this document]
Port Number: none Port Number: none
Service Code: none Service Code: none
Known Unauthorized Uses: none Known Unauthorized Uses: none
8.2. Smimeca service 8.2. Smimeca service
Service Name: simeca Service Name: simeca
Transport Protocol(s): tcp Transport Protocol(s): tcp
Assignee: IESG Assignee: IESG
Contact: <chair@ietf.org> Contact: <chair@ietf.org>
Description: Authority certificate for S/MIME certificates Description: Per-domain authority certificate for S/MIME certificates
Reference: [this document] Reference: [this document]
Port Number: none Port Number: none
Service Code: none Service Code: none
Known Unauthorized Uses: none Known Unauthorized Uses: none
9. Acknowledgements 9. Acknowledgements
 End of changes. 14 change blocks. 
22 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/