[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02

INTERNET DRAFT                                            Thierry Moreau
Document: draft-moreau-dnsext-takrem-dns-02.txt                CONNOTECH
Category: Informational                                      April, 2006
Expires: October, 2006

                   The Trust Anchor Key Renewal Method
                 Applied to DNS Security (TAKREM-DNSSEC)

Status of this Memo

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

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

     Copyright (C) The Internet Society (2006).

IPR Disclosure Acknowledgment

     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.


     This document provides an authentication scheme based on the
     generic SDDA-RR mechanism (SEP DNSKEY Direct Authenticator DNS
     Resource Record). The result is an automated key rollover mechanism
     for trust anchor keys. This represents additional security protocol
     elements to the DNS Security Extensions (DNSSEC) in the area of key
     management support functions for the DNS root zone and islands of

Moreau                       Informational                     [page 1]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1 Document Organization  . . . . . . . . . . . . . . . . . . .  4

2. Initial Procedures for the Use of TAKREM in the DNSSEC . . . . . .  4
     2.1 Initial Generation of Trust Anchor Keys  . . . . . . . . . .  4
     2.2 Initial Trust Anchor Key Distribution  . . . . . . . . . . .  5

3. Trust Anchor Key Rollover Overview . . . . . . . . . . . . . . . .  5
     3.1 Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . .  6

4. Detailed Zone Management Processing for Trust Anchor Key Rollover   7
     4.1 Procedures . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2 Data Formats . . . . . . . . . . . . . . . . . . . . . . . .  7

5. Resolver Procedures for Trust Anchor Key Rollover  . . . . . . . .  8

6. Security Considerations  . . . . . . . . . . . . . . . . . . . . .  9

7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . .  9

Appendix A - Synopsis of the TAKREM Security Procedure  . . . . . . . 10

Appendix B - Hash Function Input Stream Details . . . . . . . . . . . 12

Normative References  . . . . . . . . . . . . . . . . . . . . . . . . 14

Informative References  . . . . . . . . . . . . . . . . . . . . . . . 14

Document Revision History . . . . . . . . . . . . . . . . . . . . . . 14
     From revision -01 to revision -02  . . . . . . . . . . . . . . . 15
     From revision -00 to revision -01  . . . . . . . . . . . . . . . 15

Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . . 15

IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     Intellectual Property  . . . . . . . . . . . . . . . . . . . . . 16
     Derivative Works Limitation  . . . . . . . . . . . . . . . . . . 16
     Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 16
     Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Moreau                       Informational                     [page 2]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

1. Introduction

     The DNS security protocol ([RFC4033], [RFC4034], and [RFC4035]) is
     intended to provide DNS data assurance using a "chain of trust"
     where the links are public key cryptography digital signatures, and
     with a "trust anchor" is tied to one end of the chain. A trust
     anchor is a public signature key associated with an "island of
     trust" or the DNS root. Trust anchor key rollover relates to the
     need to change the KSK (Key Singing Key) of a DNSSEC-aware DNS zone
     when the parent zone is DNSSEC-oblivious or absent (i.e.
     respectively an island of trust or the DNS root). The present
     document addresses trust anchor key distribution issues, and
     provides an automated rollover mechanism for trust anchor keys.

     The technological capability specified herein rests on four
       o  the DNS security protocol itself ([RFC4033], [RFC4034], and
       o  the operational guidelines for the DNS security protocol
       o  the SEP DNSKEY Direct Authenticator resource record (SDDA-RR)
          specification ([SDDA-RR]), and
       o  additional security principles and formal specifications
          related to cryptographic mechanisms, including references
          [ASN1-DER], [RFC2459], and [ISO10118-4].
     The present document makes contributions in two directions:
       o  a mix of formal protocol interoperability provisions and less
          formal operational guidelines, where the security foundation
          rests on proper performance of both, in contrast to the
          limited scope on-the-wire protocol compliance, and
       o  formal provisions for cryptographic processing, allowing the
          security-related computations to succeed in encoding trust
          information (by DNS zone managers) and validating compliant
          encoded trust information (in DNS resolvers).
     Strictly speaking, the present document contains no protocol
     provision impacting interoperability for DNS protocol entities not
     involved in the present automated trust anchor key rollover scheme.
     See also the reference [SDDA-RR], in which interoperability issues
     are addressed, e.g. between different trust anchor key management
     schemes based on the SDDA resource record.

     Otherwise, it would be a double-sided sword to use the [RFC2119]
     terminology to specify compliance in the present document. Doing so
     might allow an implementation to claim "compliance to a security
     standard for trust anchor key" while in fact the confidence in a
     trust anchor key will systematically depend on operational
     procedures. Moreover, trust anchor key rollover procedures are
     spread across the nameserver and resolver dichotomy, and the
     respective security principles should be analyzed in isolation.
     Accordingly, the present document writing style avoids specifying
     what actually allows a resolver to accept a trust anchor key, which
     is nonetheless the stated goal of an automated trust anchor key
     rollover scheme.

Moreau                       Informational                     [page 3]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

1.1 Document Organization

     The normative appendix A specifies the TAKREM security procedure,
     which is the security foundation for the present document. The
     adaptation to the DNSSEC trust anchor rollover operation is covered
     in the main part of the document.

     The TAKREM procedure requires adaptations to the generation of an
     initial trust anchor key, which is covered in section 2 in the case
     of DNSSEC. These key generation provisions define some trust anchor
     key initialization (TAK-i) data to be configured in DNS resolvers
     as a preliminary, out-of-band procedure.

     The rollover operation itself is first described in section 3.

     The TAKREM procedure implies the publication of a "TAKREM rollover
     message," which turns into inserting specialized DNS resource
     records as explained in section 4.

     The rollover operation is completed with the relying party
     validation of the TAKREM rollover message, which turns into DNS
     resolver provisions in section 5.

     Unambiguous input format specification is critical to
     interoperability of cryptographic integrity mechanisms. The
     normative appendix B specifies the required unambiguous input
     format for the TAKREM procedure. The type of specifications in
     appendix B occurs in section 5.3.2. in [RFC4035], in this case for
     unambiguous input to a digital signature algorithm in the DNSSEC
     protocol itself.

2. Initial Procedures for the Use of TAKREM in the DNSSEC

2.1 Initial Generation of Trust Anchor Keys

     The secure generation of signature key pairs by zone managers is an
     implicit procedural requirement for support of the DNSSEC
     specifications. While the original DNSSEC requires a single
     signature key pair to be generated (appendix A notation
     "<r[0],R[0]>"), the present document assumes that a different
     procedure is being followed. Specifically, the TAKREM procedure
     requires the initial generation of a series of future signature key
     pairs (appendix A notation "<r[i],R[i]>" for "0<i<=n"), and the
     computation of a series of cryptographic hash code values (appendix
     A notation "D[i]" for "0<i<=n"). This computation uses the hash
     function input syntax specification in appendix B.

     The number of future key pairs (appendix A notation "n") should
     accommodate the expected lifetime of the DNSSEC service for the
     domain, and the trust anchor cryptoperiod policy: it might be in
     the order of tens or hundreds.

     The zone manager should safeguard the relevant data independently

Moreau                       Informational                     [page 4]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

     for each future signature key pair (appendix A notation
     "<r[i],R[i],N[i],p[i],s[i]>"). Bar code printouts in tamper-evident
     sealed envelopes appears as a suitable storage media for storage of
     individual key pairs in separate components. The term "dead
     storage" applies to this storage type because the cryptographic key
     material is remote from any live digital computing device.

2.2 Initial Trust Anchor Key Distribution

     With the original DNSSEC, the signature public key (appendix A
     notation "R[0]") is initially distributed with the domain name as
     the initial trust anchor key, and the signature private key
     (appendix A notation "r[0]") is put into production (e.g. to sign
     ZSK DNSKEY resource records).

     Initial trust anchor distribution mechanisms are outside of the
     DNSSEC specifications. The TAKREM proposal does not change this.
     However, the initial trust anchor configuration data (appendix A
     notation "R[0]") is replaced by an integer reference number "f" and
     the series of cryptographic hash code values. The integer reference
     number "f" is a 32-bit value. For a given domain name, the integer
     value range from "f+1" to "f+n" should not be re-used by another
     initial trust anchor configuration.

     In summary, in a resolver the initial trust anchor configuration is
     received as TAK-i data comprising, for each domain name subject to
     the present automated rollover scheme:
       1) the domain name,
       2) a series of cryptographic hash code values (appendix A
          notation "D[1], D[2], ..., D[n]"), and
       3) a 32-bit integer reference value "f".
     No special attention is paid to the hash code values and the
     reference at this initial configuration time: they are simply kept
     for later reference. At a later time, the resolver is able to
     support the automated trust anchor key rollover procedure specified
     in the following document section.

