⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2538.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 2 页
字号:

RFC 2538            Storing Certificates in the DNS           March 1999


   (1) If a domain name is included in the identification in the
       certificate or CRL, that should be used.
   (2) If a domain name is not included but an IP address is included,
       then the translation of that IP address into the appropriate
       inverse domain name should be used.
   (3) If neither of the above it used but a URI containing a domain
       name is present, that domain name should be used.
   (4) If none of the above is included but a character string name is
       included, then it should be treated as described for PGP names in
       3.2 below.
   (5) If none of the above apply, then the distinguished name (DN)
       should be mapped into a domain name as specified in RFC 2247.

   Example 1: Assume that an X.509v3 certificate is issued to /CN=John
   Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
   names of (a) string "John (the Man) Doe", (b) domain name john-
   doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
   the storage locations recommended, in priority order, would be
       (1) john-doe.com,
       (2) www.secure.john-doe.com, and
       (3) Doe.com.xy.

   Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
   of (a) domain name widget.foo.example, (b) IPv4 address
   10.251.13.201, and (c) string "James Hacker
   <hacker@mail.widget.foo.example>".  Then the storage locations
   recommended, in priority order, would be
        (1) widget.foo.example,
        (2) 201.13.251.10.in-addr.arpa, and
        (3) hacker.mail.widget.foo.example.

3.2 PGP CERT RR Names

   PGP signed keys (certificates) use a general character string User ID
   [RFC 2440]. However, it is recommended by PGP that such names include
   the RFC 822 email address of the party, as in "Leslie Example
   <Leslie@host.example>".  If such a format is used, the CERT should be
   under the standard translation of the email address into a domain
   name, which would be leslie.host.example in this case.  If no RFC 822
   name can be extracted from the string name no specific domain name is
   recommended.

4. Performance Considerations

   Current Domain Name System (DNS) implementations are optimized for
   small transfers, typically not more than 512 bytes including
   overhead.  While larger transfers will perform correctly and work is



Eastlake & Gudmundsson      Standards Track                     [Page 6]

RFC 2538            Storing Certificates in the DNS           March 1999


   underway to make larger transfers more efficient, it is still
   advisable at this time to make every reasonable effort to minimize
   the size of certificates stored within the DNS.  Steps that can be
   taken may include using the fewest possible optional or extensions
   fields and using short field values for variable length fields that
   must be included.

5. IANA Considerations

   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
   only be assigned by an IETF standards action [RFC 2434] (and this
   document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
   Certificate types 0x0100 through 0xFEFF are assigned through IETF
   Consensus [RFC 2434] based on RFC documentation of the certificate
   type.  The availability of private types under 0x00FD and 0x00FE
   should satisfy most requirements for proprietary or private types.

6. Security Considerations

   By definition, certificates contain their own authenticating
   signature.  Thus it is reasonable to store certificates in non-secure
   DNS zones or to retrieve certificates from DNS with DNS security
   checking not implemented or deferred for efficiency.  The results MAY
   be trusted if the certificate chain is verified back to a known
   trusted key and this conforms with the user's security policy.

   Alternatively, if certificates are retrieved from a secure DNS zone
   with DNS security checking enabled and are verified by DNS security,
   the key within the retrieved certificate MAY be trusted without
   verifying the certificate chain if this conforms with the user's
   security policy.

   CERT RRs are not used in connection with securing the DNS security
   additions so there are no security considerations related to CERT RRs
   and securing the DNS itself.
















Eastlake & Gudmundsson      Standards Track                     [Page 7]

RFC 2538            Storing Certificates in the DNS           March 1999


References

   RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

   RFC 1035   Mockapetris, P., "Domain Names - Implementation and
              Specifications", STD 13, RFC 1035, November 1987.

   RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
              Sataluri, "Using Domains in LDAP/X.500 Distinguished
              Names", RFC 2247, January 1998.

   RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
              "OpenPGP Message Format", RFC 2240, November 1998.

   RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
              Extensions", RFC 2535, March 1999.

   RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 2459, January 1999.



















Eastlake & Gudmundsson      Standards Track                     [Page 8]

RFC 2538            Storing Certificates in the DNS           March 1999


Authors' Addresses

   Donald E. Eastlake 3rd
   IBM
   65 Shindegan Hill Road
   RR#1
   Carmel, NY 10512 USA

   Phone:   +1-914-784-7913 (w)
            +1-914-276-2668 (h)
   Fax:     +1-914-784-3833 (w-fax)
   EMail:   dee3@us.ibm.com


   Olafur Gudmundsson
   TIS Labs at Network Associates
   3060 Washington Rd, Route 97
   Glenwood MD 21738

   Phone: +1 443-259-2389
   EMail: ogud@tislabs.com






























Eastlake & Gudmundsson      Standards Track                     [Page 9]

RFC 2538            Storing Certificates in the DNS           March 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Eastlake & Gudmundsson      Standards Track                    [Page 10]


⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -