rfc2538xml.txt		draft-ietf-dnsext-rfc2538bis.txt
1				1
2	Network Working Group S. Josefsson		Network Working Group S. Josefsson	2
3				3
4	Expires: March 5, 2005		Obsoletes: 2538 (if approved)	4
			Expires: September 2, 2006	5
5				6
6	Storing Certificates in the Domain Name System (DNS)		Storing Certificates in the Domain Name System (DNS)	7
7	rfc2538		draft-ietf-dnsext-rfc2538bis-10	8
8				9
9	Status of this Memo		Status of this Memo	10
10				11
11	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any	12
12	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware	13
13	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes	14
14	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.	15
15				16
16	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering	17
17	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that	18
	skipping to change at page 1, line 33		skipping to change at page 1, line 34
22	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any	23
23	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference	24
24	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."	25
25				26
26	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at	27
27	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.	28
28				29
29	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at	30
30	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.	31
31				32
32	This Internet-Draft will expire on March 5, 2005.		This Internet-Draft will expire on September 2, 2006.	33
33				34
34	Copyright Notice		Copyright Notice	35
35				36
36	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2006).	37
37				38
38	Abstract		Abstract	39
39				40
40	Cryptographic public key are frequently published and their		Cryptographic public keys are frequently published, and their	41
41	authenticity demonstrated by certificates. A CERT resource record		authenticity is demonstrated by certificates. A CERT resource record	42
42	(RR) is defined so that such certificates and related certificate		(RR) is defined so that such certificates and related certificate	43
43	revocation lists can be stored in the Domain Name System (DNS).		revocation lists can be stored in the Domain Name System (DNS).	44
44				45
			This document obsoletes RFC 2538.	46
				47
45	Table of Contents		Table of Contents	48
46				49
47	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	50
48	2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3		2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3	51
49	2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4		2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4	52
50	2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5		2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 6	53
51	2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6	54
52	3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6		3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 7	55
53	3.1. X.509 CERT RR Names . . . . . . . . . . . . . . . . . . . 6		3.1. Content-Based X.509 CERT RR Names . . . . . . . . . . . . 8	56
54	3.2. PGP CERT RR Names . . . . . . . . . . . . . . . . . . . . 7		3.2. Purpose-Based X.509 CERT RR Names . . . . . . . . . . . . 9	57
55	4. Performance Considerations . . . . . . . . . . . . . . . . . . 7		3.3. Content-Based OpenPGP CERT RR Names . . . . . . . . . . . 9	58
56	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		3.4. Purpose-Based OpenPGP CERT RR Names . . . . . . . . . . . 10	59
57	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX . . . . . 10	60
58	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Performance Considerations . . . . . . . . . . . . . . . . . . 10	61
59	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11	62
60	Intellectual Property and Copyright Statements . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11	63
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 11	64
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12	65
			9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 13	66
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13	67
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 13	68
			10.2. Informative References . . . . . . . . . . . . . . . . . . 14	69
			Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . 15	70
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16	71
			Intellectual Property and Copyright Statements . . . . . . . . . . 17	72