3. Trust Anchor Key Rollover Overview

     For trust anchor key rollover, the present document specifies that
     the new signature key pair (appendix A notation "<r[i],R[i]>" for
     some "i" in the range "0<i<=n") is not to be generated, but rather
     retrieved from the storage of future keys initially generated per
     above subsection 2.1 for the same domain name. This rule is not
     enforced by cryptographic means, but if the new key has a different
     domain name, it can not be authenticated with the present scheme.

     In addition to the retrieval of the next digital signature key pair
     from secure storage, the TAKREM basic procedure mandates the
     publication of a rollover message, which for DNSSEC purposes turns
     into the simultaneous publication of an SDDA resource record with
     the DNSKEY record. The generic format for the SDDA record is
     specified in [SDDA-RR] and its application to TAKREM is specified

Moreau                       Informational                     [page 5]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

     in the present document section 4. An SDDA records "targets" a
     DNSKEY record, alike a parental DS record.

     Accordingly, the DNS trust anchor rollover (augmented with TAKREM)
     can be described as a three phase procedure.

       o  In the first phase, the zone manager retrieves the relevant
          data for the future signature key pair (appendix A notation
          "<r[i],R[i],N[i],p[i],s[i]>") and sets
            a) the new signature private key (appendix A notation
               "r[i]") in the protected computing environment used for
               generating zone digital signatures,
            b) the new signature public key (appendix A notation "R[i]")
               in a DNSKEY resource record, and
            c) the key tag for the new signature public key and the
               other TAKREM rollover message elements (appendix A
               notation "<R[i],N[i],p[i],s[i]>"), plus the value "f+i",
               where "f" is the 32-bit reference described in the above
               subsection 2.2, in an SDDA resource record.
          The zone manager includes the new DNSKEY record and the SDDA
          record targeting it in the zone data at the same zone version
          update. Obituary SDDA RRs may be added to signal or confirm
          the expiry of a DNSKEY RR that is no longer present in the
          DNSKEY RRset, or should never be present (obituary SDDA RRs
          are defined in section 2.2.5 of [SDDA-RR]). Furthermore, the
          zone signing operation must include an RRSIG record targeting
          the SDDA RRset and using the new signature key. There are
          mandatory provisions in section 2.4 of [SDDA-RR] for the
          simultaneous publication of such DNSKEY, SDDA, and RRSIG
          records. The simultaneous publication of these records in a
          zone data completes the zone manager duties specific to a
          trust anchor key rollover operation according to the present
          authentication scheme.

       o  The second phase is the new KSK usage in DNS zone signing
          according to DNSSEC specifications. If the new DNSKEY record
          is to be authenticated also by a parental DS record, this
          second phase may be delayed until this DS record has been
          included in the parental zone.

       o  The third phase is run by resolvers having received the TAK-i
          data configuration for this domain name. This is specified in
          section 5.

