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

Versions: 00 01 02

INTERNET DRAFT                                            Thierry Moreau
Document: draft-moreau-dnsext-takrem-dns-01.txt                CONNOTECH
Category: Standards Track                                 December, 2005
Expires: June, 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 (2005).

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 additional security protocol elements to the
     DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034], [RFC4035]),
     in the area of DNSSEC key management support functions. It
     specifies an automated key rollover mechanism for trust anchor
     keys. This mechanism has implications on the trust anchor key
     generation procedures, because it is an integrated scheme that
     supports the security of trust anchor signature key pairs used in
     consecutive cryptoperiods.

Moreau                      Standards Track                    [page 1]

Internet-Draft               TAKREM-DNSSEC               December, 2005

Table of Contents

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

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

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

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

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

6. Security Considerations  . . . . . . . . . . . . . . . . . . . . . 11

7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . . 11

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

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

Normative References  . . . . . . . . . . . . . . . . . . . . . . . . 15

Informative References  . . . . . . . . . . . . . . . . . . . . . . . 15

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

Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . . 16

IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     Intellectual Property  . . . . . . . . . . . . . . . . . . . . . 16
     Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 16
     Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Moreau                      Standards Track                    [page 2]

Internet-Draft               TAKREM-DNSSEC               December, 2005

1. Introduction

     The DNS security protocols ([RFC4033], [RFC4034], and [RFC4035])
     are intended to provide DNS data assurance using public key
     cryptography digital signatures that are chained so that the
     assurance about an unknown signature is traced to a higher
     assurance signature. Inescapably, the chain terminates with a last
     digital signature, using a root public key, also called a trust
     anchor key. The present document addresses trust anchor key
     distribution issues, and provides an automated rollover mechanism
     for trust anchor keys.

     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. It will apply to the root zone if and when it
     becomes DNSSEC-aware, and to any "islands of trust" in the

     Trust anchor key management lies at a mating point between
     technology-intensive cryptographic security and labor-intensive
     security procedures (e.g. manual establishment of a trusted
     channel). The very notion of trust is not technological, i.e. it is
     a matter of belief that distinguishes a trusted root key from a
     plain public key record, and belief can not be represented as a
     computer-readable record. Digital signature merely translates trust
     in a key to trust in the signed data, logically and
     cryptologically. This justifies the present document to describe
     security procedures that are mostly internal to the organization
     behind a trust anchor key: these procedures, when properly
     effected, are the basis for trust.

1.1 Concepts

     For the purpose of the present document, it is useful to describe
     the DNSSEC hierarchical signature delegation scheme as a tree
     structure with four types of nodes:
       o  the root DNS zone,
       o  important DNS zones, i.e. zones controlled by organizations
          having sufficient interest in DNSSEC for to commit resources
          to manage the zone key with high operational security,
          including a wish that their zone KSK is distributed with high
       o  ordinary DNS zones, e.g. a zone controlled by managers who
          just need to keep the zone up and running,
       o  leaf nodes.
     Examples of important DNS zones would be governments and
     multinational corporations.

     The notion of "trust points" is different from "important zones". A
     trust point is any DNS zone that is secured but has an insecure
     parent. Direct trust anchor key distribution is a requirement for
     every trust point.

Moreau                      Standards Track                    [page 3]

Internet-Draft               TAKREM-DNSSEC               December, 2005

     The rationales for scheduled renewals of trust anchor keys
     ("cryptoperiod") are threefold:
       o  cryptographic strength concerns, i.e. an old key might be
       o  security operations concerns, i.e. over time, the
          uninterrupted confidentiality a production private key becomes
          less trustworthy,
       o  survivability concerns to the extent that a scheduled renewal
          operation is like a rehearsal for an emergency private key
          recovery, or an alternative for it (e.g. if the private key
          breach has no practical impact or it is merely suspected).
     Trust anchor key renewal is not motivated by the end-user
     responsibility in maintaining the configuration integrity. It
     remains a end-user system responsibility to store the properly
     distributed trust anchors differently from ordinary system data so
     that malicious system configuration is prevented.

1.2 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

     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 same type of formalism appears
     in section 5.3.2. in [RFC4035]).

     [[Editor's note: the reference [ISO10118-4] about the MASH
     cryptographic algorithm is not available on the web without
     payment. Maybe a MASH summary in an informative appendix C would
     reduce the annoyance for readers just interested in a general
     understanding of the MASH algorithm.]]

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

Moreau                      Standards Track                    [page 4]

Internet-Draft               TAKREM-DNSSEC               December, 2005

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 an augmented
     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#).

     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
     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 TAKERM proposal does not change this.
     However, the initial trust anchor configuration data is augmented
     with 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 a 4-tuple comprising:
       1) a domain name,
       2) an initial signature public key (appendix A notation #R[0]#),
       3) a series of cryptographic hash code values (appendix A
          notation #D[1], D[2], ..., D[n]#), and
       4) a 32-bit integer reference value #f#.

Moreau                      Standards Track                    [page 5]

Internet-Draft               TAKREM-DNSSEC               December, 2005

     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

     The DNSSEC document set has minimal provisions for trust anchor key
     rollover. Only two sentences address this issue in [RFC4035],
     section 4.4:
          Note that trust anchors also cover key material that is
          updated in a secure manner. This secure manner could be
          through physical media, a key exchange protocol, or some other
          out-of-band means.
     Moreover, the difference between a KSK and a ZSK is not formalized
     in the DNSSEC document set. For the present document, a trust
     anchor key MUST be a DNSKEY resource record with the SEP bit set,
     which is discussed in [RFC3757].

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

