< draft-bhjl-x509-srv-00.txt		draft-bhjl-x509-srv-01.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: September 1, 2016 Taughannock Networks		Expires: January 20, 2017 Taughannock Networks
	February 29, 2016		July 19, 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-00.txt		draft-bhjl-x509-srv-01
	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 September 1, 2016.		This Internet-Draft will expire on January 20, 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 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Name Matching . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4		5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 4		6. Certificate use and cacheing . . . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	9. Normative References . . . . . . . . . . . . . . . . . . . . 5		8.1. Certificates service . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		8.2. Smimeca service . . . . . . . . . . . . . . . . . . . . . 6
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
			10. Normative References . . . . . . . . . . . . . . . . . . . . 6
			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 Internet Public Key Infrastructure (PKI) provides the necessary		The X.509-based Public Key Infrastructure (PKI) [RFC5280] provides
	services to allow for the retrieval of certificates and certificate		the necessary services to allow for the retrieval of certificates and
	revocation lists, but lacks the discovery mechanism needed to		certificate revocation lists, but lacks the discovery mechanism
	associate e-mail domains with specific PKI servers.		needed to associate e-mail domains with specific PKI servers.
	This document specifies an approach that uses a Domain Name System		This document specifies an approach that uses a Domain Name System
	(DNS) Service Record (SRV) that allows mail service providers to		(DNS) Service Record (SRV) that allows mail service providers to
	advertise the X.509 certificate store [RFC4387] that contains		advertise the X.509 or PGP certificate store [RFC4387] that contains
	certificates and certificate revocation lists for their e-mail users.		certificates and certificate revocation lists for their e-mail users.
	Additionally, this document specifies the appropriate query strings		Additionally, this document specifies the appropriate query strings
	to use when accessing the certificate store.		to use when accessing the certificate store.
	The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"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
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 13 ¶
	_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 will construct an SRV record with the appropriate
	parameters, as described in [RFC4387], section 3.2. An example of		parameters, as described in [RFC4387], section 3.2. An example of
	such an SRV record is:		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 MUST be signed via		needs of the service provider. The DNS SRV record SHOULD be signed
	DNSSEC [RFC4033][RFC4034]. The server MUST be an https server and		via DNSSEC [RFC4033][RFC4034]. The server MUST be an https server
	will typically use port 443. The certificate of the https server		and will typically use port 443. The certificate of the https server
	MUST 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 someuser@example.com, the		record above to look up a certificate for bob@example.com, the URI
	URI would be:		would be:
	https://certs.example.com/certificates/search.cgi?uri=someuser%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 MAY support
	other attributes.		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 someuser@example.com, the		record above to look up a certificate for bob@example.com, the URI
	URI would be:		would be:
	https://certs.example.com/pgpkeys/search.cgi?email=someuser%40example.com		https://certs.example.com/pgpkeys/search.cgi?email=bob%40example.com
	PGP certificate stores MUST support the email attribute MAY support		PGP certificate stores MUST support the email attribute and MAY
	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 RFC.
	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.
	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 MUST be encoded as multipart/		certificates are returned, the response is encoded as multipart/
	mixed.		mixed.
	X509 S/MIME certificates have are validated by checking for a		X509 S/MIME certificates are validated by checking for a signature by
	signature by a Certificate Authority (CA) that is acceptable to the		a Certificate Authority (CA) that is acceptable to the validating
	validating party. This specification defines an additional		party. This specification defines an additional validation
	validation technique. The domain MAY publish validation certificates		technique. The domain MAY publish validation certificates using TLSA
	using TLSA records at the name _smime._tcp. The TLSA records MUST		records at the name _smimeca._tcp. The TLSA records MUST have PKIX-
	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 MUST apply a local policy
	to decide whether to use a S/MIME certificate validated only by a		to 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 may
	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 MUST apply 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. Security Considerations		6. Certificate use and cacheing
			Clients SHOULD cache responses to queries as advised by http cache
			headers. This includes both returned certificates, and 404 failures
			saying that an address (or other search key) has no certificate.
			S/MIME keys retrieved from the certificate store SHOULD NOT be used
			for validation of signatures on incoming mail without further
			validation of the certificate. S/MIME signed mail includes a copy of
			the signing certificate which, if it can be validated, typically
			should be used instead.
			7. Security Considerations
	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 the relationship between a domain and its mailbox users is in
	general unknown to correspondents, it would be imprudent to assume		general unknown to correspondents, it would be imprudent to assume
	that such certificates are in fact ones issued to or used by mailbox		that 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
	mail users is beyond the scope of this document.		mail users is beyond the scope of this document.
	7. IANA Considerations		8. IANA Considerations
	[Note to IANA, to be removed prior to publication.]		[Note to IANA, to be removed prior to publication.]
	IANA is requested to add one entry to the Service Name and Transport		IANA is requested to add two entries to the Service Name and
	Protocol Port Number Registry. The service name is "smime"", with no		Transport Protocol Port Number Registry.
	associated port numbers. (more here)
	8. Acknowledgements		8.1. Certificates service
	9. Normative References		Service Name: certificates
			Transport Protocol(s): tcp
			Assignee: IESG
			Contact: <chair@ietf.org>
			Description: Server for S/MIME and PGP certificates
			Reference: [this document]
			Port Number: none
			Service Code: none
			Known Unauthorized Uses: none
			8.2. Smimeca service
			Service Name: simeca
			Transport Protocol(s): tcp
			Assignee: IESG
			Contact: <chair@ietf.org>
			Description: Authority certificate for S/MIME certificates
			Reference: [this document]
			Port Number: none
			Service Code: none
			Known Unauthorized Uses: none
			9. Acknowledgements
			We thank Wei Chuang, Nicolas Lidzborski, and Andreas Schulze for
			comments and suggestions.
			10. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	DOI 10.17487/RFC2782, February 2000,		DOI 10.17487/RFC2782, February 2000,
	<http://www.rfc-editor.org/info/rfc2782>.		<http://www.rfc-editor.org/info/rfc2782>.
	skipping to change at page 6, line 5 ¶		skipping to change at page 7, line 15 ¶
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<http://www.rfc-editor.org/info/rfc4034>.		<http://www.rfc-editor.org/info/rfc4034>.
	[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key		[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key
	Infrastructure Operational Protocols: Certificate Store		Infrastructure Operational Protocols: Certificate Store
	Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February		Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February
	2006, <http://www.rfc-editor.org/info/rfc4387>.		2006, <http://www.rfc-editor.org/info/rfc4387>.
			[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
			<http://www.rfc-editor.org/info/rfc5280>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<http://www.rfc-editor.org/info/rfc5321>.		<http://www.rfc-editor.org/info/rfc5321>.
	[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify		[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
	Conversations about DNS-Based Authentication of Named		Conversations about DNS-Based Authentication of Named
	Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April		Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April
	2014, <http://www.rfc-editor.org/info/rfc7218>.		2014, <http://www.rfc-editor.org/info/rfc7218>.
	Authors' Addresses		Authors' Addresses
End of changes. 21 change blocks.
	41 lines changed or deleted		103 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/