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]
added
removed
doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