3.1 Usage Scenarios

     The manager of an island of trust or the DNS root can use the
     present authentication scheme for trust anchor rollover, provided
     the TAK-i data distribution was done according to the above
     subsection 2.2.

     A normal secure child zone may also use the present rollover
     scheme, e.g. if it is suspected that some DNS resolver would not

Moreau                       Informational                     [page 6]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

     have a trust anchor for validating the parent zone signatures.

     In any case, only the DNS resolvers having been configured with the
     TAK-i data for a domain name can authenticate its trust anchor
     using the present authentication scheme.

4. Detailed Zone Management Processing for Trust Anchor Key Rollover

4.1 Procedures

     This section specifies how a zone manager creates at once the SDDA
     record and the targeted DNSKEY record for a trust anchor key
     rollover. The DNSKEY record must have both the "Zone Key" and
     "Secure Entry Point" flags set to 1. The lifetime of an SDDA record
     should be the same as the one in the targeted DNSKEY.

     The intended cryptoperiod for the DNSKEY signature public key
     should be reflected in the SDDA record field pair for
     Authentication Expiration and Authentication Inception.
     Specifically, after the earliest SDDA expiration time ever
     published for a given target DNSKEY signature public key, the zone
     manager must not reuse the same signature public key value again.
     Likewise, before the latest inception time ever published for a
     given target DNSKEY signature public key, the zone manager must not
     use the signature public key.

     The DNS publication of the DNSKEY and SDDA records create or
     augment corresponding RRsets. The RRSIG signatures for these DNSKEY
     and SDDA RRsets are specified respectively in section 2.2 of
     [RFC4035], and in section 2.4 of [SDDA-RR].