61				73
62	1. Introduction		1. Introduction	74
63				75
64	Public keys are frequently published in the form of a certificate and		Public keys are frequently published in the form of a certificate,	76
65	their authenticity is commonly demonstrated by certificates and		and their authenticity is commonly demonstrated by certificates and	77
66	related certificate revocation lists (CRLs). A certificate is a		related certificate revocation lists (CRLs). A certificate is a	78
67	binding, through a cryptographic digital signature, of a public key,		binding, through a cryptographic digital signature, of a public key,	79
68	a validity interval and/or conditions, and identity, authorization,		a validity interval and/or conditions, and identity, authorization,	80
69	or other information. A certificate revocation list is a list of		or other information. A certificate revocation list is a list of	81
70	certificates that are revoked, and incidental information, all signed		certificates that are revoked, and of incidental information, all	82
71	by the signer (issuer) of the revoked certificates. Examples are		signed by the signer (issuer) of the revoked certificates. Examples	83
72	X.509 certificates/CRLs in the X.500 directory system or PGP		are X.509 certificates/CRLs in the X.500 directory system or OpenPGP	84
73	certificates/revocations used by PGP software.		certificates/revocations used by OpenPGP software.	85
74				86
75	Section 2 below specifies a CERT resource record (RR) for the storage		Section 2 specifies a CERT resource record (RR) for the storage of	87
76	of certificates in the Domain Name System.		certificates in the Domain Name System [1] [2].	88
77				89
78	Section 3 discusses appropriate owner names for CERT RRs.		Section 3 discusses appropriate owner names for CERT RRs.	90
79				91
80	Sections 4, 5, and 6 below cover performance, IANA, and security		Sections 4, 7, and 8 cover performance, security, and IANA	92
81	considerations, respectively.		considerations, respectively.	93
82				94
			Section 9 explains the changes in this document compared to RFC 2538.	95
				96
83	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	97
84	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	98
85	document are to be interpreted as described in [3].		document are to be interpreted as described in [3].	99
86				100
87	2. The CERT Resource Record		2. The CERT Resource Record	101
88				102
89	The CERT resource record (RR) has the structure given below. Its RR		The CERT resource record (RR) has the structure given below. Its RR	103
90	type code is 37.		type code is 37.	104
91				105
92	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3	106
93	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	107
94	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	108
95	| type | key tag |		| type | key tag |	109
96	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	110
97	| algorithm | /		| algorithm | /	111
98	+---------------+ certificate or CRL /		+---------------+ certificate or CRL /	112
99	/ /		/ /	113
100	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|	114
101				115
102	The type field is the certificate type as define in section 2.1		The type field is the certificate type as defined in Section 2.1	116
103	below.		below.	117
104				118
105	The algorithm field has the same meaning as the algorithm field in		The key tag field is the 16-bit value computed for the key embedded	119
106	KEY and SIG RRs [8] except that a zero algorithm field indicates the		in the certificate, using the RRSIG Key Tag algorithm described in	120
107	algorithm is unknown to a secure DNS, which may simply be the result		Appendix B of [12]. This field is used as an efficiency measure to	121
108	of the algorithm not having been standardized for secure DNS.		pick which CERT RRs may be applicable to a particular key. The key	122
			tag can be calculated for the key in question, and then only CERT RRs	123
			with the same key tag need to be examined. Note that two different	124
			keys can have the same key tag. However, the key MUST be transformed	125
			to the format it would have as the public key portion of a DNSKEY RR	126
			before the key tag is computed. This is only possible if the key is	127
			applicable to an algorithm and complies to limits (such as key size)	128
			defined for DNS security. If it is not, the algorithm field MUST be	129
			zero and the tag field is meaningless and SHOULD be zero.	130
109				131
110	The key tag field is the 16 bit value computed for the key embedded		The algorithm field has the same meaning as the algorithm field in	132
111	in the certificate as specified in the DNSSEC Standard [8]. This		DNSKEY and RRSIG RRs [12], except that a zero algorithm field	133
112	field is used as an efficiency measure to pick which CERT RRs may be		indicates that the algorithm is unknown to a secure DNS, which may	134
113	applicable to a particular key. The key tag can be calculated for		simply be the result of the algorithm not having been standardized	135
114	the key in question and then only CERT RRs with the same key tag need		for DNSSEC [11].	136
115	be examined. However, the key must always be transformed to the
116	format it would have as the public key portion of a KEY RR before the
117	key tag is computed. This is only possible if the key is applicable
118	to an algorithm (and limits such as key size limits) defined for DNS
119	security. If it is not, the algorithm field MUST BE zero and the tag
120	field is meaningless and SHOULD BE zero.
121				137
122	2.1. Certificate Type Values		2.1. Certificate Type Values	138
123				139
124	The following values are defined or reserved:		The following values are defined or reserved:	140
125				141
126	Value Mnemonic Certificate Type		Value Mnemonic Certificate Type	142
127	----- -------- ----------- ----		----- -------- ----------------	143
128	0 reserved		0 Reserved	144
129	1 PKIX X.509 as per PKIX		1 PKIX X.509 as per PKIX	145
130	2 SPKI SPKI cert		2 SPKI SPKI certificate	146
131	3 PGP PGP cert		3 PGP OpenPGP packet	147
132	4-252 available for IANA assignment		4 IPKIX The URL of an X.509 data object	148
			5 ISPKI The URL of an SPKI certificate	149
			6 IPGP The fingerprint and URL of an OpenPGP packet	150
			7 ACPKIX Attribute Certificate	151
			8 IACPKIX The URL of an Attribute Certificate	152
			9-252 Available for IANA assignment	153
