draft-ietf-dnsext-rfc2538bis-04.txt

bind 源码 最新实现 linux/unix/windows平台

   Note that the certificate / CRL portion may have internal sub-fields,
   but these do not appear in the master file representation.  For
   example, with type 254, there will be an OID size, an OID, and then
   the certificate / CRL proper.  But only a single logical base 64
   string will appear in the text representation.

2.3.  X.509 OIDs

   OIDs have been defined in connection with the X.500 directory for
   user certificates, certification authority certificates, revocations
   of certification authority, and revocations of user certificates.
   The following table lists the OIDs, their BER encoding, and their
   length-prefixed hex format for use in CERT RRs:

       id-at-userCertificate
           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
              == 0x 03 55 04 24
       id-at-cACertificate
           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
              == 0x 03 55 04 25
       id-at-authorityRevocationList
           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
              == 0x 03 55 04 26
       id-at-certificateRevocationList
           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
              == 0x 03 55 04 27


3.  Appropriate Owner Names for CERT RRs

   It is recommended that certificate CERT RRs be stored under a domain
   name related to their subject, i.e., the name of the entity intended
   to control the private key corresponding to the public key being
   certified.  It is recommended that certificate revocation list CERT
   RRs be stored under a domain name related to their issuer.

   Following some of the guidelines below may result in the use in DNS
   names of characters that require DNS quoting which is to use a
   backslash followed by the octal representation of the ASCII code for
   the character (e.g., \000 for NULL).

   The choice of name under which CERT RRs are stored is important to
   clients that perform CERT queries.  In some situations, the clients
   may not know all information about the CERT RR object it wishes to
   retrieve.  For example, a client may not know the subject name of an
   X.509 certificate, or the e-mail address of the owner of an OpenPGP
   key.  Further, the client might only know the hostname of a service
   that uses X.509 certificates or the Key ID of an OpenPGP key.



Josefsson                 Expires March 3, 2006                 [Page 6]

Internet-Draft       Storing Certificates in the DNS         August 2005


   Therefore, two owner name guidelines are defined: content-based owner
   names and purpose-based owner names.  A content-based owner name is
   derived from the content of the CERT RR data; for example, the
   Subject field in an X.509 certificate or the User ID field in OpenPGP
   keys.  A purpose-based owner name is a name that a client retrieving
   CERT RRs MUST already know; for example, the host name of an X.509
   protected service or the Key ID of an OpenPGP key.  The content-based
   and purpose-based owner name MAY be the same; for example, when a
   client looks up a key based on the From: address of an incoming
   e-mail.

   Implementations SHOULD use the purpose-based owner name guidelines
   described in this document, and MAY use CNAMEs of content-based owner
   names (or other names), pointing to the purpose-based owner name.

3.1.  Content-based X.509 CERT RR Names

   Some X.509 versions permit multiple names to be associated with
   subjects and issuers under "Subject Alternate Name" and "Issuer
   Alternate Name".  For example, X.509v3 has such Alternate Names with
   an ASN.1 specification as follows:

        GeneralName ::= CHOICE {
           otherName                  [0] INSTANCE OF OTHER-NAME,
           rfc822Name                 [1] IA5String,
           dNSName                    [2] IA5String,
           x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
           directoryName              [4] EXPLICIT Name,
           ediPartyName               [5] EDIPartyName,
           uniformResourceIdentifier  [6] IA5String,
           iPAddress                  [7] OCTET STRING,
           registeredID               [8] OBJECT IDENTIFIER
        }

   The recommended locations of CERT storage are as follows, in priority
   order:
   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 is 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 OpenPGP
       names below.





Josefsson                 Expires March 3, 2006                 [Page 7]

