rfc2535.txt

RFC 的详细文档！

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                          public key                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

   The KEY RR is not intended for storage of certificates and a separate
   certificate RR has been developed for that purpose, defined in [RFC
   2538].

   The meaning of the KEY RR owner name, flags, and protocol octet are
   described in Sections 3.1.1 through 3.1.5 below.  The flags and
   algorithm must be examined before any data following the algorithm
   octet as they control the existence and format of any following data.
   The algorithm and public key fields are described in Section 3.2.
   The format of the public key is algorithm dependent.

   KEY RRs do not specify their validity period but their authenticating
   SIG RR(s) do as described in Section 4 below.

3.1.1 Object Types, DNS Names, and Keys

   The public key in a KEY RR is for the object named in the owner name.

   A DNS name may refer to three different categories of things.  For
   example, foo.host.example could be (1) a zone, (2) a host or other
   end entity , or (3) the mapping into a DNS name of the user or
   account [e-mail].  Thus, there are flag bits, as described
   below, in the KEY RR to indicate with which of these roles the owner
   name and public key are associated.  Note that an appropriate zone
   KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
   occur only at delegation points.

3.1.2 The KEY RR Flag Field

   In the "flags" field:

     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |  A/C  | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z |      SIG      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Bit 0 and 1 are the key "type" bits whose values have the following
   meanings:



Eastlake                    Standards Track                    [Page 11]

RFC 2535                DNS Security Extensions               March 1999


           10: Use of the key is prohibited for authentication.
           01: Use of the key is prohibited for confidentiality.
           00: Use of the key for authentication and/or confidentiality
               is permitted. Note that DNS security makes use of keys
               for authentication only. Confidentiality use flagging is
               provided for use of keys in other protocols.
               Implementations not intended to support key distribution
               for confidentiality MAY require that the confidentiality
               use prohibited bit be on for keys they serve.
           11: If both bits are one, the "no key" value, there is no key
               information and the RR stops after the algorithm octet.
               By the use of this "no key" value, a signed KEY RR can
               authenticatably assert that, for example, a zone is not
               secured.  See section 3.4 below.

   Bits 2 is reserved and must be zero.

   Bits 3 is reserved as a flag extension bit.  If it is a one, a second
          16 bit flag field is added after the algorithm octet and
          before the key data.  This bit MUST NOT be set unless one or
          more such additional bits have been defined and are non-zero.

   Bits 4-5 are reserved and must be zero.

   Bits 6 and 7 form a field that encodes the name type. Field values
   have the following meanings:

           00: indicates that this is a key associated with a "user" or
               "account" at an end entity, usually a host.  The coding
               of the owner name is that used for the responsible
               individual mailbox in the SOA and RP RRs: The owner name
               is the user name as the name of a node under the entity
               name.  For example, "j_random_user" on
               host.subdomain.example could have a public key associated
               through a KEY RR with name
               j_random_user.host.subdomain.example.  It could be used
               in a security protocol where authentication of a user was
               desired.  This key might be useful in IP or other
               security for a user level service such a telnet, ftp,
               rlogin, etc.
           01: indicates that this is a zone key for the zone whose name
               is the KEY RR owner name.  This is the public key used
               for the primary DNS security feature of data origin
               authentication.  Zone KEY RRs occur only at delegation
               points.
           10: indicates that this is a key associated with the non-zone
               "entity" whose name is the RR owner name.  This will
               commonly be a host but could, in some parts of the DNS



Eastlake                    Standards Track                    [Page 12]

RFC 2535                DNS Security Extensions               March 1999


               tree, be some other type of entity such as a telephone
               number [RFC 1530] or numeric IP address.  This is the
               public key used in connection with DNS request and
               transaction authentication services.  It could also be
               used in an IP-security protocol where authentication at
               the host, rather than user, level was desired, such as
               routing, NTP, etc.
           11: reserved.

   Bits 8-11 are reserved and must be zero.

   Bits 12-15 are the "signatory" field.  If non-zero, they indicate
              that the key can validly sign things as specified in DNS
              dynamic update [RFC 2137].  Note that zone keys (see bits
              6 and 7 above) always have authority to sign any RRs in
              the zone regardless of the value of the signatory field.

3.1.3 The Protocol Octet

   It is anticipated that keys stored in DNS will be used in conjunction
   with a variety of Internet protocols.  It is intended that the
   protocol octet and possibly some of the currently unused (must be
   zero) bits in the KEY RR flags as specified in the future will be
   used to indicate a key's validity for different protocols.

   The following values of the Protocol Octet are reserved as indicated:

        VALUE   Protocol

          0      -reserved
          1     TLS
          2     email
          3     dnssec
          4     IPSEC
         5-254   - available for assignment by IANA
        255     All

   In more detail:
        1 is reserved for use in connection with TLS.
        2 is reserved for use in connection with email.
        3 is used for DNS security.  The protocol field SHOULD be set to
          this value for zone keys and other keys used in DNS security.
          Implementations that can determine that a key is a DNS
          security key by the fact that flags label it a zone key or the
          signatory flag field is non-zero are NOT REQUIRED to check the
          protocol field.
        4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
          and indicates that this key is valid for use in conjunction



