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. 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 (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. Abstract 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 meantime. 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 assurance, 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 cracked, 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 ##), 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 ## 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 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 ## 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 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 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 validation. 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 #D[i]#). 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 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]. Accordingly, the SDDA RR must contain no Authentication Algorithm Type Extension field ([SDDA-RR] section 2.2.10.2). 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.3) 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 ##, ##, ##, ..., ##, 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#. 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. 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 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: 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 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 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 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 arithmetic" [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, http://www.connotech.com/takrem.pdf 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 [SDDA-RR]. 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 ietf-ipr@ietf.org. 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 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 Standards Track [page 16]