133	253 URI URI private		253 URI URI private	154
134	254 OID OID private		254 OID OID private	155
135	255-65534 available for IANA assignment		255 Reserved	156
136	65535 reserved		256-65279 Available for IANA assignment	157
			65280-65534 Experimental	158
			65535 Reserved	159
				160
			These values represent the initial content of the IANA registry; see	161
			Section 8.	162
137				163
138	The PKIX type is reserved to indicate an X.509 certificate conforming		The PKIX type is reserved to indicate an X.509 certificate conforming	164
139	to the profile being defined by the IETF PKIX working group. The		to the profile defined by the IETF PKIX working group [8]. The	165
140	certificate section will start with a one byte unsigned OID length		certificate section will start with a one-octet unsigned OID length	166
141	and then an X.500 OID indicating the nature of the remainder of the		and then an X.500 OID indicating the nature of the remainder of the	167
142	certificate section (see 2.3 below). (NOTE: X.509 certificates do		certificate section (see Section 2.3, below). (NOTE: X.509	168
143	not include their X.500 directory type designating OID as a prefix.)		certificates do not include their X.500 directory-type-designating	169
			OID as a prefix.)	170
144				171
145	The SPKI type is reserved to indicate a certificate formated as to be		The SPKI and ISPKI types are reserved to indicate the SPKI	172
146	specified by the IETF SPKI working group.		certificate format [15], for use when the SPKI documents are moved	173
			from experimental status. The format for these two CERT RR types	174
			will need to be specified later.	175
147				176
148	The PGP type indicates a Pretty Good Privacy certificate as described		The PGP type indicates an OpenPGP packet as described in [5] and its	177
149	in [6] and its extensions and successors.		extensions and successors. This is used to transfer public key	178
			material and revocation signatures. The data is binary and MUST NOT	179
			be encoded into an ASCII armor. An implementation SHOULD process	180
			transferable public keys as described in Section 10.1 of [5], but it	181
			MAY handle additional OpenPGP packets.	182
				183
			The ACPKIX type indicates an Attribute Certificate format [9].	184
				185
			The IPKIX and IACPKIX types indicate a URL that will serve the	186
			content that would have been in the "certificate, CRL, or URL" field	187
			of the corresponding type (PKIX or ACPKIX, respectively).	188
				189
			The IPGP type contains both an OpenPGP fingerprint for the key in	190
			question, as well as a URL. The certificate portion of the IPGP CERT	191
			RR is defined as a one-octet fingerprint length, followed by the	192
			OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is	193
			calculated as defined in RFC 2440 [5]. A zero-length fingerprint or	194
			a zero-length URL are legal, and indicate URL-only IPGP data or	195
			fingerprint-only IPGP data, respectively. A zero-length fingerprint	196
			and a zero-length URL are meaningless and invalid.	197
				198
			The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".	199
			These types MUST be used when the content is too large to fit in the	200
			CERT RR and MAY be used at the implementer's discretion. They SHOULD	201
			NOT be used where the DNS message is 512 octets or smaller and could	202
			thus be expected to fit a UDP packet.	203