Eastlake                    Standards Track                    [Page 13]

RFC 2535                DNS Security Extensions               March 1999


          with that security standard.  This key could be used in
          connection with secured communication on behalf of an end
          entity or user whose name is the owner name of the KEY RR if
          the entity or user flag bits are set.  The presence of a KEY
          resource with this protocol value is an assertion that the
          host speaks Oakley/IPSEC.
        255 indicates that the key can be used in connection with any
          protocol for which KEY RR protocol octet values have been
          defined.  The use of this value is discouraged and the use of
          different keys for different protocols is encouraged.

3.2 The KEY Algorithm Number Specification

   This octet is the key algorithm parallel to the same field for the
   SIG resource as described in Section 4.1.  The following values are
   assigned:

   VALUE   Algorithm

     0      - reserved, see Section 11
     1     RSA/MD5 [RFC 2537] - recommended
     2     Diffie-Hellman [RFC 2539] - optional, key only
     3     DSA [RFC 2536] - MANDATORY
     4     reserved for elliptic curve crypto
   5-251    - available, see Section 11
   252     reserved for indirect keys
   253     private - domain name (see below)
   254     private - OID (see below)
   255      - reserved, see Section 11

   Algorithm specific formats and procedures are given in separate
   documents.  The mandatory to implement for interoperability algorithm
   is number 3, DSA.  It is recommended that the RSA/MD5 algorithm,
   number 1, also be implemented.  Algorithm 2 is used to indicate
   Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.

   Algorithm number 252 indicates an indirect key format where the
   actual key material is elsewhere.  This format is to be defined in a
   separate document.

   Algorithm numbers 253 and 254 are reserved for private use and will
   never be assigned a specific algorithm.  For number 253, the public
   key area and the signature begin with a wire encoded domain name.
   Only local domain name compression is permitted.  The domain name
   indicates the private algorithm to use and the remainder of the
   public key area is whatever is required by that algorithm.  For
   number 254, the public key area for the KEY RR and the signature
   begin with an unsigned length byte followed by a BER encoded Object



Eastlake                    Standards Track                    [Page 14]

RFC 2535                DNS Security Extensions               March 1999


   Identifier (ISO OID) of that length.  The OID indicates the private
   algorithm in use and the remainder of the area is whatever is
   required by that algorithm.  Entities should only use domain names
   and OIDs they control to designate their private algorithms.

   Values 0 and 255 are reserved but the value 0 is used in the
   algorithm field when that field is not used.  An example is in a KEY
   RR with the top two flag bits on, the "no-key" value, where no key is
   present.

3.3 Interaction of Flags, Algorithm, and Protocol Bytes

   Various combinations of the no-key type flags, algorithm byte,
   protocol byte, and any future assigned protocol indicating flags are
   possible.  The meaning of these combinations is indicated below:

   NK = no key type (flags bits 0 and 1 on)
   AL = algorithm byte
   PR = protocols indicated by protocol byte or future assigned flags

   x represents any valid non-zero value(s).

    AL  PR   NK  Meaning
     0   0   0   Illegal, claims key but has bad algorithm field.
     0   0   1   Specifies total lack of security for owner zone.
     0   x   0   Illegal, claims key but has bad algorithm field.
     0   x   1   Specified protocols unsecured, others may be secure.
     x   0   0   Gives key but no protocols to use it.
     x   0   1   Denies key for specific algorithm.
     x   x   0   Specifies key for protocols.
     x   x   1   Algorithm not understood for protocol.

3.4 Determination of Zone Secure/Unsecured Status

   A zone KEY RR with the "no-key" type field value (both key type flag
   bits 0 and 1 on) indicates that the zone named is unsecured while a
   zone KEY RR with a key present indicates that the zone named is
   secure.  The secured versus unsecured status of a zone may vary with
   different cryptographic algorithms.  Even for the same algorithm,
   conflicting zone KEY RRs may be present.

   Zone KEY RRs, like all RRs, are only trusted if they are
   authenticated by a SIG RR whose signer field is a signer for which
   the resolver has a public key they trust and where resolver policy
   permits that signer to sign for the KEY owner name.  Untrusted zone
   KEY RRs MUST be ignored in determining the security status of the
   zone.  However, there can be multiple sets of trusted zone KEY RRs
   for a zone with different algorithms, signers, etc.



Eastlake                    Standards Track                    [Page 15]

RFC 2535                DNS Security Extensions               March 1999


   For any particular algorithm, zones can be (1) secure, indicating
   that any retrieved RR must be authenticated by a SIG RR or it will be
   discarded as bogus, (2) unsecured, indicating that SIG RRs are not
   expected or required for RRs retrieved from the zone, or (3)
   experimentally secure, which indicates that SIG RRs might or might
   not be present but must be checked if found.  The status of a zone is
   determined as follows:

   1. If, for a zone and algorithm, every trusted zone KEY RR for the