blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
4.1 SIG RDATA Format Connected: An Internet Encyclopedia
4.1 SIG RDATA Format

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2065
Up: 4. The SIG Resource Record
Prev: 4. The SIG Resource Record
Next: 4.1.1 Signature Data

4.1 SIG RDATA Format

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.

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.

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.


Next: 4.1.1 Signature Data

Connected: An Internet Encyclopedia
4.1 SIG RDATA Format

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609