150				204
151	The URI private type indicates a certificate format defined by an		The URI private type indicates a certificate format defined by an	205
152	absolute URI. The certificate portion of the CERT RR MUST begin with		absolute URI. The certificate portion of the CERT RR MUST begin with	206
153	a null terminated URI [5] and the data after the null is the private		a NUL-terminated URI [10] and the data after the NUL is the private	207
154	format certificate itself. The URI SHOULD be such that a retrieval		format certificate itself. The URI SHOULD be such that a retrieval	208
155	from it will lead to documentation on the format of the certificate.		from it will lead to documentation on the format of the certificate.	209
156	Recognition of private certificate types need not be based on URI		Recognition of private certificate types need not be based on URI	210
157	equality but can use various forms of pattern matching so that, for		equality but can use various forms of pattern matching so that, for	211
158	example, subtype or version information can also be encoded into the		example, subtype or version information can also be encoded into the	212
159	URI.		URI.	213
160				214
161	The OID private type indicates a private format certificate specified		The OID private type indicates a private format certificate specified	215
162	by a an ISO OID prefix. The certificate section will start with a		by an ISO OID prefix. The certificate section will start with a one-	216
163	one byte unsigned OID length and then a BER encoded OID indicating		octet unsigned OID length and then a BER-encoded OID indicating the	217
164	the nature of the remainder of the certificate section. This can be		nature of the remainder of the certificate section. This can be an	218
165	an X.509 certificate format or some other format. X.509 certificates		X.509 certificate format or some other format. X.509 certificates	219
166	that conform to the IETF PKIX profile SHOULD be indicated by the PKIX		that conform to the IETF PKIX profile SHOULD be indicated by the PKIX	220
167	type, not the OID private type. Recognition of private certificate		type, not the OID private type. Recognition of private certificate	221
168	types need not be based on OID equality but can use various forms of		types need not be based on OID equality but can use various forms of	222
169	pattern matching such as OID prefix.		pattern matching such as OID prefix.	223
170				224
171	2.2. Text Representation of CERT RRs		2.2. Text Representation of CERT RRs	225
172				226
173	The RDATA portion of a CERT RR has the type field as an unsigned		The RDATA portion of a CERT RR has the type field as an unsigned	227
174	integer or as a mnemonic symbol as listed in section 2.1 above.		decimal integer or as a mnemonic symbol as listed in Section 2.1,	228
			above.	229