4.2 Data Formats

     This section specifies the TAKREM application of SDDA RR wire
     format and formation, using the notation from appendix A. The
     generic provisions of [SDDA-RR] apply to the SDDA record formation
     and the targeting to the appropriate DNSKEY record.

     The SDDA RR Authentication Mechanism Type field ([SDDA-RR] section
     2.2.3) must contain 1 for the present document to apply.

     The SDDA RR Authentication Context Type field ([SDDA-RR] section
     2.2.4) should be 2 or 0.
       o  When this field value is 2, the 32-bits opaque value in the
          Authentication Context Data field must hold the value "f+i".
          From the value "f+i", a resolver can efficiently identify a
          most probable candidate digest "D[i]" for TAKREM hash code
       o  When the Authentication Context Type field is 0, the SDDA RR
          Authentication Context Data field is absent.
       o  Other Authentication Context Type values may be used provided
          a prior arrangement allowing relying parties to identify the
          relevant initial trust anchor configuration.

Moreau                       Informational                     [page 7]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

     The SDDA RR must contain one set of Algorithm-Related fields
     ([SDDA-RR] section 2.2.10). For the Authentication Algorithm Type
     field ([SDDA-RR] section within this set, the currently
     allocated values are
       o  1: MASH-1 as defined in [ISO10118-4], and
       o  2: MASH-2 as defined in [ISO10118-4],
     encoded as a single octet binary field value.

     Two MASH parameters, respectively "N[i]", a large composite number
     of unknown factorization, and "p[i]", a large prime number,
     populate the Authentication Algorithm Common Parameters field
     ([SDDA-RR] section in the SDDA RR wire format. Each of
     "N[i]" and "p[i]" is encoded as a variable length unsigned integer
     prefixed by a length indication: the unsigned integer length in
     octets is represented as one octet if it is in the range of 1 to
     255 and by a zero octet followed by a two octet length if it is
     longer than 255 bytes. Leading zero bytes should be omitted from
     the unsigned integer representation.

     The SDDA RR Authentication Mechanism Data field ([SDDA-RR] section
     2.2.11) comprises a length indication as in the preceding paragraph
     holding the length (octet count) of the TAKREM rollover message
     salt field "s[i]", followed by an octet stream of this length,
     encoding this salt field in binary form. The encoded salt may
     contain leading zeroes.

5. Resolver Procedures for Trust Anchor Key Rollover

     The present authentication scheme uses the generic DNS rollover
     procedures specified in section 3 of reference [SDDA-RR]. The
     present document section provides the required details for a
     complete DNS resolver procedure specifications.

     A resolver may process an SDDA record by first matching the DNSKEY
     record pointed by the SDDA record, then reconstructing a TAKREM
     digest from the DNSKEY and SDDA record, and finally checking the
     presence of an identical digest value "D[i]" among the TAK-i data
     that the resolver may have accepted as part of trusted

     As can be inferred from other portions of this document, a resolver
     should validate the authenticity of a DNS resource record pair SDDA
     plus linked DNSKEY with the SDDA having an Authentication Mechanism
     Type set to 1 as if they provide a TAKREM rollover message. This
     validation is based on a number of data elements:
       o  the DNSKEY RR linked to the SDDA RR, providing the public key
          component "R[i]" of the TAKREM MASH input stream (in the case
          of an obituary SDDA RR, the DNSKEY value is taken from the DNS
          resolver state information),
       o  the field contents from the SDDA RR Authentication Mechanism
          Data field, providing the salt component "s[i]" of the TAKREM
          MASH input stream, and
       o  the two large integer values from the SDDA RR Authentication

Moreau                       Informational                     [page 8]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

          Algorithm Common Parameters field, providing the MASH
          parameters "N[i]" and "p[i]", thus revealing the specific MASH
          function used in the computation of the hash code outputs in
          the TAK-i data configuration,
     from which a TAKREM MASH input stream must be reconstructed
     according to appendix B, using values "s[i]", "R[i]", "N[i]",
     "p[i]". Then the resolver computes a TAKREM rollover message hash
     code according to the integer value from the Authentication
     Algorithm Type field (either 1 or 2), providing the selection among
     the MASH-1 and MASH-2 variants. Finally, the computed message hash
     code is checked for equality with any of the trusted digests "D[i]"
     from the initial TAK-i data configurations associated with the
     relevant domain name. If the SDDA RR Authentication Context Type
     field holds the value 2, the SDDA RR Authentication Context Data
     field provides a 32-bit reference value "f+i" that provides a hint
     for selecting a candidate digest "D[i]". If no matching trusted
     digests "D[i]" can be found, the resolver should abstain from
     granting a trust anchor status to the DNSKEY record (or an obituary
     SDDA RR should be considered bogus).

6. Security Considerations

     The TAKREM security effectiveness rests more on end-to-end
     cryptographic properties than on particulars of DNS protocol

     The malicious parties will typically attempt to circumvent the
     cryptographic computations, notably by exploiting mishaps in manual
     procedures (e.g. attempting to read a signature private key file)
     or in implementation weaknesses (e.g. inadequate integrity
     protection of resolver configuration).

7. IANA Considerations

     The present document provides a specification for the
     authentication scheme identified by the value "1" in the SDDA
     record Authentication Mechanism Type field. The SDDA record
     Authentication Mechanism Type name space is created in the
     reference [SDDA-RR], where the assigned value "1" registration is
     originally requested.

     There are no additional IANA considerations.

Moreau                       Informational                     [page 9]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

Appendix A - Synopsis of the TAKREM Security Procedure

     In this appendix, the TAKREM security procedure is described
     without reference to the DNS protocols. This appendix is normative.

     The purpose of any key management scheme is to preserve the
     cryptographic properties of algorithms. For TAKREM, this is further
     covered in reference [CONNOTECH].

     We use the notation "R[i]" for the public trust anchor key "R[i]",
     with the private key counterpart "r[i]".

     The zone owner establishes key pairs "<r[0],R[0]>", "<r[1],R[1]>",
     "<r[2],R[2]>", ..., "<r[n],R[n]>", allocating the pair
     "<r[0],R[0]>" as the initial trust anchor key pair, and reserving
     each key pairs "<r[i],R[i]>" for the cryptoperiod starting with the
     "i"'th trust anchor renewal, for "1<=i<=n".

     Actually, the initial key pair "<r[0],R[0]>" is not essential; the
     DNS resolver may bootstrap with the validation of the key pair
     "<r[1],R[1]>" using the normal TAKREM rollover validation
     procedure. The initial key pair "<r[0],R[0]>" is mentioned to
     relate the TAKREM description to the prior procedure of manual
     trust anchor key configuration.

     A separate MASH (Modular Arithmetic Secure Hash) instance "H[i]" is
     created for each "R[i]". MASH is defined in International standard
     document ISO/IEC 10118-4:1998 ([ISO10118-4]).

     That is, the zone owner selects a large composite modulus number
     "N[i]" used in the MASH round function and a prime number "p[i]"
     used in the MASH final reduction function.

     Then, the zone owner selects a random salt field "s[i]".

     A hash computation gives a root key digest "D[i]" :
          "D[i]=H[i](s[i]|R[i]|N[i]|P[i])" .
     The digest "D[i]" is like an advanced notice of future trust anchor
     key "R[i]".

     The data tuple "<r[i],R[i],N[i],p[i],s[i]>" is set aside in dead

     The trust anchor key initial distribution is
     "R[0], D[1], D[2], ..., D[n]" .

     Security rationale: with data tuple "<r[i],R[i],N[i],p[i],s[i]>"
     totally concealed until the usage period for key pair
     "<r[i],R[i]>", an adversary is left with the digest "D[i]" from
     which it is deemed impossible to mount a brute force attack.

Moreau                       Informational                    [page 10]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

     A trust anchor key rollover is triggered by a rollover message
     carrying the following information:
          "i,<R[i],N[i],p[i],s[i]>" .

     Upon receipt of this message, the DNS resolver becomes in a
     position to validate the trust anchor key digest "D[i]".

Moreau                       Informational                    [page 11]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

Appendix B - Hash Function Input Stream Details

     This appendix is normative.

     The TAKREM rollover message processing requires the unambiguous
     definition of a cryptographic hash function input stream in a
     format not necessarily typical of the DNS RR formatting rules. The
     input format is based on the ASN.1 distinguished encoring rules
     [ASN1-DER]. The input format is based on the X.509 public key
     encoding standard. In addition to providing an unambiguous
     canonical encoding, this approach supports the inclusion of new
     digital signature algorithms in the initial TAK-i data

     The TAKREM MASH input stream to be (re)constructed is the ASN.1 DER
     encoding for a value of the ASN.1 type defined as:

                         -- salt field "s[i]", SDDA RR
                         -- Authentication Mechanism Data field
     [1] IMPLICIT SEQUENCE { -- SubjectPublicKeyInfo "R[i]"
                             -- in RFC2459
          SEQUENCE { -- AlgorithmIdentifier in RFC2459
               algorithm OBJECT IDENTIFIER,
               parameters ANY DEFINED BY algorithm OPTIONAL
          subjectPublicKey BIT STRING
            -- public key encoded as a "subjectPublicKey"
            -- per RFC 2459, or per encoding rules for the
            -- subject public key algorithm
     INTEGER, -- the MASH parameter "N[i]"
     INTEGER  -- the MASH parameter "p[i]"

     In (re)constructing the MASH input stream, the ASN.1 encoding shall
     omit the optional fields that are "witness values" that allow
     verification of either number-theoretic properties intrinsic to the
     public key value, or the unbiased selection of random public key
     parameters (e.g. in [RC2459] for the Diffie-Hellman cryptosystem).
     Such fields may occur in the "parameters" ASN.1 field above, and/or
     in the "subjectPublicKey" ASN.1 field above

     Other optional fields should be provided in the ASN.1 encoding of a
     public key. Some optional fields are required for the complete
     knowledge of a public key value and must be retained (e.g. the
     three DSA common parameters are required even if they are encoded
     in an optional field of an ASN.1 sequence). In the case of RSA
     public keys, the X.509 mandates a NULL field in the
     AlgorithmIdentifier ASN.1 structure, which must be retained
     according to the present specification.

Moreau                       Informational                    [page 12]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

     In doing the above encoding conversion from the DNS encoding to
     ASN.1 encoding inspired from the X.509 specifications, the public
     key information is stripped of some usage control data. That is, a
     given type of public key might be allowable with a number of
     digital signature algorithms. The TAKREM mechanism specified in the
     body of this document protects the public key value with the type
     of public key, but not with a specific digital signature algorithm.
     Specifically, this allows RSA public keys to be used in the future
     with hash algorithms different from SHA-1, but also omit to protect
     against the use of weaker algorithms once stronger algorithms are

     The current digital signature algorithms allowed for DNS zone
     signing are limited to RSA and DSA, plus the unspecified private
     algorithms. For RSA (resp. DSA), the ASN.1 encoding specification
     is in section 7.3.1 (resp. 7.3.3) in [RFC2459]. For private
     algorithms, a similar public key encoding specification should be
     relied upon.

Moreau                       Informational                    [page 13]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

Normative References

[ASN1-DER]     International Standard ISO/IEC 8825-1, ITU-T
               Recommendation X.690, "Information technology   ASN.1
               encoding rules: Specification of Basic Encoding Rules
               (BER), Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER)", July 2002

[ISO10118-4]   International standard document ISO/IEC 10118-4:1998,
               "Information technology - Security techniques -
               Hash-functions - Part 4: Hash-functions using modular

[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public
          Key Infrastructure Certificate and CRL Profile", RFC 2459,
          January 1999

[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "DNS
          Security Introduction and Requirements", RFC 4033, March 2005

[RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose,
          "Resource Records for the DNS Security Extensions", RFC 4034,
          March 2005

[RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose,
          "Protocol Modifications for the DNS Security Extensions",
          RFC 4035, March 2005

[SDDA-RR] T. Moreau, "The SEP DNSKEY Direct Authenticator DNS Resource
          Record (SDDA-RR)", work-in-progress, Internet Draft
          draft-moreau-dnsext-sdda-rr-02.txt, April 2006

Informative References

[CONNOTECH]    Thierry Moreau, "A Note About Trust Anchor Key
               Distribution", CONNOTECH Experts-conseils inc., Document
               Number C003444, 2005/07/05,

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
          Levels", RFC2119, March 1997

[RFC2541bis]   O. Kolkman, R. Gieben, "DNSSEC Operational Practices",
               March 6, 2006, approved for RFC publication obsoleting

Document Revision History

     [[This document section to be removed upon RFC publication.]]

Moreau                       Informational                    [page 14]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

>From revision -01 to revision -02

     Major document editing with some technical changes and corrections,

       a) Document made informational instead of standard track, made
          explicit the non-use of RFC2119 keywords, and indicated the
          explicit avoidance of a basis for compliance statements (in
          revised introduction text).

       b) Moved some provisions about resolver process to the [SDDA-RR]

       c) Removed text that provided some design rationales.

       d) Removed the initial public key "R[0]" in the TAK-i
          configuration, avoiding a design bug, i.e. the lack of
          expiration time and obituary capability for public key "R[0]"
          (left public key "R[0]" in the text it as a tutorial

       e) Fixed a design bug with the introduction of the obituary SDDA,
          luckily with no impact on services provided by the TAKREM for
          DNSSEC scheme.

       f) The IANA considerations were stipulated as emty.

>From revision -00 to revision -01

       a) Changed the encoding for "N[i]", "p[i]", "s[i]" in section
          4.2, making it alike the RSA public key exponent encoding in
          DNSKEY RR.

       b) Alignments with the technical changes in the revision -01 of

       c) Minor editorial clarifications and corrections.

