idnits 2.17.1
draft-ietf-dnsext-rfc2538bis-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 680.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
== There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 18, 2005) is 6765 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: '0' is mentioned on line 308, but not defined
** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2440 (ref. '6') (Obsoleted by RFC 4880)
** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226)
** Obsolete normative reference: RFC 2822 (ref. '8') (Obsoleted by RFC 5322)
** Obsolete normative reference: RFC 3280 (ref. '9') (Obsoleted by RFC 5280)
** Obsolete normative reference: RFC 3281 (ref. '10') (Obsoleted by RFC
5755)
-- Obsolete informational reference (is this intentional?): RFC 2246 (ref.
'13') (Obsoleted by RFC 4346)
-- Obsolete informational reference (is this intentional?): RFC 2401 (ref.
'14') (Obsoleted by RFC 4301)
-- Obsolete informational reference (is this intentional?): RFC 3548 (ref.
'16') (Obsoleted by RFC 4648)
-- Obsolete informational reference (is this intentional?): RFC 3851 (ref.
'17') (Obsoleted by RFC 5751)
Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group S. Josefsson
3 Internet-Draft October 18, 2005
4 Obsoletes: 2538 (if approved)
5 Expires: April 21, 2006
7 Storing Certificates in the Domain Name System (DNS)
8 draft-ietf-dnsext-rfc2538bis-09
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on April 21, 2006.
35 Copyright Notice
37 Copyright (C) The Internet Society (2005).
39 Abstract
41 Cryptographic public keys are frequently published and their
42 authenticity demonstrated by certificates. A CERT resource record
43 (RR) is defined so that such certificates and related certificate
44 revocation lists can be stored in the Domain Name System (DNS).
46 This document obsoletes RFC 2538.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
51 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
52 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4
53 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5
54 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
55 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
56 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
57 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
58 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9
59 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
60 3.5. Owner names for IPKIX, ISPKI, IPGP, and IACPKIX . . . . . 10
61 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
62 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
66 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 12
67 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 13
68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
70 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
72 Intellectual Property and Copyright Statements . . . . . . . . . . 17
74 1. Introduction
76 Public keys are frequently published in the form of a certificate and
77 their authenticity is commonly demonstrated by certificates and
78 related certificate revocation lists (CRLs). A certificate is a
79 binding, through a cryptographic digital signature, of a public key,
80 a validity interval and/or conditions, and identity, authorization,
81 or other information. A certificate revocation list is a list of
82 certificates that are revoked, and incidental information, all signed
83 by the signer (issuer) of the revoked certificates. Examples are
84 X.509 certificates/CRLs in the X.500 directory system or OpenPGP
85 certificates/revocations used by OpenPGP software.
87 Section 2 below specifies a CERT resource record (RR) for the storage
88 of certificates in the Domain Name System [1] [2].
90 Section 3 discusses appropriate owner names for CERT RRs.
92 Sections 4, 5, and 6 below cover performance, IANA, and security
93 considerations, respectively.
95 Section 9 explain the changes in this document compared to RFC 2538.
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
99 document are to be interpreted as described in [3].
101 2. The CERT Resource Record
103 The CERT resource record (RR) has the structure given below. Its RR
104 type code is 37.
106 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
107 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
108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
109 | type | key tag |
110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
111 | algorithm | /
112 +---------------+ certificate or CRL /
113 / /
114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
116 The type field is the certificate type as defined in section 2.1
117 below.
119 The key tag field is the 16 bit value computed for the key embedded
120 in the certificate, using the RRSIG Key Tag algorithm described in
121 Appendix B of [12]. This field is used as an efficiency measure to
122 pick which CERT RRs may be applicable to a particular key. The key
123 tag can be calculated for the key in question and then only CERT RRs
124 with the same key tag need be examined. Note that two different keys
125 can have the same key tag. However, the key MUST be transformed to
126 the format it would have as the public key portion of a DNSKEY RR
127 before the key tag is computed. This is only possible if the key is
128 applicable to an algorithm and complies to limits (such as key size)
129 defined for DNS security. If it is not, the algorithm field MUST be
130 zero and the tag field is meaningless and SHOULD be zero.
132 The algorithm field has the same meaning as the algorithm field in
133 DNSKEY and RRSIG RRs [12], except that a zero algorithm field
134 indicates the algorithm is unknown to a secure DNS, which may simply
135 be the result of the algorithm not having been standardized for
136 DNSSEC [11].
138 2.1. Certificate Type Values
140 The following values are defined or reserved:
142 Value Mnemonic Certificate Type
143 ----- -------- ----------------
144 0 reserved
145 1 PKIX X.509 as per PKIX
146 2 SPKI SPKI certificate
147 3 PGP OpenPGP packet
148 4 IPKIX The URL of an X.509 data object
149 5 ISPKI The URL of an SPKI certificate
150 6 IPGP The URL of an OpenPGP packet
151 7 ACPKIX Attribute Certificate
152 8 IACPKIX The URL of an Attribute Certificate
153 9-252 available for IANA assignment
154 253 URI URI private
155 254 OID OID private
156 255-65023 available for IANA assignment
157 65024-65534 experimental
158 65535 reserved
160 These values represent the initial content of the IANA registry, see
161 section 8.
163 The PKIX type is reserved to indicate an X.509 certificate conforming
164 to the profile defined by the IETF PKIX working group [9]. The
165 certificate section will start with a one-octet unsigned OID length
166 and then an X.500 OID indicating the nature of the remainder of the
167 certificate section (see 2.3 below). (NOTE: X.509 certificates do
168 not include their X.500 directory type designating OID as a prefix.)
169 The SPKI type is reserved to indicate the SPKI certificate format
170 [15], for use when the SPKI documents are moved from experimental
171 status.
173 The PGP type indicates an OpenPGP packet as described in [6] and its
174 extensions and successors. Two uses are to transfer public key
175 material and revocation signatures. The data is binary, and MUST NOT
176 be encoded into an ASCII armor. An implementation SHOULD process
177 transferable public keys as described in section 10.1 of [6], but it
178 MAY handle additional OpenPGP packets.
180 The ACPKIX type indicate an Attribute Certificate format [10].
182 The IPKIX, ISPKI, IPGP, IACPKIX types indicate a URL which will serve
183 the content that would have been in the "certificate, CRL or URL"
184 field of the corresponding types; PKIX, SPKI, PGP, or ACPKIX
185 respectively. The IPKIX, ISPKI, IPGP and IACPKIX types are known as
186 "indirect". These types MUST be used when the content is too large
187 to fit in the CERT RR, and MAY be used at the implementer's
188 discretion. They SHOULD NOT be used where the DNS message is 512
189 octets or smaller, and could thus be expected to fit a UDP packet.
191 The URI private type indicates a certificate format defined by an
192 absolute URI. The certificate portion of the CERT RR MUST begin with
193 a null terminated URI [5] and the data after the null is the private
194 format certificate itself. The URI SHOULD be such that a retrieval
195 from it will lead to documentation on the format of the certificate.
196 Recognition of private certificate types need not be based on URI
197 equality but can use various forms of pattern matching so that, for
198 example, subtype or version information can also be encoded into the
199 URI.
201 The OID private type indicates a private format certificate specified
202 by an ISO OID prefix. The certificate section will start with a one-
203 octet unsigned OID length and then a BER encoded OID indicating the
204 nature of the remainder of the certificate section. This can be an
205 X.509 certificate format or some other format. X.509 certificates
206 that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
207 type, not the OID private type. Recognition of private certificate
208 types need not be based on OID equality but can use various forms of
209 pattern matching such as OID prefix.
211 2.2. Text Representation of CERT RRs
213 The RDATA portion of a CERT RR has the type field as an unsigned
214 decimal integer or as a mnemonic symbol as listed in section 2.1
215 above.
217 The key tag field is represented as an unsigned decimal integer.
219 The algorithm field is represented as an unsigned decimal integer or
220 a mnemonic symbol as listed in [12].
222 The certificate / CRL portion is represented in base 64 [16] and may
223 be divided up into any number of white space separated substrings,
224 down to single base 64 digits, which are concatenated to obtain the
225 full signature. These substrings can span lines using the standard
226 parenthesis.
228 Note that the certificate / CRL portion may have internal sub-fields,
229 but these do not appear in the master file representation. For
230 example, with type 254, there will be an OID size, an OID, and then
231 the certificate / CRL proper. But only a single logical base 64
232 string will appear in the text representation.
234 2.3. X.509 OIDs
236 OIDs have been defined in connection with the X.500 directory for
237 user certificates, certification authority certificates, revocations
238 of certification authority, and revocations of user certificates.
239 The following table lists the OIDs, their BER encoding, and their
240 length-prefixed hex format for use in CERT RRs:
242 id-at-userCertificate
243 = { joint-iso-ccitt(2) ds(5) at(4) 36 }
244 == 0x 03 55 04 24
245 id-at-cACertificate
246 = { joint-iso-ccitt(2) ds(5) at(4) 37 }
247 == 0x 03 55 04 25
248 id-at-authorityRevocationList
249 = { joint-iso-ccitt(2) ds(5) at(4) 38 }
250 == 0x 03 55 04 26
251 id-at-certificateRevocationList
252 = { joint-iso-ccitt(2) ds(5) at(4) 39 }
253 == 0x 03 55 04 27
255 3. Appropriate Owner Names for CERT RRs
257 It is recommended that certificate CERT RRs be stored under a domain
258 name related to their subject, i.e., the name of the entity intended
259 to control the private key corresponding to the public key being
260 certified. It is recommended that certificate revocation list CERT
261 RRs be stored under a domain name related to their issuer.
263 Following some of the guidelines below may result in DNS names with
264 characters that require DNS quoting as per section 5.1 of RFC 1035
265 [2].
267 The choice of name under which CERT RRs are stored is important to
268 clients that perform CERT queries. In some situations, the clients
269 may not know all information about the CERT RR object it wishes to
270 retrieve. For example, a client may not know the subject name of an
271 X.509 certificate, or the e-mail address of the owner of an OpenPGP
272 key. Further, the client might only know the hostname of a service
273 that uses X.509 certificates or the Key ID of an OpenPGP key.
275 Therefore, two owner name guidelines are defined: content-based owner
276 names and purpose-based owner names. A content-based owner name is
277 derived from the content of the CERT RR data; for example, the
278 Subject field in an X.509 certificate or the User ID field in OpenPGP
279 keys. A purpose-based owner name is a name that a client retrieving
280 CERT RRs ought to already know; for example, the host name of an
281 X.509 protected service or the Key ID of an OpenPGP key. The
282 content-based and purpose-based owner name may be the same; for
283 example, when a client looks up a key based on the From: address of
284 an incoming e-mail.
286 Implementations SHOULD use the purpose-based owner name guidelines
287 described in this document, and MAY use CNAME RRs at content-based
288 owner names (or other names), pointing to the purpose-based owner
289 name.
291 Note that this section describes an application-based mapping from
292 the name space used in a certificate to the name space used by DNS.
293 The DNS does not infer any relationship amongst CERT resource records
294 based on similarities or differences of the DNS owner name(s) of CERT
295 resource records. For example, if multiple labels are used when
296 mapping from a CERT identifier to a domain name then care must be
297 taken in understanding wildcard record synthesis.
299 3.1. Content-based X.509 CERT RR Names
301 Some X.509 versions, such as the PKIX profile of X.509 [9], permit
302 multiple names to be associated with subjects and issuers under
303 "Subject Alternative Name" and "Issuer Alternative Name". For
304 example, the PKIX profile has such Alternate Names with an ASN.1
305 specification as follows:
307 GeneralName ::= CHOICE {
308 otherName [0] OtherName,
309 rfc822Name [1] IA5String,
310 dNSName [2] IA5String,
311 x400Address [3] ORAddress,
312 directoryName [4] Name,
313 ediPartyName [5] EDIPartyName,
314 uniformResourceIdentifier [6] IA5String,
315 iPAddress [7] OCTET STRING,
316 registeredID [8] OBJECT IDENTIFIER }
318 The recommended locations of CERT storage are as follows, in priority
319 order:
320 1. If a domain name is included in the identification in the
321 certificate or CRL, that ought be used.
322 2. If a domain name is not included but an IP address is included,
323 then the translation of that IP address into the appropriate
324 inverse domain name ought to be used.
325 3. If neither of the above is used, but a URI containing a domain
326 name is present, that domain name ought to be used.
327 4. If none of the above is included but a character string name is
328 included, then it ought to be treated as described for OpenPGP
329 names below.
330 5. If none of the above apply, then the distinguished name (DN)
331 ought to be mapped into a domain name as specified in [4].
333 Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
334 DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
335 string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
336 URI . The storage locations
337 recommended, in priority order, would be
338 1. john-doe.com,
339 2. www.secure.john-doe.com, and
340 3. Doe.com.xy.
342 Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
343 L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
344 domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
345 (c) string "James Hacker ". The
346 storage locations recommended, in priority order, would be
347 1. widget.foo.example,
348 2. 201.13.251.10.in-addr.arpa, and
349 3. hacker.mail.widget.foo.example.
351 3.2. Purpose-based X.509 CERT RR Names
353 Due to the difficulty for clients that do not already possess a
354 certificate to reconstruct the content-based owner name, purpose-
355 based owner names are recommended in this section. Recommendations
356 for purpose-based owner names vary per scenario. The following table
357 summarizes the purpose-based X.509 CERT RR owner name guidelines for
358 use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
360 Scenario Owner name
361 ------------------ ----------------------------------------------
362 S/MIME Certificate Standard translation of an RFC 2822 email
363 address. Example: An S/MIME certificate for
364 "postmaster@example.org" will use a standard
365 hostname translation of the owner name,
366 "postmaster.example.org".
368 TLS Certificate Hostname of the TLS server.
370 IPsec Certificate Hostname of the IPsec machine and/or, for IPv4
371 or IPv6 addresses, the fully qualified domain
372 name in the appropriate reverse domain.
374 An alternate approach for IPsec is to store raw public keys [18].
376 3.3. Content-based OpenPGP CERT RR Names
378 OpenPGP signed keys (certificates) use a general character string
379 User ID [6]. However, it is recommended by OpenPGP that such names
380 include the RFC 2822 [8] email address of the party, as in "Leslie
381 Example ". If such a format is used, the CERT
382 ought to be under the standard translation of the email address into
383 a domain name, which would be leslie.host.example in this case. If
384 no RFC 2822 name can be extracted from the string name, no specific
385 domain name is recommended.
387 If a user has more than one email address, the CNAME type can be used
388 to reduce the amount of data stored in the DNS. Example:
390 $ORIGIN example.org.
391 smith IN CERT PGP 0 0
392 john.smith IN CNAME smith
393 js IN CNAME smith
395 3.4. Purpose-based OpenPGP CERT RR Names
397 Applications that receive an OpenPGP packet containing encrypted or
398 signed data but do not know the email address of the sender will have
399 difficulties constructing the correct owner name and cannot use the
400 content-based owner name guidelines. However, these clients commonly
401 know the key fingerprint or the Key ID. The key ID is found in
402 OpenPGP packets, and the key fingerprint is commonly found in
403 auxiliary data that may be available. In this case, use of an owner
404 name identical to the key fingerprint and the key ID expressed in
405 hexadecimal [16] is recommended. Example:
407 $ORIGIN example.org.
408 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
409 F835EDA21E94B565716F IN CERT PGP ...
410 B565716F IN CERT PGP ...
412 If the same key material is stored for several owner names, the use
413 of CNAME may help to avoid data duplication. Note that CNAME is not
414 always applicable, because it maps one owner name to the other for
415 all purposes, which may be sub-optimal when two keys with the same
416 Key ID are stored.
418 3.5. Owner names for IPKIX, ISPKI, IPGP, and IACPKIX
420 These types are stored under the same owner names, both purpose- and
421 content-based, as the PKIX, SPKI, PGP and ACPKIX types.
423 4. Performance Considerations
425 The Domain Name System (DNS) protocol was designed for small
426 transfers, typically below 512 octets. While larger transfers will
427 perform correctly and work is underway to make larger transfers more
428 efficient, it is still advisable at this time to make every
429 reasonable effort to minimize the size of certificates stored within
430 the DNS. Steps that can be taken may include using the fewest
431 possible optional or extension fields and using short field values
432 for necessary variable length fields.
434 The RDATA field in the DNS protocol may only hold data of size 65535
435 octets (64kb) or less. This means that each CERT RR MUST NOT contain
436 more than 64kb of payload, even if the corresponding certificate or
437 certificate revocation list is larger. This document addresses this
438 by defining "indirect" data types for each normal type.
440 Deploying CERT RRs to support digitally signed e-mail change the
441 access patterns of DNS lookups from per-domain to per-user. If
442 digitally signed e-mail, and a key/certificate lookup based on CERT
443 RRs, is deployed on a wide scale, this may lead to an increased DNS
444 load, with potential performance and cache effectiveness
445 consequencess. Whether this load increase will be noticable or not
446 is not known.
448 5. Contributors
450 The majority of this document is copied verbatim from RFC 2538, by
451 Donald Eastlake 3rd and Olafur Gudmundsson.
453 6. Acknowledgements
455 Thanks to David Shaw and Michael Graff for their contributions to
456 earlier works that motivated, and served as inspiration for, this
457 document.
459 This document was improved by suggestions and comments from Olivier
460 Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
461 Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
462 Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
463 Weiler, and Florian Weimer. No doubt the list is incomplete. We
464 apologize to anyone we left out.
466 7. Security Considerations
468 By definition, certificates contain their own authenticating
469 signature. Thus, it is reasonable to store certificates in non-
470 secure DNS zones or to retrieve certificates from DNS with DNS
471 security checking not implemented or deferred for efficiency. The
472 results may be trusted if the certificate chain is verified back to a
473 known trusted key and this conforms with the user's security policy.
475 Alternatively, if certificates are retrieved from a secure DNS zone
476 with DNS security checking enabled and are verified by DNS security,
477 the key within the retrieved certificate may be trusted without
478 verifying the certificate chain if this conforms with the user's
479 security policy.
481 If an organization chooses to issue certificates for its employees,
482 placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
483 is in use, it is possible for someone to enumerate all employees of
484 the organization. This is usually not considered desirable, for the
485 same reason enterprise phone listings are not often publicly
486 published and are even mark confidential.
488 Using the URI type introduces another level of indirection that may
489 open a new vulnerability. One method to secure that indirection is
490 to include a hash of the certificate in the URI itself.
492 If DNSSEC is used, then the non-existence of a CERT RR and,
493 consequently, certificates or revocation lists can be securely
494 asserted. Without DNSSEC, this is not possible.
496 8. IANA Considerations
498 IANA needs to create a new registry for CERT RR, certificate types.
499 The initial contents of this registry is:
501 [[RFC Editor: Replace xxxx below with the number of this RFC.]]
503 Decimal Type Meaning Reference
504 ------- ---- ------- ---------
505 0 Reserved RFC xxxx
506 1 PKIX X.509 as per PKIX RFC xxxx
507 2 SPKI SPKI certificate RFC xxxx
508 3 PGP OpenPGP packet RFC xxxx
509 4 IPKIX The URL of an X.509 data object RFC xxxx
510 5 ISPKI The URL of an SPKI certificate RFC xxxx
511 6 IPGP The URL of an OpenPGP packet RFC xxxx
512 7 ACPKIX Attribute Certificate RFC xxxx
513 8 IACPKIX The URL of an Attribute Certificate RFC xxxx
514 9-252 Available for IANA assignment
515 by IETF Standards action
516 253 URI URI private RFC xxxx
517 254 OID OID private RFC xxxx
518 255-65023 Available for IANA assignment
519 by IETF Consensus
520 65024-65534 Experimental RFC xxxx
521 65535 Reserved RFC xxxx
523 Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
524 only be assigned by an IETF standards action [7]. This document
525 assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate
526 types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
527 based on RFC documentation of the certificate type. The availability
528 of private types under 0x00FD and 0x00FE ought to satisfy most
529 requirements for proprietary or private types.
531 The CERT RR reuses the DNS Security Algorithm Numbers registry. In
532 particular, the CERT RR requires that algorithm number 0 remain
533 reserved, as described in Section 2. The IANA is directed to
534 reference the CERT RR as a user of this registry and value 0, in
535 particular.
537 9. Changes since RFC 2538
538 1. Editorial changes to conform with new document requirements,
539 including splitting reference section into two parts and
540 updating the references to point at latest versions, and to add
541 some additional references.
542 2. Improve terminology. For example replace "PGP" with "OpenPGP",
543 to align with RFC 2440.
544 3. In section 2.1, clarify that OpenPGP public key data are binary,
545 not the ASCII armored format, and reference 10.1 in RFC 2440 on
546 how to deal with OpenPGP keys, and acknowledge that
547 implementations may handle additional packet types.
548 4. Clarify that integers in the representation format are decimal.
549 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
550 terminology. Improve reference for Key Tag Algorithm
551 calculations.
552 6. Add examples that suggest use of CNAME to reduce bandwidth.
553 7. In section 3, appended the last paragraphs that discuss
554 "content-based" vs "purpose-based" owner names. Add section 3.2
555 for purpose-based X.509 CERT owner names, and section 3.4 for
556 purpose-based OpenPGP CERT owner names.
557 8. Added size considerations.
558 9. The SPKI types has been reserved, until RFC 2692/2693 is moved
559 from the experimental status.
560 10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
561 11. An IANA registry of CERT type values was created.
563 Appendix A. Copying conditions
565 Regarding the portion of this document that was written by Simon
566 Josefsson ("the author", for the remainder of this section), the
567 author makes no guarantees and is not responsible for any damage
568 resulting from its use. The author grants irrevocable permission to
569 anyone to use, modify, and distribute it in any way that does not
570 diminish the rights of anyone else to use, modify, and distribute it,
571 provided that redistributed derivative works do not contain
572 misleading author or version information. Derivative works need not
573 be licensed under similar terms.
575 10. References
577 10.1. Normative References
579 [1] Mockapetris, P., "Domain names - concepts and facilities",
580 STD 13, RFC 1034, November 1987.
582 [2] Mockapetris, P., "Domain names - implementation and
583 specification", STD 13, RFC 1035, November 1987.
585 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
586 Levels", BCP 14, RFC 2119, March 1997.
588 [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
589 "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
590 January 1998.
592 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
593 Resource Identifiers (URI): Generic Syntax", RFC 2396,
594 August 1998.
596 [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
597 "OpenPGP Message Format", RFC 2440, November 1998.
599 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
600 Considerations Section in RFCs", BCP 26, RFC 2434,
601 October 1998.
603 [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
605 [9] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
606 Public Key Infrastructure Certificate and Certificate
607 Revocation List (CRL) Profile", RFC 3280, April 2002.
609 [10] Farrell, S. and R. Housley, "An Internet Attribute Certificate
610 Profile for Authorization", RFC 3281, April 2002.
612 [11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
613 "DNS Security Introduction and Requirements", RFC 4033,
614 March 2005.
616 [12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
617 "Resource Records for the DNS Security Extensions", RFC 4034,
618 March 2005.
620 10.2. Informative References
622 [13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
623 RFC 2246, January 1999.
625 [14] Kent, S. and R. Atkinson, "Security Architecture for the
626 Internet Protocol", RFC 2401, November 1998.
628 [15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
629 and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
630 September 1999.
632 [16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
633 RFC 3548, July 2003.
635 [17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
636 (S/MIME) Version 3.1 Message Specification", RFC 3851,
637 July 2004.
639 [18] Richardson, M., "A Method for Storing IPsec Keying Material in
640 DNS", RFC 4025, March 2005.
642 Author's Address
644 Simon Josefsson
646 Email: simon@josefsson.org
648 Intellectual Property Statement
650 The IETF takes no position regarding the validity or scope of any
651 Intellectual Property Rights or other rights that might be claimed to
652 pertain to the implementation or use of the technology described in
653 this document or the extent to which any license under such rights
654 might or might not be available; nor does it represent that it has
655 made any independent effort to identify any such rights. Information
656 on the procedures with respect to rights in RFC documents can be
657 found in BCP 78 and BCP 79.
659 Copies of IPR disclosures made to the IETF Secretariat and any
660 assurances of licenses to be made available, or the result of an
661 attempt made to obtain a general license or permission for the use of
662 such proprietary rights by implementers or users of this
663 specification can be obtained from the IETF on-line IPR repository at
664 http://www.ietf.org/ipr.
666 The IETF invites any interested party to bring to its attention any
667 copyrights, patents or patent applications, or other proprietary
668 rights that may cover technology that may be required to implement
669 this standard. Please address the information to the IETF at
670 ietf-ipr@ietf.org.
672 Disclaimer of Validity
674 This document and the information contained herein are provided on an
675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
677 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
678 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
679 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
682 Copyright Statement
684 Copyright (C) The Internet Society (2005). This document is subject
685 to the rights, licenses and restrictions contained in BCP 78, and
686 except as set forth therein, the authors retain all their rights.
688 Acknowledgment
690 Funding for the RFC Editor function is currently provided by the
691 Internet Society.