175				230
176	The key tag field is represented as an unsigned integer.		The key tag field is represented as an unsigned decimal integer.	231
177				232
178	The algorithm field is represented as an unsigned integer or a		The algorithm field is represented as an unsigned decimal integer or	233
179	mnemonic symbol as listed in [8].		a mnemonic symbol as listed in [12].	234
180				235
181	The certificate / CRL portion is represented in base 64 and may be		The certificate/CRL portion is represented in base 64 [16] and may be	236
182	divided up into any number of white space separated substrings, down		divided into any number of white-space-separated substrings, down to	237
183	to single base 64 digits, which are concatenated to obtain the full		single base-64 digits, which are concatenated to obtain the full	238
184	signature. These substrings can span lines using the standard		signature. These substrings can span lines using the standard	239
185	parenthesis.		parenthesis.	240
186				241
187	Note that the certificate / CRL portion may have internal sub-fields		Note that the certificate / CRL portion may have internal sub-fields,	242
188	but these do not appear in the master file representation. For		but these do not appear in the master file representation. For	243
189	example, with type 254, there will be an OID size, an OID, and then		example, with type 254, there will be an OID size, an OID, and then	244
190	the certificate / CRL proper. But only a single logical base 64		the certificate/CRL proper. However, only a single logical base-64	245
191	string will appear in the text representation.		string will appear in the text representation.	246
192				247
193	2.3. X.509 OIDs		2.3. X.509 OIDs	248
194				249
195	OIDs have been defined in connection with the X.500 directory for		OIDs have been defined in connection with the X.500 directory for	250
196	user certificates, certification authority certificates, revocations		user certificates, certification authority certificates, revocations	251
197	of certification authority, and revocations of user certificates.		of certification authority, and revocations of user certificates.	252
198	The following table lists the OIDs, their BER encoding, and their		The following table lists the OIDs, their BER encoding, and their	253
199	length prefixed hex format for use in CERT RRs:		length-prefixed hex format for use in CERT RRs:	254
200				255
201	id-at-userCertificate		id-at-userCertificate	256
202	= { joint-iso-ccitt(2) ds(5) at(4) 36 }		= { joint-iso-ccitt(2) ds(5) at(4) 36 }	257
203	== 0x 03 55 04 24		== 0x 03 55 04 24	258
204	id-at-cACertificate		id-at-cACertificate	259
205	= { joint-iso-ccitt(2) ds(5) at(4) 37 }		= { joint-iso-ccitt(2) ds(5) at(4) 37 }	260
206	== 0x 03 55 04 25		== 0x 03 55 04 25	261
207	id-at-authorityRevocationList		id-at-authorityRevocationList	262
208	= { joint-iso-ccitt(2) ds(5) at(4) 38 }		= { joint-iso-ccitt(2) ds(5) at(4) 38 }	263
209	== 0x 03 55 04 26		== 0x 03 55 04 26	264
	skipping to change at page 6, line 26		skipping to change at page 7, line 26
212	== 0x 03 55 04 27		== 0x 03 55 04 27	267
213				268
214	3. Appropriate Owner Names for CERT RRs		3. Appropriate Owner Names for CERT RRs	269
215				270
216	It is recommended that certificate CERT RRs be stored under a domain		It is recommended that certificate CERT RRs be stored under a domain	271
217	name related to their subject, i.e., the name of the entity intended		name related to their subject, i.e., the name of the entity intended	272
218	to control the private key corresponding to the public key being		to control the private key corresponding to the public key being	273
219	certified. It is recommended that certificate revocation list CERT		certified. It is recommended that certificate revocation list CERT	274
220	RRs be stored under a domain name related to their issuer.		RRs be stored under a domain name related to their issuer.	275
221				276
222	Following some of the guidelines below may result in the use in DNS		Following some of the guidelines below may result in DNS names with	277
223	names of characters that require DNS quoting which is to use a		characters that require DNS quoting as per Section 5.1 of RFC 1035	278
224	backslash followed by the octal representation of the ASCII code for		[2].	279
225	the character such as \000 for NULL.
226				280
227	3.1. X.509 CERT RR Names		The choice of name under which CERT RRs are stored is important to	281
			clients that perform CERT queries. In some situations, the clients	282
			may not know all information about the CERT RR object it wishes to	283
			retrieve. For example, a client may not know the subject name of an	284
			X.509 certificate, or the email address of the owner of an OpenPGP	285
			key. Further, the client might only know the hostname of a service	286
			that uses X.509 certificates or the Key ID of an OpenPGP key.	287