Internet-Draft       Storing Certificates in the DNS         August 2005


   5.  If none of the above apply, then the distinguished name (DN)
       should be mapped into a domain name as specified in [4].

   Example 1: 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/>.  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: 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 <[e-mail]>".  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.  Purpose-based X.509 CERT RR Names

   Due to the difficulty for clients that do not already possess a
   certificate to reconstruct the content-based owner name, purpose-
   based owner names are recommended in this section.  Recommendations
   for purpose-based owner names vary per scenario.  The following table
   summarizes the purpose-based X.509 CERT RR owner name guidelines for
   use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:

    Scenario             Owner name
    ------------------   ----------------------------------------------
    S/MIME Certificate   Standard translation of an RFC 2822 email
                         address.  Example: An S/MIME certificate for
                         "[e-mail]" will use a standard
                         hostname translation of the owner name,
                         "postmaster.example.org".

    TLS Certificate      Hostname of the TLS server.

    IPSEC Certificate    Hostname of the IPSEC machine and/or, for IPv4
                         or IPv6 addresses, the fully qualified domain
                         name in the appropriate reverse domain.

   An alternate approach for IPSEC is to store raw public keys [15].






Josefsson                 Expires March 3, 2006                 [Page 8]

Internet-Draft       Storing Certificates in the DNS         August 2005


3.3.  Content-based OpenPGP CERT RR Names

   OpenPGP signed keys (certificates) use a general character string
   User ID [6].  However, it is recommended by OpenPGP that such names
   include the RFC 2822 [8] email address of the party, as in "Leslie
   Example <[e-mail]>".  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 2822 name can be extracted from the string name, no specific
   domain name is recommended.

   If a user has more than one email address, the CNAME type can be used
   to reduce the amount of data stored in the DNS.  Example:

      $ORIGIN example.org.
      smith        IN CERT PGP 0 0 <OpenPGP binary>
      john.smith   IN CNAME smith
      js           IN CNAME smith

3.4.  Purpose-based OpenPGP CERT RR Names

   Applications that receive an OpenPGP packet containing encrypted or
   signed data but do not know the email address of the sender will have
   difficulties constructing the correct owner name and cannot use the
   content-based owner name guidelines.  However, these clients commonly
   know the key fingerprint or the Key ID.  The key ID is found in
   OpenPGP packets, and the key fingerprint is commonly found in
   auxilliary data that may be available.  In this case, use of an owner
   name identical to the key fingerprint and the key ID expressed in
   hexadecimal [14] is recommended.  Example:

      $ORIGIN example.org.
      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
      F835EDA21E94B565716F                     IN CERT PGP ...
      B565716F                                 IN CERT PGP ...

   If the same key material is stored for several owner names, the use
   of CNAME may be used to avoid data duplication.  Note that CNAME is
   not always applicable, because it maps one owner name to the other
   for all purposes, which may be sub-optimal when two keys with the
   same Key ID are stored.

3.5.  Owner names for IPKIX, ISPKI, and IPGP

   These types are stored under the same owner names, both purpose- and
   content-based, as the PKIX, SPKI and PGP types.





Josefsson                 Expires March 3, 2006                 [Page 9]

Internet-Draft       Storing Certificates in the DNS         August 2005


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
   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 extension
   fields and using short field values for necessary variable length
   fields.

   The RDATA field in the DNS protocol may only hold data of size 65535
   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
   more than 64kb of payload, even if the corresponding certificate or
   certificate revocation list is larger.  This document addresses this
   by defining "indirect" data types for each normal type.


5.  Contributors

   The majority of this document is copied verbatim from RFC 2538, by
   Donald Eastlake 3rd and Olafur Gudmundsson.


6.  Acknowledgements

   Thanks to David Shaw and Michael Graff for their contributions to
   earlier works that motivated, and served as inspiration for, this
   document.

   This document was improved by suggestions and comments from Olivier
   Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
   Sloderbeck, Samuel Weiler, and Florian Weimer.  No doubt the list is
   incomplete.  We apologize to anyone we left out.


7.  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,



Josefsson                 Expires March 3, 2006                [Page 10]

Internet-Draft       Storing Certificates in the DNS         August 2005