Moreau                      Standards Track                    [page 6]

Internet-Draft               TAKREM-DNSSEC               December, 2005

               2.2, in an SDDA resource record.
          The zone manager MUST include the new DNSKEY record and the
          SDDA record targeting it in the zone data at the same zone
          version update. The simultaneous publication of these two
          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 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 TAKREM
          initial 4-tuple configuration. This is specified in section 5.

     The items a) and b) in the first phase are essentially internal
     procedures of a zone manager. They support the remaining of the
     rollover procedure which has interoperability provisions.

3.1 Usage Scenarios

     The manager of a zone that is a trust point can use the present
     authentication scheme for trust anchor rollover, provided the
     initial trust anchor key distribution was done according to the
     above subsection 2.2.

     Once a trust point vanishes because the parent zone turns on DNSSEC
     delegations (i.e. DS records), the child zone may still use the
     present rollover scheme, e.g. if it is suspected that local
     policies in a set of resolvers put more weight on direct
     authentication by the child zone manager than the normal DS
     authentication by the parental zone manager.

     Likewise, the owner of an "important" zone having a DNSSEC-enabled
     parent may whish to use the TAKREM mechanism for a target resolver
     population. For instance, a financial institution might whish to
     offer the TAKREM enhanced authentication strength to its on-line
     banking users by fear of inadequate parent zone security practices.

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.

Moreau                      Standards Track                    [page 7]

Internet-Draft               TAKREM-DNSSEC               December, 2005

     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 4.3 of [SDDA-RR]. The SDDA RRset
     signature provisions in [SDDA-RR] mandate the signature of SDDA
     contents using the targeted DNSKEY public key, providing origin
     authentication for the announced DNSKEY cryptoperiod.

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.4) must contain 1 for the present document to apply.

     The SDDA RR Authentication Context Type field ([SDDA-RR] section
     2.2.5) 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 readily 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 because the NAME
          and the Algorithm fields in the SDDA RR should identify the
          relevant initial trust anchor configuration for which a
          renewal operation is authenticated by the SDDA RR (e.g. if
          indexing techniques are used to search the candidates digests
       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                      Standards Track                    [page 8]

Internet-Draft               TAKREM-DNSSEC               December, 2005

     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].
     Accordingly, the SDDA RR must contain no Authentication Algorithm
     Type Extension field ([SDDA-RR] section 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. That is, 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.

     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.

5. Resolver Procedures for Trust Anchor Key Rollover

     This section applies to a resolver supporting the present
     specification, provided it is configured with at least one series
     of cryptographic hash code values associated with a domain name.
     When such a resolver encounters a DNSSEC record with the SEP bit
     set and for a domain name having a series of hash codes, it MAY use
     the procedure in this section to authenticate the unknown signature
     public key as an authentic trust anchor. A resolver might encounter
     such a DNSSEC record either as additional DNS data in a response
     per [RFC4035] section 3.1.2, or as normal answer data after an
     explicit query for the DNSKEY RRset at the zone apex.

     The resolver having detected a new DNSKEY record for a domain name
     having a 4-tuple configuration should query the name server for the
     SDDA RRset for the domain name.

     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 a identical digest value #D[i]# among the initial 4-
     tuple configurations that the resolver may have accepted as part of
     trusted configuration.

     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

Moreau                      Standards Track                    [page 9]

Internet-Draft               TAKREM-DNSSEC               December, 2005

     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,
       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 Authentication 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 initial
          4-tuple 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 4-tuple 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 deny any trust
     anchor status to the DNSKEY record.

     As a precaution against the replay of an old trust anchor key, a
     resolver should remember the DNSKEY expiration time (from the SDDA
     RR contents) when it is first authenticated with the above
     procedure, and abstain from re-entrusting the same key after this
     expiration time.

6. Security Considerations

     The present document provides a partial solution to the emergency
     trust anchor key rollover requirement because no mechanism is
     provided to force the revocation of a breached key.

     The TAKREM security effectiveness rests more on end-to-end
     cryptographic properties than on particulars of DNS protocol
     operations. 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

     See the reference [SDDA-RR]. The present document creates no
     additional IANA considerations.

Moreau                      Standards Track                   [page 10]

Internet-Draft               TAKREM-DNSSEC               December, 2005

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

     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.

     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                      Standards Track                   [page 11]

Internet-Draft               TAKREM-DNSSEC               December, 2005

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 verification processing design is based on the
     X.509 public key encoding standard that is expected to lead the DNS
     use of the underlying signature algorithm. In addition to providing
     an unambiguous canonical encoding, this approach supports the
     inclusion of new digital signature algorithms in the initial
     4-tuple configuration.

     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                      Standards Track                   [page 12]

Internet-Draft               TAKREM-DNSSEC               December, 2005

     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                      Standards Track                   [page 13]

Internet-Draft               TAKREM-DNSSEC               December, 2005

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

[RFC3757] O. Kolkman, J. Schlyter, E. Lewis, "Domain Name System KEY
          (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
          RFC 3757, April 2004

[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-01.txt, December 2005

Informative References

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

Document Revision History

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

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

Moreau                      Standards Track                   [page 14]

Internet-Draft               TAKREM-DNSSEC               December, 2005

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

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

Copyright Notice

     Copyright (C) The Internet Society (2005).

     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.

Moreau                      Standards Track                   [page 15]

Internet-Draft               TAKREM-DNSSEC               December, 2005


     This document and the information contained herein are provided on

Moreau                      Standards Track                   [page 16]

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