draft-ietf-dnsext-rfc2538bis-04.txt

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

Network Working Group                                       S. Josefsson
Internet-Draft                                           August 30, 2005
Expires: March 3, 2006


          Storing Certificates in the Domain Name System (DNS)
                    draft-ietf-dnsext-rfc2538bis-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Cryptographic public keys are frequently published and their
   authenticity demonstrated by certificates.  A CERT resource record
   (RR) is defined so that such certificates and related certificate
   revocation lists can be stored in the Domain Name System (DNS).

   This document obsoletes RFC 2538.






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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The CERT Resource Record . . . . . . . . . . . . . . . . . . .  3
     2.1.  Certificate Type Values  . . . . . . . . . . . . . . . . .  4
     2.2.  Text Representation of CERT RRs  . . . . . . . . . . . . .  5
     2.3.  X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Appropriate Owner Names for CERT RRs . . . . . . . . . . . . .  6
     3.1.  Content-based X.509 CERT RR Names  . . . . . . . . . . . .  7
     3.2.  Purpose-based X.509 CERT RR Names  . . . . . . . . . . . .  8
     3.3.  Content-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
     3.4.  Purpose-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
     3.5.  Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . .  9
   4.  Performance Considerations . . . . . . . . . . . . . . . . . . 10
   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Copying conditions  . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15


























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


1.  Introduction

   Public keys are frequently published in the form of a certificate and
   their authenticity is commonly demonstrated by certificates and
   related certificate revocation lists (CRLs).  A certificate is a
   binding, through a cryptographic digital signature, of a public key,
   a validity interval and/or conditions, and identity, authorization,
   or other information.  A certificate revocation list is a list of
   certificates that are revoked, and incidental information, all signed
   by the signer (issuer) of the revoked certificates.  Examples are
   X.509 certificates/CRLs in the X.500 directory system or OpenPGP
   certificates/revocations used by OpenPGP software.

   Section 2 below specifies a CERT resource record (RR) for the storage
   of certificates in the Domain Name System [1] [2].

   Section 3 discusses appropriate owner names for CERT RRs.

   Sections 4, 5, and 6 below cover performance, IANA, and security
   considerations, respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [3].


2.  The CERT Resource Record

   The CERT resource record (RR) has the structure given below.  Its RR
   type code is 37.

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             type              |             key tag           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   algorithm   |                                               /
   +---------------+            certificate or CRL                 /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

   The type field is the certificate type as defined in section 2.1
   below.

   The key tag field is the 16 bit value computed for the key embedded
   in the certificate, using the RRSIG Key Tag algorithm described in
   Appendix B of [10].  This field is used as an efficiency measure to
   pick which CERT RRs may be applicable to a particular key.  The key



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


   tag can be calculated for the key in question and then only CERT RRs
   with the same key tag need be examined.  However, the key must always
   be transformed to the format it would have as the public key portion
   of a DNSKEY RR before the key tag is computed.  This is only possible
   if the key is applicable to an algorithm (and limits such as key size
   limits) defined for DNS security.  If it is not, the algorithm field
   MUST BE zero and the tag field is meaningless and SHOULD BE zero.

   The algorithm field has the same meaning as the algorithm field in
   DNSKEY and RRSIG RRs [10], except that a zero algorithm field
   indicates the algorithm is unknown to a secure DNS, which may simply
   be the result of the algorithm not having been standardized for
   DNSSEC.

2.1.  Certificate Type Values

   The following values are defined or reserved:

       Value  Mnemonic  Certificate Type
       -----  --------  ----------------
           0            reserved
           1  PKIX      X.509 as per PKIX
           2  SPKI      SPKI certificate
           3  PGP       OpenPGP packet
           4  IPKIX     The URL of an X.509 data object
           5  ISPKI     The URL of an SPKI certificate
           6  IPGP      The URL of an OpenPGP packet
       7-252            available for IANA assignment
         253  URI       URI private
         254  OID       OID private
   255-65534            available for IANA assignment
       65535            reserved

   The PKIX type is reserved to indicate an X.509 certificate conforming
   to the profile being defined by the IETF PKIX working group.  The
   certificate section will start with a one-byte unsigned OID length
   and then an X.500 OID indicating the nature of the remainder of the
   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
   not include their X.500 directory type designating OID as a prefix.)

   The SPKI type is reserved to indicate the SPKI certificate format
   [13], for use when the SPKI documents are moved from experimental
   status.

   The PGP type indicates an OpenPGP packet as described in [6] and its
   extensions and successors.  Two uses are to transfer public key
   material and revocation signatures.  The data is binary, and MUST NOT
   be encoded into an ASCII armor.  An implementation SHOULD process



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


   transferable public keys as described in section 10.1 of [6], but it
   MAY handle additional OpenPGP packets.

   The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
   content that would have been in the "certificate, CRL or URL" field
   of the corresponding (PKIX, SPKI or PGP) packet types.  These types
   are known as "indirect".  These packet types MUST be used when the
   content is too large to fit in the CERT RR, and MAY be used at the
   implementer's discretion.  They SHOULD NOT be used where the entire
   UDP packet would have fit in 512 bytes.

   The URI private type indicates a certificate format defined by an
   absolute URI.  The certificate portion of the CERT RR MUST begin with
   a null terminated URI [5] and the data after the null is the private
   format certificate itself.  The URI SHOULD be such that a retrieval
   from it will lead to documentation on the format of the certificate.
   Recognition of private certificate types need not be based on URI
   equality but can use various forms of pattern matching so that, for
   example, subtype or version information can also be encoded into the
   URI.

   The OID private type indicates a private format certificate specified
   by an ISO OID prefix.  The certificate section will start with a one-
   byte unsigned OID length and then a BER encoded OID indicating the
   nature of the remainder of the certificate section.  This can be an
   X.509 certificate format or some other format.  X.509 certificates
   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
   type, not the OID private type.  Recognition of private certificate
   types need not be based on OID equality but can use various forms of
   pattern matching such as OID prefix.

2.2.  Text Representation of CERT RRs

   The RDATA portion of a CERT RR has the type field as an unsigned
   decimal integer or as a mnemonic symbol as listed in section 2.1
   above.

   The key tag field is represented as an unsigned decimal integer.

   The algorithm field is represented as an unsigned decimal integer or
   a mnemonic symbol as listed in [10].

   The certificate / CRL portion is represented in base 64 [14] and may
   be divided up into any number of white space separated substrings,
   down to single base 64 digits, which are concatenated to obtain the
   full signature.  These substrings can span lines using the standard
   parenthesis.




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