228				288
229	Some X.509 versions permit multiple names to be associated with		Therefore, two owner name guidelines are defined: content-based owner	289
230	subjects and issuers under "Subject Alternate Name" and "Issuer		names and purpose-based owner names. A content-based owner name is	290
231	Alternate Name". For example, x.509v3 has such Alternate Names with		derived from the content of the CERT RR data; for example, the	291
232	an ASN.1 specification as follows:		Subject field in an X.509 certificate or the User ID field in OpenPGP	292
			keys. A purpose-based owner name is a name that a client retrieving	293
			CERT RRs ought to know already; for example, the host name of an	294
			X.509 protected service or the Key ID of an OpenPGP key. The	295
			content-based and purpose-based owner name may be the same; for	296
			example, when a client looks up a key based on the From: address of	297
			an incoming email.	298
				299
			Implementations SHOULD use the purpose-based owner name guidelines	300
			described in this document and MAY use CNAME RRs at content-based	301
			owner names (or other names), pointing to the purpose-based owner	302
			name.	303
				304
			Note that this section describes an application-based mapping from	305
			the name space used in a certificate to the name space used by DNS.	306
			The DNS does not infer any relationship amongst CERT resource records	307
			based on similarities or differences of the DNS owner name(s) of CERT	308
			resource records. For example, if multiple labels are used when	309
			mapping from a CERT identifier to a domain name, then care must be	310
			taken in understanding wildcard record synthesis.	311
				312
			3.1. Content-Based X.509 CERT RR Names	313
				314
			Some X.509 versions, such as the PKIX profile of X.509 [8], permit	315
			multiple names to be associated with subjects and issuers under	316
			"Subject Alternative Name" and "Issuer Alternative Name". For	317
			example, the PKIX profile has such Alternate Names with an ASN.1	318
			specification as follows:	319
