rfc2065.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Eastlake & Kaufman          Standards Track                    [Page 16]

RFC 2065                DNS Security Extensions             January 1997


4.1 SIG RDATA Format

   The RDATA portion of a SIG RR is as shown below.  The integrity of
   the RDATA information is protected by the signature field.

                        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 covered           |  algorithm    |     labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      signature expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         time signed                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         key footprint         |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         signer's name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   +-                          signature                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value of the SIG RR type is 24.

   The "type covered" is the type of the other RRs covered by this SIG.

   The algorithm number is an octet specifying the digital signature
   algorithm used parallel to the algorithm octet for the KEY RR.  The
   MD5/RSA algorithm described in this document is number 1.  Numbers 2
   through 252 are available for assignment should sufficient reason
   arise to allocate them.  However, the designation of a new algorithm
   could have a major impact on the interoperability of the global DNS
   system and requires an IETF standards action.  Number 254 is reserved
   for private use and will not be assigned a specific algorithm.  For
   number 254, the "signature" area shown above will actually begin with
   a length byte followed by an Object Identifier (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.  Number 253,
   known as the "expiration date algorithm", is used when the expiration
   date or other non-signature fields of the SIG are desired without any
   actual security.  It is anticipated that this algorithm will only be
   used in connection with some modes of DNS dynamic update.  For number
   253, the signature field will be null.  Values 0 and 255 are
   reserved.




Eastlake & Kaufman          Standards Track                    [Page 17]

RFC 2065                DNS Security Extensions             January 1997


   The "labels" octet is an unsigned count of how many labels there are
   in the original SIG RR owner name not counting the null label for
   root and not counting any initial "*" for a wildcard.  If a secured
   retrieval is the result of wild card substitution, it is necessary
   for the resolver to use the original form of the name in verifying
   the digital signature.  This field helps optimize the determination
   of the original form thus reducing the effort in authenticating
   signed data.

   If, on retrieval, the RR appears to have a longer name than indicated
   by "labels", the resolver can tell it is the result of wildcard
   substitution.  If the RR owner name appears to be shorter than the
   labels count, the SIG RR must be considered corrupt and ignored.  The
   maximum number of labels allowed in the current DNS is 127 but the
   entire octet is reserved and would be required should DNS names ever
   be expanded to 255 labels.  The following table gives some examples.
   The value of "labels" is at the top, the retrieved owner name on the
   left, and the table entry is the name to use in signature
   verification except that "bad" means the RR is corrupt.

        labels= |  0  |   1  |    2   |      3   |      4   |
        --------+-----+------+--------+----------+----------+
               .|   . | bad  |  bad   |    bad   |    bad   |
              d.|  *. |   d. |  bad   |    bad   |    bad   |
            c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
          b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
        a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |

   The "original TTL" field is included in the RDATA portion to avoid
   (1) authentication problems that caching servers would otherwise
   cause by decrementing the real TTL field and (2) security problems
   that unscrupulous servers could otherwise cause by manipulating the
   real TTL field.  This original TTL is protected by the signature
   while the current TTL field is not.

   NOTE:  The "original TTL" must be restored into the covered RRs when
   the signature is verified.  This implies that all RRs for a
   particular type, name, and class must have the same TTL to start
   with.

   The SIG is valid until the "signature expiration" time which is an
   unsigned number of seconds since the start of 1 January 1970, GMT,
   ignoring leap seconds.  (See also Section 4.4.)  SIG RRs should not
   have a date signed significantly in the future.  To prevent
   misordering of network requests to update a zone dynamically,
   monotonically increasing "time signed" dates may be necessary.





Eastlake & Kaufman          Standards Track                    [Page 18]

RFC 2065                DNS Security Extensions             January 1997


   The "time signed" field is an unsigned number of seconds since the
   start of 1 January 1970, GMT, ignoring leap seconds.

   A SIG RR with an expiration date before the time signed must be
   considered corrupt and ignored.

   The "key footprint" is a 16 bit quantity that is used to help
   efficiently select between multiple keys which may be applicable and
   as a quick check that a public key about to be used for the
   computationally expensive effort to check the signature is possibly
   valid.  Its exact meaning is algorithm dependent.  For the MD5/RSA
   algorithm, it is the next to the bottom two octets of the public key
   modulus needed to decode the signature field.  That is to say, the
   most significant 16 of the lest significant 24 bits of the modulus in
   network order.

   The "signer's name" field is the domain name of the signer generating
   the SIG RR.  This is the owner of the public KEY RR that can be used
   to verify the signature.  It is frequently the zone which contained
   the RR(s) being authenticated.  The signer's name may be compressed
   with standard DNS name compression when being transmitted over the
   network.

   The structure of the "signature" field is described below.

4.1.1 Signature Data

   Except for algorithm number 253 where it is null, the actual
   signature portion of the SIG RR binds the other RDATA fields to all
   of the "type covered" RRs with that owner name and class.  These
   covered RRs are thereby authenticated.  To accomplish this, a data
   sequence is constructed as follows:

           data = RDATA | RR(s)...

   where "|" is concatenation, RDATA is all the RDATA fields in the SIG
   RR itself before and not including the signature, and RR(s) are all
   the RR(s) of the type covered with the same owner name and class as
   the SIG RR in canonical form and order.  How this data sequence is
   processed into the signature is algorithm dependent.

   For purposes of DNS security, the canonical form for an RR is the RR
   with domain names (1) fully expanded (no name compression via
   pointers), (2) all domain name letters set to lower case, and (3) the
   original TTL substituted for the current TTL.






Eastlake & Kaufman          Standards Track                    [Page 19]

RFC 2065                DNS Security Extensions             January 1997


   For purposes of DNS security, the canonical order for RRs is to sort
   them in ascending order by name, considering labels as a left
   justified unsigned octet sequence in network (transmission) order
   where a missing octet sorts before a zero octet.  (See also ordering
   discussion in Section 5.1.)  Within any particular name they are
   similarly sorted by type and then RDATA as a left justified unsigned
   octet sequence. EXCEPT that the type SIG RR(s) covering any
   particular type appear immediately after the other RRs of that type.
   (This special consideration for SIG RR(s) in ordering really only
   applies to calculating the AXFR SIG RR as explained in section 4.1.3
   below.)  Thus if at name a.b there are two A RRs and one KEY RR,
   their order with SIGs for concatenating the "data" to be signed would
   be as follows:

           a.b.  A ....
           a.b.  A ....
           a.b.  SIG A ...
           a.b.  KEY ...
           a.b.  SIG KEY ...

   SIGs covering type ANY should not be included in a zone.

4.1.2 MD5/RSA Algorithm Signature Calculation

   For the MD5/RSA algorithm, the signature is as follows

      hash = MD5 ( data )

      signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)

   where MD5 is the message digest algorithm documented in RFC 1321, "|"
   is concatenation, "e" is the private key exponent of the signer, and
   "n" is the modulus of the signer's public key.  01, FF, and 00 are
   fixed octets of the corresponding hexadecimal value. "prefix" is the
   ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, that
   is,
           hex 3020300c06082a864886f70d020505000410 [NETSEC].
   This prefix is included to make it easier to use RSAREF or similar
   packages.  The FF octet is repeated the maximum number of times such
   that the value of the quantity being exponentiated is one octet
   shorter than the value of n.

   (The above specifications are identical to the corresponding part of
   Public Key Cryptographic Standard #1 [PKCS1].)







Eastlake & Kaufman          Standards Track                    [Page 20]

RFC 2065                DNS Security Extensions             January 1997


   The size of n, including most and least significant bits (which will
   be 1) SHALL be not less than 512 bits and not more than 2552 bits.  n
   and e SHOULD be chosen such that the public exponent is small.

   Leading zeros bytes are not permitted in the MD5/RSA algorithm
   signature.

   A public exponent of 3 minimizes the effort needed to decode a
   signature.  Use of 3 as the public exponent may be weak for
   confidentiality uses since, if the same data can be collected
   encrypted under three different keys with an exponent of 3 then,
   using the Chinese Remainder Theorem, the original plain text can be
   easily recovered.  This weakness is not significant for DNS because
   we seek only authentication, not confidentiality.

4.1.3 Zone Transfer (AXFR) SIG

   The above SIG mechanisms assure the authentication of all zone signed
   RRs of a particular name, class and type.  However, to efficiently
   assure the completeness and security of zone transfers, a SIG RR
   owned by the zone name must be created with a type covered of AXFR
   that covers all zone signed RRs in the zone and their zone SIGs but
   not the SIG AXFR itself.  The RRs are ordered and concatenated for
   hashing as described in Section 4.1.1.  (See also ordering discussion
   in Section 5.1.)

   The AXFR SIG must be calculated last of all zone key signed SIGs in
   the zone.  In effect, when signing the zone, you order, as described
   above, all RRs to be signed by the zone, and all associated glue RRs
   and delegation point NS RRs.  You can then make one pass inserting
   all the zone SIGs.  As you proceed you hash RRs to be signed into
   both an RRset hash and the zone hash.  When the name or type changes
   you calculate and insert the RRset zone SIG, clear the RRset hash,
   and hash that SIG into the zone hash (note that glue RRs and
   delegation point NSs are not zone signed but zone apex NSs are).
   When you have finished processing all the starting RRs as described
   above, you can then use the cumulative zone hash RR to calculate and
   insert an AXFR SIG covering the zone.  Of course any computational
   technique producing the same results as above is permitted.

   The AXFR SIG really belongs to the zone as a whole, not to the zone
   name.  Although it should be correct for the zone name, the labels
   field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only
   retrieved as part of a zone transfer.  After validation of the AXFR
   SIG, the zone MAY be considered valid without verification of the
   internal zone signed SIGs in the zone; however, any RRs authenticated
   by SIGs signed by entity keys or the like MUST still be validated.
   The AXFR SIG SHOULD be transmitted first in a zone transfer so the



Eastlake & Kaufman          Standards Track                    [Page 21]

RFC 2065                DNS Security Extensions             January 1997