Author's Address

     Thierry Moreau
     CONNOTECH Experts-conseils inc.
     9130 Place de Montgolfier
     Montreal, Qc, Canada
     Tel.: +1-514-385-5691
     e-mail: thierry.moreau@connotech.com

Moreau                       Informational                    [page 15]

Internet-Draft               TAKREM-DNSSEC                  April, 2006

IPR Notices

Intellectual Property

     The IETF takes no position regarding the validity or scope of any
     Intellectual Property Rights or other rights that might be claimed
     to pertain to the implementation or use of the technology described
     in this document or the extent to which any license under such
     rights might or might not be available; nor does it represent that
     it has made any independent effort to identify any such rights.
     Information on the ISOC's procedures with respect to rights in ISOC
     Documents can be found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat and any
     assurances of licenses to be made available, or the result of an
     attempt made to obtain a general license or permission for the use
     of such proprietary rights by implementers or users of this
     specification can be obtained from the IETF on-line IPR repository
     at http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required to implement
     this standard. Please address the information to the IETF at

Derivative Works Limitation

     This document may not be modified, and derivative works of it may
     not be created, except to publish it as an RFC and to translate it
     into languages other than English.

Copyright Notice

     Copyright (C) The Internet Society (2006).

     This document is subject to the rights, licenses and restrictions
     contained in BCP 78, and except as set forth therein, the authors
     retain all their rights.


     This document and the information contained herein are provided on

Moreau                       Informational                    [page 16]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/