4 Network Working Group S. Josefsson
5 Internet-Draft August 30, 2005
9 Storing Certificates in the Domain Name System (DNS)
10 draft-ietf-dnsext-rfc2538bis-04
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on March 3, 2006.
39 Copyright (C) The Internet Society (2005).
43 Cryptographic public keys are frequently published and their
44 authenticity demonstrated by certificates. A CERT resource record
45 (RR) is defined so that such certificates and related certificate
46 revocation lists can be stored in the Domain Name System (DNS).
48 This document obsoletes RFC 2538.
55 Josefsson Expires March 3, 2006 [Page 1]
57 Internet-Draft Storing Certificates in the DNS August 2005
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
64 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4
65 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5
66 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
67 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
68 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
69 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
70 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9
71 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
72 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
73 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
74 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
78 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
79 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12
80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
82 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
84 Intellectual Property and Copyright Statements . . . . . . . . . . 15
111 Josefsson Expires March 3, 2006 [Page 2]
113 Internet-Draft Storing Certificates in the DNS August 2005
118 Public keys are frequently published in the form of a certificate and
119 their authenticity is commonly demonstrated by certificates and
120 related certificate revocation lists (CRLs). A certificate is a
121 binding, through a cryptographic digital signature, of a public key,
122 a validity interval and/or conditions, and identity, authorization,
123 or other information. A certificate revocation list is a list of
124 certificates that are revoked, and incidental information, all signed
125 by the signer (issuer) of the revoked certificates. Examples are
126 X.509 certificates/CRLs in the X.500 directory system or OpenPGP
127 certificates/revocations used by OpenPGP software.
129 Section 2 below specifies a CERT resource record (RR) for the storage
130 of certificates in the Domain Name System [1] [2].
132 Section 3 discusses appropriate owner names for CERT RRs.
134 Sections 4, 5, and 6 below cover performance, IANA, and security
135 considerations, respectively.
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in [3].
142 2. The CERT Resource Record
144 The CERT resource record (RR) has the structure given below. Its RR
147 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
148 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
149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
153 +---------------+ certificate or CRL /
155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
157 The type field is the certificate type as defined in section 2.1
160 The key tag field is the 16 bit value computed for the key embedded
161 in the certificate, using the RRSIG Key Tag algorithm described in
162 Appendix B of [10]. This field is used as an efficiency measure to
163 pick which CERT RRs may be applicable to a particular key. The key
167 Josefsson Expires March 3, 2006 [Page 3]
169 Internet-Draft Storing Certificates in the DNS August 2005
172 tag can be calculated for the key in question and then only CERT RRs
173 with the same key tag need be examined. However, the key must always
174 be transformed to the format it would have as the public key portion
175 of a DNSKEY RR before the key tag is computed. This is only possible
176 if the key is applicable to an algorithm (and limits such as key size
177 limits) defined for DNS security. If it is not, the algorithm field
178 MUST BE zero and the tag field is meaningless and SHOULD BE zero.
180 The algorithm field has the same meaning as the algorithm field in
181 DNSKEY and RRSIG RRs [10], except that a zero algorithm field
182 indicates the algorithm is unknown to a secure DNS, which may simply
183 be the result of the algorithm not having been standardized for
186 2.1. Certificate Type Values
188 The following values are defined or reserved:
190 Value Mnemonic Certificate Type
191 ----- -------- ----------------
193 1 PKIX X.509 as per PKIX
194 2 SPKI SPKI certificate
196 4 IPKIX The URL of an X.509 data object
197 5 ISPKI The URL of an SPKI certificate
198 6 IPGP The URL of an OpenPGP packet
199 7-252 available for IANA assignment
202 255-65534 available for IANA assignment
205 The PKIX type is reserved to indicate an X.509 certificate conforming
206 to the profile being defined by the IETF PKIX working group. The
207 certificate section will start with a one-byte unsigned OID length
208 and then an X.500 OID indicating the nature of the remainder of the
209 certificate section (see 2.3 below). (NOTE: X.509 certificates do
210 not include their X.500 directory type designating OID as a prefix.)
212 The SPKI type is reserved to indicate the SPKI certificate format
213 [13], for use when the SPKI documents are moved from experimental
216 The PGP type indicates an OpenPGP packet as described in [6] and its
217 extensions and successors. Two uses are to transfer public key
218 material and revocation signatures. The data is binary, and MUST NOT
219 be encoded into an ASCII armor. An implementation SHOULD process
223 Josefsson Expires March 3, 2006 [Page 4]
225 Internet-Draft Storing Certificates in the DNS August 2005
228 transferable public keys as described in section 10.1 of [6], but it
229 MAY handle additional OpenPGP packets.
231 The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
232 content that would have been in the "certificate, CRL or URL" field
233 of the corresponding (PKIX, SPKI or PGP) packet types. These types
234 are known as "indirect". These packet types MUST be used when the
235 content is too large to fit in the CERT RR, and MAY be used at the
236 implementer's discretion. They SHOULD NOT be used where the entire
237 UDP packet would have fit in 512 bytes.
239 The URI private type indicates a certificate format defined by an
240 absolute URI. The certificate portion of the CERT RR MUST begin with
241 a null terminated URI [5] and the data after the null is the private
242 format certificate itself. The URI SHOULD be such that a retrieval
243 from it will lead to documentation on the format of the certificate.
244 Recognition of private certificate types need not be based on URI
245 equality but can use various forms of pattern matching so that, for
246 example, subtype or version information can also be encoded into the
249 The OID private type indicates a private format certificate specified
250 by an ISO OID prefix. The certificate section will start with a one-
251 byte unsigned OID length and then a BER encoded OID indicating the
252 nature of the remainder of the certificate section. This can be an
253 X.509 certificate format or some other format. X.509 certificates
254 that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
255 type, not the OID private type. Recognition of private certificate
256 types need not be based on OID equality but can use various forms of
257 pattern matching such as OID prefix.
259 2.2. Text Representation of CERT RRs
261 The RDATA portion of a CERT RR has the type field as an unsigned
262 decimal integer or as a mnemonic symbol as listed in section 2.1
265 The key tag field is represented as an unsigned decimal integer.
267 The algorithm field is represented as an unsigned decimal integer or
268 a mnemonic symbol as listed in [10].
270 The certificate / CRL portion is represented in base 64 [14] and may
271 be divided up into any number of white space separated substrings,
272 down to single base 64 digits, which are concatenated to obtain the
273 full signature. These substrings can span lines using the standard
279 Josefsson Expires March 3, 2006 [Page 5]
281 Internet-Draft Storing Certificates in the DNS August 2005
284 Note that the certificate / CRL portion may have internal sub-fields,
285 but these do not appear in the master file representation. For
286 example, with type 254, there will be an OID size, an OID, and then
287 the certificate / CRL proper. But only a single logical base 64
288 string will appear in the text representation.
292 OIDs have been defined in connection with the X.500 directory for
293 user certificates, certification authority certificates, revocations
294 of certification authority, and revocations of user certificates.
295 The following table lists the OIDs, their BER encoding, and their
296 length-prefixed hex format for use in CERT RRs:
298 id-at-userCertificate
299 = { joint-iso-ccitt(2) ds(5) at(4) 36 }
302 = { joint-iso-ccitt(2) ds(5) at(4) 37 }
304 id-at-authorityRevocationList
305 = { joint-iso-ccitt(2) ds(5) at(4) 38 }
307 id-at-certificateRevocationList
308 = { joint-iso-ccitt(2) ds(5) at(4) 39 }
312 3. Appropriate Owner Names for CERT RRs
314 It is recommended that certificate CERT RRs be stored under a domain
315 name related to their subject, i.e., the name of the entity intended
316 to control the private key corresponding to the public key being
317 certified. It is recommended that certificate revocation list CERT
318 RRs be stored under a domain name related to their issuer.
320 Following some of the guidelines below may result in the use in DNS
321 names of characters that require DNS quoting which is to use a
322 backslash followed by the octal representation of the ASCII code for
323 the character (e.g., \000 for NULL).
325 The choice of name under which CERT RRs are stored is important to
326 clients that perform CERT queries. In some situations, the clients
327 may not know all information about the CERT RR object it wishes to
328 retrieve. For example, a client may not know the subject name of an
329 X.509 certificate, or the e-mail address of the owner of an OpenPGP
330 key. Further, the client might only know the hostname of a service
331 that uses X.509 certificates or the Key ID of an OpenPGP key.
335 Josefsson Expires March 3, 2006 [Page 6]
337 Internet-Draft Storing Certificates in the DNS August 2005
340 Therefore, two owner name guidelines are defined: content-based owner
341 names and purpose-based owner names. A content-based owner name is
342 derived from the content of the CERT RR data; for example, the
343 Subject field in an X.509 certificate or the User ID field in OpenPGP
344 keys. A purpose-based owner name is a name that a client retrieving
345 CERT RRs MUST already know; for example, the host name of an X.509
346 protected service or the Key ID of an OpenPGP key. The content-based
347 and purpose-based owner name MAY be the same; for example, when a
348 client looks up a key based on the From: address of an incoming
351 Implementations SHOULD use the purpose-based owner name guidelines
352 described in this document, and MAY use CNAMEs of content-based owner
353 names (or other names), pointing to the purpose-based owner name.
355 3.1. Content-based X.509 CERT RR Names
357 Some X.509 versions permit multiple names to be associated with
358 subjects and issuers under "Subject Alternate Name" and "Issuer
359 Alternate Name". For example, X.509v3 has such Alternate Names with
360 an ASN.1 specification as follows:
362 GeneralName ::= CHOICE {
363 otherName [0] INSTANCE OF OTHER-NAME,
364 rfc822Name [1] IA5String,
365 dNSName [2] IA5String,
366 x400Address [3] EXPLICIT OR-ADDRESS.&Type,
367 directoryName [4] EXPLICIT Name,
368 ediPartyName [5] EDIPartyName,
369 uniformResourceIdentifier [6] IA5String,
370 iPAddress [7] OCTET STRING,
371 registeredID [8] OBJECT IDENTIFIER
374 The recommended locations of CERT storage are as follows, in priority
376 1. If a domain name is included in the identification in the
377 certificate or CRL, that should be used.
378 2. If a domain name is not included but an IP address is included,
379 then the translation of that IP address into the appropriate
380 inverse domain name should be used.
381 3. If neither of the above is used, but a URI containing a domain
382 name is present, that domain name should be used.
383 4. If none of the above is included but a character string name is
384 included, then it should be treated as described for OpenPGP
391 Josefsson Expires March 3, 2006 [Page 7]
393 Internet-Draft Storing Certificates in the DNS August 2005
396 5. If none of the above apply, then the distinguished name (DN)
397 should be mapped into a domain name as specified in [4].
399 Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
400 DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
401 string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
402 uri <https://www.secure.john-doe.com:8080/>. The storage locations
403 recommended, in priority order, would be
405 2. www.secure.john-doe.com, and
408 Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
409 L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
410 domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
411 (c) string "James Hacker <hacker@mail.widget.foo.example>". The
412 storage locations recommended, in priority order, would be
413 1. widget.foo.example,
414 2. 201.13.251.10.in-addr.arpa, and
415 3. hacker.mail.widget.foo.example.
417 3.2. Purpose-based X.509 CERT RR Names
419 Due to the difficulty for clients that do not already possess a
420 certificate to reconstruct the content-based owner name, purpose-
421 based owner names are recommended in this section. Recommendations
422 for purpose-based owner names vary per scenario. The following table
423 summarizes the purpose-based X.509 CERT RR owner name guidelines for
424 use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
427 ------------------ ----------------------------------------------
428 S/MIME Certificate Standard translation of an RFC 2822 email
429 address. Example: An S/MIME certificate for
430 "postmaster@example.org" will use a standard
431 hostname translation of the owner name,
432 "postmaster.example.org".
434 TLS Certificate Hostname of the TLS server.
436 IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4
437 or IPv6 addresses, the fully qualified domain
438 name in the appropriate reverse domain.
440 An alternate approach for IPSEC is to store raw public keys [15].
447 Josefsson Expires March 3, 2006 [Page 8]
449 Internet-Draft Storing Certificates in the DNS August 2005
452 3.3. Content-based OpenPGP CERT RR Names
454 OpenPGP signed keys (certificates) use a general character string
455 User ID [6]. However, it is recommended by OpenPGP that such names
456 include the RFC 2822 [8] email address of the party, as in "Leslie
457 Example <Leslie@host.example>". If such a format is used, the CERT
458 should be under the standard translation of the email address into a
459 domain name, which would be leslie.host.example in this case. If no
460 RFC 2822 name can be extracted from the string name, no specific
461 domain name is recommended.
463 If a user has more than one email address, the CNAME type can be used
464 to reduce the amount of data stored in the DNS. Example:
467 smith IN CERT PGP 0 0 <OpenPGP binary>
468 john.smith IN CNAME smith
471 3.4. Purpose-based OpenPGP CERT RR Names
473 Applications that receive an OpenPGP packet containing encrypted or
474 signed data but do not know the email address of the sender will have
475 difficulties constructing the correct owner name and cannot use the
476 content-based owner name guidelines. However, these clients commonly
477 know the key fingerprint or the Key ID. The key ID is found in
478 OpenPGP packets, and the key fingerprint is commonly found in
479 auxilliary data that may be available. In this case, use of an owner
480 name identical to the key fingerprint and the key ID expressed in
481 hexadecimal [14] is recommended. Example:
484 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
485 F835EDA21E94B565716F IN CERT PGP ...
486 B565716F IN CERT PGP ...
488 If the same key material is stored for several owner names, the use
489 of CNAME may be used to avoid data duplication. Note that CNAME is
490 not always applicable, because it maps one owner name to the other
491 for all purposes, which may be sub-optimal when two keys with the
492 same Key ID are stored.
494 3.5. Owner names for IPKIX, ISPKI, and IPGP
496 These types are stored under the same owner names, both purpose- and
497 content-based, as the PKIX, SPKI and PGP types.
503 Josefsson Expires March 3, 2006 [Page 9]
505 Internet-Draft Storing Certificates in the DNS August 2005
508 4. Performance Considerations
510 Current Domain Name System (DNS) implementations are optimized for
511 small transfers, typically not more than 512 bytes including
512 overhead. While larger transfers will perform correctly and work is
513 underway to make larger transfers more efficient, it is still
514 advisable at this time to make every reasonable effort to minimize
515 the size of certificates stored within the DNS. Steps that can be
516 taken may include using the fewest possible optional or extension
517 fields and using short field values for necessary variable length
520 The RDATA field in the DNS protocol may only hold data of size 65535
521 octets (64kb) or less. This means that each CERT RR MUST NOT contain
522 more than 64kb of payload, even if the corresponding certificate or
523 certificate revocation list is larger. This document addresses this
524 by defining "indirect" data types for each normal type.
529 The majority of this document is copied verbatim from RFC 2538, by
530 Donald Eastlake 3rd and Olafur Gudmundsson.
535 Thanks to David Shaw and Michael Graff for their contributions to
536 earlier works that motivated, and served as inspiration for, this
539 This document was improved by suggestions and comments from Olivier
540 Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
541 Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is
542 incomplete. We apologize to anyone we left out.
545 7. Security Considerations
547 By definition, certificates contain their own authenticating
548 signature. Thus, it is reasonable to store certificates in non-
549 secure DNS zones or to retrieve certificates from DNS with DNS
550 security checking not implemented or deferred for efficiency. The
551 results MAY be trusted if the certificate chain is verified back to a
552 known trusted key and this conforms with the user's security policy.
554 Alternatively, if certificates are retrieved from a secure DNS zone
555 with DNS security checking enabled and are verified by DNS security,
559 Josefsson Expires March 3, 2006 [Page 10]
561 Internet-Draft Storing Certificates in the DNS August 2005
564 the key within the retrieved certificate MAY be trusted without
565 verifying the certificate chain if this conforms with the user's
568 If an organization chooses to issue certificates for it's employees,
569 placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
570 is in use, it is possible for someone to enumerate all employees of
571 the organization. This is usually not considered desirable, for the
572 same reason enterprise phone listings are not often publicly
573 published and are even mark confidential.
575 When the URI type is used, it should be understood that it introduces
576 an additional indirection that may allow for a new attack vector.
577 One method to secure that indirection is to include a hash of the
578 certificate in the URI itself.
580 CERT RRs are not used by DNSSEC [9], so there are no security
581 considerations related to CERT RRs and securing the DNS itself.
583 If DNSSEC is used, then the non-existence of a CERT RR and,
584 consequently, certificates or revocation lists can be securely
585 asserted. Without DNSSEC, this is not possible.
588 8. IANA Considerations
590 Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
591 only be assigned by an IETF standards action [7]. This document
592 assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
593 types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
594 based on RFC documentation of the certificate type. The availability
595 of private types under 0x00FD and 0x00FE should satisfy most
596 requirements for proprietary or private types.
598 The CERT RR reuses the DNS Security Algorithm Numbers registry. In
599 particular, the CERT RR requires that algorithm number 0 remain
600 reserved, as described in Section 2. The IANA is directed to
601 reference the CERT RR as a user of this registry and value 0, in
605 9. Changes since RFC 2538
607 1. Editorial changes to conform with new document requirements,
608 including splitting reference section into two parts and
609 updating the references to point at latest versions, and to add
610 some additional references.
615 Josefsson Expires March 3, 2006 [Page 11]
617 Internet-Draft Storing Certificates in the DNS August 2005
620 2. Improve terminology. For example replace "PGP" with "OpenPGP",
621 to align with RFC 2440.
622 3. In section 2.1, clarify that OpenPGP public key data are binary,
623 not the ASCII armored format, and reference 10.1 in RFC 2440 on
624 how to deal with OpenPGP keys, and acknowledge that
625 implementations may handle additional packet types.
626 4. Clarify that integers in the representation format are decimal.
627 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
628 terminology. Improve reference for Key Tag Algorithm
630 6. Add examples that suggest use of CNAME to reduce bandwidth.
631 7. In section 3, appended the last paragraphs that discuss
632 "content-based" vs "purpose-based" owner names. Add section 3.2
633 for purpose-based X.509 CERT owner names, and section 3.4 for
634 purpose-based OpenPGP CERT owner names.
635 8. Added size considerations.
636 9. The SPKI types has been reserved, until RFC 2692/2693 is moved
637 from the experimental status.
638 10. Added indirect types IPKIX, ISPKI, and IPGP.
641 Appendix A. Copying conditions
643 Regarding the portion of this document that was written by Simon
644 Josefsson ("the author", for the remainder of this section), the
645 author makes no guarantees and is not responsible for any damage
646 resulting from its use. The author grants irrevocable permission to
647 anyone to use, modify, and distribute it in any way that does not
648 diminish the rights of anyone else to use, modify, and distribute it,
649 provided that redistributed derivative works do not contain
650 misleading author or version information. Derivative works need not
651 be licensed under similar terms.
656 10.1. Normative References
658 [1] Mockapetris, P., "Domain names - concepts and facilities",
659 STD 13, RFC 1034, November 1987.
661 [2] Mockapetris, P., "Domain names - implementation and
662 specification", STD 13, RFC 1035, November 1987.
664 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
665 Levels", BCP 14, RFC 2119, March 1997.
667 [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
671 Josefsson Expires March 3, 2006 [Page 12]
673 Internet-Draft Storing Certificates in the DNS August 2005
676 "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
679 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
680 Resource Identifiers (URI): Generic Syntax", RFC 2396,
683 [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
684 "OpenPGP Message Format", RFC 2440, November 1998.
686 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
687 Considerations Section in RFCs", BCP 26, RFC 2434,
690 [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
692 [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
693 "DNS Security Introduction and Requirements", RFC 4033,
696 [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
697 "Resource Records for the DNS Security Extensions", RFC 4034,
700 10.2. Informative References
702 [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
703 RFC 2246, January 1999.
705 [12] Kent, S. and R. Atkinson, "Security Architecture for the
706 Internet Protocol", RFC 2401, November 1998.
708 [13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
709 and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
712 [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
715 [15] Richardson, M., "A Method for Storing IPsec Keying Material in
716 DNS", RFC 4025, March 2005.
718 [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
719 (S/MIME) Version 3.1 Message Specification", RFC 3851,
727 Josefsson Expires March 3, 2006 [Page 13]
729 Internet-Draft Storing Certificates in the DNS August 2005
736 Email: simon@josefsson.org
783 Josefsson Expires March 3, 2006 [Page 14]
785 Internet-Draft Storing Certificates in the DNS August 2005
788 Intellectual Property Statement
790 The IETF takes no position regarding the validity or scope of any
791 Intellectual Property Rights or other rights that might be claimed to
792 pertain to the implementation or use of the technology described in
793 this document or the extent to which any license under such rights
794 might or might not be available; nor does it represent that it has
795 made any independent effort to identify any such rights. Information
796 on the procedures with respect to rights in RFC documents can be
797 found in BCP 78 and BCP 79.
799 Copies of IPR disclosures made to the IETF Secretariat and any
800 assurances of licenses to be made available, or the result of an
801 attempt made to obtain a general license or permission for the use of
802 such proprietary rights by implementers or users of this
803 specification can be obtained from the IETF on-line IPR repository at
804 http://www.ietf.org/ipr.
806 The IETF invites any interested party to bring to its attention any
807 copyrights, patents or patent applications, or other proprietary
808 rights that may cover technology that may be required to implement
809 this standard. Please address the information to the IETF at
813 Disclaimer of Validity
815 This document and the information contained herein are provided on an
816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
818 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
819 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
820 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
826 Copyright (C) The Internet Society (2005). This document is subject
827 to the rights, licenses and restrictions contained in BCP 78, and
828 except as set forth therein, the authors retain all their rights.
833 Funding for the RFC Editor function is currently provided by the
839 Josefsson Expires March 3, 2006 [Page 15]