233				320
234	GeneralName ::= CHOICE {		GeneralName ::= CHOICE {	321
235	otherName [0] INSTANCE OF OTHER-NAME,		otherName [0] OtherName,	322
236	rfc822Name [1] IA5String,		rfc822Name [1] IA5String,	323
237	dNSName [2] IA5String,		dNSName [2] IA5String,	324
238	x400Address [3] EXPLICIT OR-ADDRESS.&Type,		x400Address [3] ORAddress,	325
239	directoryName [4] EXPLICIT Name,		directoryName [4] Name,	326
240	ediPartyName [5] EDIPartyName,		ediPartyName [5] EDIPartyName,	327
241	uniformResourceIdentifier [6] IA5String,		uniformResourceIdentifier [6] IA5String,	328
242	iPAddress [7] OCTET STRING,		iPAddress [7] OCTET STRING,	329
243	registeredID [8] OBJECT IDENTIFIER		registeredID [8] OBJECT IDENTIFIER }	330
244	}
245				331
246	The recommended locations of CERT storage are as follows, in priority		The recommended locations of CERT storage are as follows, in priority	332
247	order:		order:	333
248
249	1. If a domain name is included in the identification in the		1. If a domain name is included in the identification in the	334
250	certificate or CRL, that should be used.		certificate or CRL, that ought to be used.	335
251	2. If a domain name is not included but an IP address is included,		2. If a domain name is not included but an IP address is included,	336
252	then the translation of that IP address into the appropriate		then the translation of that IP address into the appropriate	337
253	inverse domain name should be used.		inverse domain name ought to be used.	338
254	3. If neither of the above it used but a URI containing a domain		3. If neither of the above is used, but a URI containing a domain	339
255	name is present, that domain name should be used.		name is present, that domain name ought to be used.	340
256	4. If none of the above is included but a character string name is		4. If none of the above is included but a character string name is	341
257	included, then it should be treated as described for PGP names in		included, then it ought to be treated as described below for	342
258	3.2 below.		OpenPGP names.	343
259	5. If none of the above apply, then the distinguished name (DN)		5. If none of the above apply, then the distinguished name (DN)	344
260	should be mapped into a domain name as specified in [4].		ought to be mapped into a domain name as specified in [4].	345
261				346
262	Example 1: Assume that an X.509v3 certificate is issued to /CN=John		Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/	347
263	Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative		DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)	348
264	names of (a) string "John (the Man) Doe", (b) domain name john-		string "John (the Man) Doe", (b) domain name john-doe.com, and (c)	349
265	doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then		URI <https://www.secure.john-doe.com:8080/>. The storage locations	350
266	the storage locations recommended, in priority order, would be		recommended, in priority order, would be	351
267	1. john-doe.com,		1. john-doe.com,	352
268	2. www.secure.john-doe.com, and		2. www.secure.john-doe.com, and	353
269	3. Doe.com.xy.		3. Doe.com.xy.	354
270				355
271	Example 2: Assume that an X.509v3 certificate is issued to /CN=James		Example 2: An X.509v3 certificate is issued to /CN=James Hacker/	356
272	Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names		L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)	357
273	of (a) domain name widget.foo.example, (b) IPv4 address		domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and	358
274	10.251.13.201, and (c) string "James Hacker		(c) string "James Hacker <hacker@mail.widget.foo.example>". The	359
275	<hacker@mail.widget.foo.example>". Then the storage locations		storage locations recommended, in priority order, would be	360
276	recommended, in priority order, would be
277	1. widget.foo.example,		1. widget.foo.example,	361
278	2. 201.13.251.10.in-addr.arpa, and		2. 201.13.251.10.in-addr.arpa, and	362
279	3. hacker.mail.widget.foo.example.		3. hacker.mail.widget.foo.example.	363
280				364
281	3.2. PGP CERT RR Names		3.2. Purpose-Based X.509 CERT RR Names	365
282				366
283	PGP signed keys (certificates) use a general character string User ID		Due to the difficulty for clients that do not already possess a	367
284	[6]. However, it is recommended by PGP that such names include the		certificate to reconstruct the content-based owner name, purpose-	368
285	RFC 822 email address of the party, as in "Leslie Example		based owner names are recommended in this section. Recommendations	369
286	<Leslie@host.example>". If such a format is used, the CERT should be		for purpose-based owner names vary per scenario. The following table	370
287	under the standard translation of the email address into a domain		summarizes the purpose-based X.509 CERT RR owner name guidelines for	371
288	name, which would be leslie.host.example in this case. If no RFC 822		use with S/MIME [17], SSL/TLS [13], and IPsec [14]:	372
289	name can be extracted from the string name no specific domain name is			373
290	recommended.		Scenario Owner name	374
			------------------ ----------------------------------------------	375
			S/MIME Certificate Standard translation of an RFC 2822 email	376
			address. Example: An S/MIME certificate for	377
			"postmaster@example.org" will use a standard	378
			hostname translation of the owner name,	379
			"postmaster.example.org".	380
				381
			TLS Certificate Hostname of the TLS server.	382
				383
			IPsec Certificate Hostname of the IPsec machine and/or, for IPv4	384
			or IPv6 addresses, the fully qualified domain	385
			name in the appropriate reverse domain.	386
				387
			An alternate approach for IPsec is to store raw public keys [18].	388
				389
			3.3. Content-Based OpenPGP CERT RR Names	390
				391
			OpenPGP signed keys (certificates) use a general character string	392
			User ID [5]. However, it is recommended by OpenPGP that such names	393
			include the RFC 2822 [7] email address of the party, as in "Leslie	394
			Example <Leslie@host.example>". If such a format is used, the CERT	395
			ought to be under the standard translation of the email address into	396
			a domain name, which would be leslie.host.example in this case. If	397
			no RFC 2822 name can be extracted from the string name, no specific	398
			domain name is recommended.	399
				400
			If a user has more than one email address, the CNAME type can be used	401
			to reduce the amount of data stored in the DNS. For example:	402
				403
			$ORIGIN example.org.	404
			smith IN CERT PGP 0 0 <OpenPGP binary>	405
			john.smith IN CNAME smith	406
			js IN CNAME smith	407
				408
			3.4. Purpose-Based OpenPGP CERT RR Names	409
				410
			Applications that receive an OpenPGP packet containing encrypted or	411
			signed data but do not know the email address of the sender will have	412
			difficulties constructing the correct owner name and cannot use the	413
			content-based owner name guidelines. However, these clients commonly	414
			know the key fingerprint or the Key ID. The key ID is found in	415
			OpenPGP packets, and the key fingerprint is commonly found in	416
			auxiliary data that may be available. In this case, use of an owner	417
			name identical to the key fingerprint and the key ID expressed in	418
			hexadecimal [16] is recommended. For example:	419
				420
			$ORIGIN example.org.	421
			0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...	422
			F835EDA21E94B565716F IN CERT PGP ...	423
			B565716F IN CERT PGP ...	424
				425
			If the same key material is stored for several owner names, the use	426
			of CNAME may help avoid data duplication. Note that CNAME is not	427
			always applicable, because it maps one owner name to the other for	428
			all purposes, which may be sub-optimal when two keys with the same	429
			Key ID are stored.	430
				431
			3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX	432
				433
			These types are stored under the same owner names, both purpose- and	434
			content-based, as the PKIX, SPKI, PGP, and ACPKIX types.	435
