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. 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 progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. Abstract 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 trust. 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 foundations: o the DNS security protocol itself ([RFC4033], [RFC4034], and [RFC4035]), o the operational guidelines for the DNS security protocol ([RFC2541bis]), 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 ""), 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 "" for "0"). 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 "" for some "i" in the range "0") 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 ""), 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 validation. 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 2.2.10.1) 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 2.2.10.2) 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 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 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 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 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 "", "", "", ..., "", allocating the pair "" as the initial trust anchor key pair, and reserving each key pairs "" for the cryptoperiod starting with the "i"'th trust anchor renewal, for "1<=i<=n". Actually, the initial key pair "" is not essential; the DNS resolver may bootstrap with the validation of the key pair "" using the normal TAKREM rollover validation procedure. The initial key pair "" 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 "" is set aside in dead storage. The trust anchor key initial distribution is "R[0], D[1], D[2], ..., D[n]" . Security rationale: with data tuple "" totally concealed until the usage period for key pair "", 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," . 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 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: SEQUENCE { OCTET STRING SIZE(20..MAX), -- 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 deployed. 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 arithmetic" [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, http://www.connotech.com/takrem.pdf [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997 [RFC2541bis] O. Kolkman, R. Gieben, "DNSSEC Operational Practices", [[Internet-Draft draft-ietf-dnsop-dnssec-operational-practices-08.txt, March 6, 2006, approved for RFC publication obsoleting RFC2541]] 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, including: 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] document. 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 convenience). 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 [SDDA-RR]. 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 ietf-ipr@ietf.org. 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. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Moreau Informational [page 16]