291				436
292	4. Performance Considerations		4. Performance Considerations	437
293				438
294	Current Domain Name System (DNS) implementations are optimized for		The Domain Name System (DNS) protocol was designed for small	439
295	small transfers, typically not more than 512 bytes including		transfers, typically below 512 octets. While larger transfers will	440
296	overhead. While larger transfers will perform correctly and work is		perform correctly and work is underway to make larger transfers more	441
297	underway to make larger transfers more efficient, it is still		efficient, it is still advisable at this time that every reasonable	442
298	advisable at this time to make every reasonable effort to minimize		effort be made to minimize the size of certificates stored within the	443
299	the size of certificates stored within the DNS. Steps that can be		DNS. Steps that can be taken may include using the fewest possible	444
300	taken may include using the fewest possible optional or extensions		optional or extension fields and using short field values for	445
301	fields and using short field values for variable length fields that		necessary variable-length fields.	446
302	must be included.
303				447
304	5. IANA Considerations		The RDATA field in the DNS protocol may only hold data of size 65535	448
			octets (64kb) or less. This means that each CERT RR MUST NOT contain	449
			more than 64kb of payload, even if the corresponding certificate or	450
			certificate revocation list is larger. This document addresses this	451
			by defining "indirect" data types for each normal type.	452
305				453
306	Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can		Deploying CERT RRs to support digitally signed email changes the	454
307	only be assigned by an IETF standards action [7] (and this document		access patterns of DNS lookups from per-domain to per-user. If	455
308	assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). Certificate		digitally signed email and a key/certificate lookup based on CERT RRs	456
309	types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]		are deployed on a wide scale, this may lead to an increased DNS load,	457
310	based on RFC documentation of the certificate type. The availability		with potential performance and cache effectiveness consequences.	458
311	of private types under 0x00FD and 0x00FE should satisfy most		Whether or not this load increase will be noticeable is not known.	459
312	requirements for proprietary or private types.
313				460
314	6. Security Considerations		5. Contributors	461
				462
			The majority of this document is copied verbatim from RFC 2538, by	463
			Donald Eastlake 3rd and Olafur Gudmundsson.	464
				465
			6. Acknowledgements	466
				467
			Thanks to David Shaw and Michael Graff for their contributions to	468
			earlier works that motivated, and served as inspiration for, this	469
			document.	470
				471
			This document was improved by suggestions and comments from Olivier	472
			Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.	473
			Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,	474
			Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel	475
			Weiler, Florian Weimer, and the IANA. No doubt the list is	476
			incomplete. We apologize to anyone we left out.	477
				478
			7. Security Considerations	479
315				480
316	By definition, certificates contain their own authenticating		By definition, certificates contain their own authenticating	481
317	signature. Thus it is reasonable to store certificates in non-secure		signatures. Thus, it is reasonable to store certificates in non-	482
318	DNS zones or to retrieve certificates from DNS with DNS security		secure DNS zones or to retrieve certificates from DNS with DNS	483
319	checking not implemented or deferred for efficiency. The results MAY		security checking not implemented or deferred for efficiency. The	484
320