INTERNET DRAFT Thierry Moreau Document: draft-moreau-dnsext-sdda-rr-01.txt CONNOTECH Category: Standards Track December, 2005 Expires: June, 2006 The SEP DNSKEY Direct Authenticator DNS Resource Record (SDDA-RR) 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 specifies a generic DNS resource record format for "direct authentication" of DSNKEY records with the SEP bit (Secure Entry Point) set to "1". Although a generic record format is specified with type fields allowing standardized or proprietary extensions, the only use of SDDA RR in DNSSEC operations is the support of trust anchor key management operations. Schemes using the SDDA-RR format are to be specified in other documents. Moreau Standards Track [page 1] Internet-Draft SDDA-RR December, 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Resource Record Specifications . . . . . . . . . . . . . . . . . . 3 2.1 General Characteristics . . . . . . . . . . . . . . . . . . 3 2.2 SDDA RR Wire Format . . . . . . . . . . . . . . . . . . . . 3 2.2.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 5 2.2.2 The Algorithm Field . . . . . . . . . . . . . . . . . 5 2.2.3 The Authentication Mechanism Type Field . . . . . . . 5 2.2.4 The Authentication Context Type Field . . . . . . . . 6 2.2.5 The Authentication Expiration Field . . . . . . . . . 6 2.2.6 The Authentication Inception Field . . . . . . . . . 6 2.2.7 The Authentication Mechanism Type Extension Field . . 7 2.2.8 The Authentication Context Data Field . . . . . . . . 7 2.2.9 Algorithm-Related Fields . . . . . . . . . . . . . . 7 2.2.9.1 The Authentication Algorithm Type Field . . . 8 2.2.9.2 The Authentication Algorithm Type Extension Field . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.9.3 The Authentication Algorithm Common Parameters Field . . . . . . . . . . . . . . . . . . . . . . 8 2.2.10 The Authentication Mechanism Data Field . . . . . . 8 2.3 The SDDA RR Presentation Format . . . . . . . . . . . . . . 8 3. Resolver Procedures . . . . . . . . . . . . . . . . . . . . . . . 9 4. Impact on DNSSEC Core Specifications . . . . . . . . . . . . . . . 11 4.1 Impact on [RFC4033] Specifications . . . . . . . . . . . . . 11 4.2 Impact on [RFC4034] Specifications . . . . . . . . . . . . . 12 4.3 Impact on [RFC4035] Specifications . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 7. Normative References . . . . . . . . . . . . . . . . . . . . . . . 13 8. Informative References . . . . . . . . . . . . . . . . . . . . . . 14 Document Revision History . . . . . . . . . . . . . . . . . . . . . . 14 From revision -00 to revision -01 . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 15 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 15 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 16 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Moreau Standards Track [page 2] Internet-Draft SDDA-RR December, 2005 1. Introduction The SEP DNSSEC Direct Authenticator Resource Record (SDDA RR) provides a generic RR format for authentication mechanisms applicable to DNSKEY records with the SEP bit set. It is intended to fulfill the need of trust anchor key management, notably automated trust anchor key rollover. Typically, this is done using cryptographic mechanisms outside of the DNSSEC core specifications. Zero or more SDDA records may occur in a zone apex for a DNSKEY record with the SEP bit, each using a different combination of algorithms and security context. An SDDA record provides additional information about the DNSKEY. This information may assist resolvers in authenticating the DNSKEY record contents. Authentication mechanisms used with SDDA records are expected to require and/or exploit outside arrangements, e.g. authentication key establishment or a pre-existing security association. The section 3 of the present specification suggests detailed resolver procedures for applying the SDDA RR to automate trust anchor key rollover, assuming some properties of the authentication mechanism. 2. Resource Record Specifications 2.1 General Characteristics The Type value for the SDDA RR type is [[to be determined]]. Experimentation with the present specification may be undertaken with the private SDDA RR type value 0xFF3F or 65343. The DNSKEY RR is class independent. The DNSKEY RR has no special TTL requirements. 2.2 SDDA RR Wire Format The RDATA for an SDDA record consists of a 2 octet key tag field, three 1 octet type fields, and a number of other fields as implied, directly or indirectly, by the type indications. The type fields are respectively for o an algorithm type field, o an authentication mechanism type field, o an authentication context type field. It is not expected that a decoding software be able to parse the variable-length fields unless it is fully compliant with the set of type indication values. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Moreau Standards Track [page 3] Internet-Draft SDDA-RR December, 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Auth Mech Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Ctx Type | Signature Expiration | +-+-+-+-+-+-+-+/ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Signature Inception | +-+-+-+-+-+-+-+/ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+/ other fields / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SDDA RR fields are listed in the table below in their order in the SDDA RR wire encoding. Some fields are optional and/or can be repeated. The group of three fields starting with Authentication Algorithm in section 2.2.9 may be repeated more than once. The Authentication Mechanism Data value lies at the end of SDDA RR wire encoding, it may comprise zero, one, or more fields (e.g. a DSA signature value is two integers). An SDDA record points to a DNSKEY record using the fields NAME, Key Tag, and Algorithm. Section Field Description, Occurrence Rule ======= ================================== 2.2.1 Key Tag, Always present 2.2.2 Algorithm, Always present 2.2.3 Authentication Mechanism Type, Always present 2.2.4 Authentication Context Type, Always present 2.2.5 Authentication Expiration, Always present 2.2.6 Authentication Inception, Always present 2.2.7 Authentication Mechanism Type Extension, Optional based on Authentication Mechanism Type 2.2.8 Authentication Context Data, Optional based on Authentication Context Type 2.2.9.1 Authentication Algorithm Type, Zero or more occurrences based on Authentication Mechanism Type 2.2.9.2 Authentication Algorithm Type Extension, Optional based on immediately preceding Authentication Algorithm Type 2.2.9.3 Authentication Algorithm Common Parameters, Zero or more occurrences based on immediately preceding Authentication Algorithm Type 2.2.10 Authentication Mechanism Data, Zero or more occurrences based on Authentication Mechanism Type and any Authentication Algorithm Type Moreau Standards Track [page 4] Internet-Draft SDDA-RR December, 2005 2.2.1 The Key Tag Field The Key Tag field holds the key tag of the DNSKEY RR referred to by the SDDA record, in network byte order. The DNSKEY RR referred to by the key tag field of an SDDA RR MUST have the same owner name and the SEP bit set. The Key Tag used by the SDDA RR is as specified in Appendix B of [RFC4034]. As explained in Appendix B of [RFC4034], DNSSEC key tags are not always referring unambiguously to a single DNSKEY RR within the allowed set. An authentication mechanism specification MUST ensure that colliding key tags ambiguities can be resolved with the data contents of other fields. 2.2.2 The Algorithm Field The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the SDDA record. The algorithm number used by the SDDA RR is identical to the algorithm number used by DNSKEY RRs. Appendix A.1 in [RFC4034] lists the algorithm number types. 2.2.3 The Authentication Mechanism Type Field The SDDA RR provides authentication information for a DNSKEY RR according to an authentication mechanism. The Authentication Mechanism type field identifies the specific mechanism applicable to the SDDA record, and partly determines the format of the RDATA variable part after the Authentication Inception field. The currently allocated authentication mechanisms are 0: reserved, 1: TAKREM key rollover message authentication defined in reference [TAKREM-DNSSEC], 253: Private mechanism identified by a domain-name-encoded extension field, see section 2.2.7, 254: Private mechanism identified by an ISO Object Identifier extension field, see section 2.2.7. Mechanism numbers 253 and 254 are reserved for private use and neither will be assigned to a specific mechanism. Private mechanisms use the Authentication Mechanism Type Extension optional field specified in section 2.2.7. 2.2.4 The Authentication Context Type Field Some authentication mechanism may need a reference to previously established parameters, e.g. a security association or a simple symmetric secret key. In cases where the Name field of the SDDA Moreau Standards Track [page 5] Internet-Draft SDDA-RR December, 2005 record does not provide sufficient context indication, a non-zero value in the Authentication Context Type field tells the format of reference information found in the Authentication Context Data field. The semantic rules of Authentication Context Data field should be specified with any authentication mechanisms that use a given format. The currently allocated authentication context types are 0: none, i.e. the domain name provides adequate context information; 1: a DNS name (not compressed) is present in the Authentication Context Data field; 2: an opaque 32 bits value (encoded in network order) is present in the Authentication Context Data field. 2.2.5 The Authentication Expiration Field The Authentication Expiration field and Authentication Inception field specify a validity period for the DNSKEY authentication. The DNSKEY targeted by the SDDA record MUST NOT be used as a trust anchor outside of the inception and expiration range. The Authentication Expiration field and Authentication Inception field values specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The longest interval that can be expressed by this format without wrapping is approximately 136 years. An SDDA RR can have an Authentication Expiration field value that is numerically smaller than the Authentication Inception field value if the expiration field value is near the 32-bit wrap-around point or if the signature is long lived. Because of this, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]. As a direct consequence, the values contained in these fields cannot refer to dates more than 68 years in either the past or the future. 2.2.6 The Authentication Inception Field See the description in above subsection 2.2.5. 2.2.7 The Authentication Mechanism Type Extension Field When the Authentication Mechanism Type field value implies the presence of the present extension field, this subsection specification applies. If the Authentication Mechanism Type field value is 253, the present extension field contains a wire encoded domain name, which must not be compressed. The domain name indicates the private mechanism to use. Entities should only use domain names they Moreau Standards Track [page 6] Internet-Draft SDDA-RR December, 2005 control to designate their private mechanisms. If the Authentication Mechanism Type field value is 254, the present extension field contains an unsigned length byte followed by a BER encoded Object Identifier (ISO OID) of that length. The OID indicates the private mechanism to use. Entities should only use OIDs they control to designate their private mechanisms. 2.2.8 The Authentication Context Data Field The Authentication Context Data field contains the security context identification data in a format identified by the Authentication Context Type field. This field is present if a non-zero value is present in the Authentication Context Type field. An authentication mechanism may need this information in an SDDA RR instance for a complete reference to previously established security parameters. 2.2.9 Algorithm-Related Fields A given authentication mechanism may rely on one or more cryptography algorithms, e.g. a digital signature mechanism may use two such algorithms: a cryptographic hash function and a public key primitive. For each cryptographic algorithm, a set of algorithm-related fields may be present. This allows the selection of a specific algorithm among a family of alternatives, and/or the specification of common parameters applicable to an algorithm instance. The presence of one or more sets is implicitly specified by the Authentication Mechanism Type indication in an SDDA RR, as are the algorithm-specific field contents and semantic. A set of algorithm-related fields comprises at least the Authentication Algorithm Type field described in section 2.2.9.1, optionally the Authentication Algorithm Type Extension field described in section 2.2.9.2, and optionally the Authentication Algorithm Common Parameters field described in section 2.2.9.3. When more than one algorithm deserve some algorithm-related fields, they should appear by groups, e.g. Authentication Algorithm Type, Authentication Algorithm Type Extension, and Authentication Algorithm Common Parameters for a first algorithm, then these three fields for the next algorithm. 2.2.9.1 The Authentication Algorithm Type Field The Authentication Algorithm Type field is optional and significant in the context of the Authentication Mechanism field value of a given SDDA RR encoding. This should be a one-octet field. The mechanism-specific allocation of algorithm type values may make use of the Authentication Algorithm Type Extension field for private algorithms. Moreau Standards Track [page 7] Internet-Draft SDDA-RR December, 2005 2.2.9.2 The Authentication Algorithm Type Extension Field The Authentication Algorithm Type Extension field allows private algorithms to be specified in the Authentication Algorithm Type field, as may be specified for a given authentication mechanism. 2.2.9.3 The Authentication Algorithm Common Parameters Field Some cryptographic algorithm require the specification of common parameters, e.g. the Diffie-Hellman cryptosystem, other algorithms based on the discrete logarithm problem and elliptic curve cryptographic algorithms. The Authentication Algorithm Common Parameters field allows the specification of these parameters, using algorithm-specific rules. These rules may specify the common parameter values directly or by reference to values published elsewhere (e.g the United States NIST organization publishes elliptic curve parameters). 2.2.10 The Authentication Mechanism Data Field The Authentication Mechanism Data field contains the "payload" data relevant to the authentication mechanism applied to the DNSKEY RR linked to the SDDA RR. The rules applicable to this data field are governed by the authentication mechanism and any authentication algorithm specified in the previous fields of this SDDA RR. 2.3 The SDDA RR Presentation Format The presentation format of the RDATA portion is as follows: The Key Tag field MUST be represented as an unsigned decimal integer. The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic as specified in Appendix A.1 of [RFC4034]. The Authentication Mechanism Type MUST be represented as an unsigned decimal integer. The Authentication Context Type MUST be represented as an unsigned decimal integer. The Authentication Expiration Time field and Authentication Inception Time field values MUST be represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where: o YYYY is the year (0001-9999, but see Section 2.2.5); o MM is the month number (01-12); o DD is the day of the month (01-31); Moreau Standards Track [page 8] Internet-Draft SDDA-RR December, 2005 o HH is the hour, in 24 hour notation (00-23); o mm is the minute (00-59); and o SS is the second (00-59). Note that it is always possible to distinguish between these two formats because the YYYYMMDDHHmmSS format will always be exactly 14 digits, while the decimal representation of a 32-bit unsigned integer can never be longer than 10 digits. The remaining portion of the RDATA field must be represented as a Base64 encoding of its contents. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC3548]. 3. Resolver Procedures The present specification is limited to record format rules, and some minor provisions for name server procedures. It does not change the DNS resolver procedures. However, this section describes generic resolver procedures that may be possible assuming some properties of the authentication mechanism. The SDDA RR is intended for trust anchor key rollover support, preferably as a fully automated procedure. Inescapably, trust anchor key management implies that the resolver maintain some state information about current valid trust anchor keys, and perhaps other relevant data. We assume that a rollover scheme requires some Trust Anchor Key initial configuration data (TAK-i) and the rollover operation contributes some additional data (TAK-r) that changes the state maintained by the resolver. We assume that the TAK-i data contains indications of which domain name(s) may be subject to DNSKEY rollover supported by the SDDA mechanism. Moreover, resolver queries for the DNSKEY and SDDA RRsets for such a domain name would, upon successful completion, provide the TAK-r data. For a domain name covered by the TAK-i data, and at a given point in time, the TAK-i data plus the cumulative TAK-r data received so far by a resolver provide trust status for one or more DNSKEY values, including expiration and inception times provided by the SDDA RR. Thus, a domain name can have one of the following characterization: TAK-i with current trust o the domain name is covered by TAK-i data, and the cumulative TAK-r data provides current trust for at least one DNSKEY value, TAK-i without trust o the domain name is covered by TAK-i data, and the cumulative TAK-r data provides no currently trusted DNSKEY value (e.g. before receipt of any valid TAK-r data or after the expiration time of every received SDDA), Moreau Standards Track [page 9] Internet-Draft SDDA-RR December, 2005 TAK-i with valid parental DS o the domain name is covered by TAK-i data, the cumulative TAK-r data provides no currently trusted DNSKEY value, and a validated parental DS has been received for this DNSKEY value (ignoring RRSIG expiration times), local trust policy o not being covered by TAK-i data, the domain name is considered a trust anchor according to local policy, no trust information o the domain name is not covered by any of the trust characterization above. When presented with a application query, the resolver might immediately determine that a domain name at or above the name in the query would be characterized as "TAK-i without trust" while no lower domain is characterized as "local trust policy" or "TAK-i with current trust." In such a case, it may be reasonable for the resolver to start name server queries at this domain name for the DNSKEY RRset and the SDDA RRset. When the status of a specific DNSKEY RR with the SEP bit set is to be determined for some zone name, a "local trust policy" or "TAK-i with current trust" including this DNSKEY value needs no further resolver processing. In the case of "no trust information," no SDDA query should be attempted (i.e. a normal attempt to validate a parental DS for a zone name other then the root). For "TAK-i with valid parental DS," the SDDA query should be attempted only after failure of a normal attempt to validate a parental DS for the zone name. Other cases of "TAK-i with current trust" and "TAK-i without trust" should trigger an SDDA query for the zone name (instead of a parental DS validation). The individual SDDA RR outcome (following a DNS query for an SDDA RRset) should be considered validated when it is properly signed with the targeted DNSKEY, and the received expiration and inception times are the same as, or more restrictive than, any such values previously received. Following any such validation, the trust characterization for the zone name can be set to either "TAK-i with current trust" or "TAK-i without trust." The circumstances may require a normal attempt to validate a parental DS for the zone name, which might turn the characterization from "TAK-i without trust" into "TAK-i with valid parental DS." Otherwise, a failure of the SDDA query should have no impact on the trust characterization of a domain name in the resolver state. 4. Impact on DNSSEC Core Specifications 4.1 Impact on [RFC4033] Specifications Moreau Standards Track [page 10] Internet-Draft SDDA-RR December, 2005 In [RFC4033], section 3, second paragraph, the present document adds a DNSSEC resource record type for the SDDA RR (in addition to RRSIG, DNSKEY, DS, and NSEC). In [RFC4033], section 3.1, at the end of the before last paragraph (where typical DNSSEC authentication chains are introduced), the following text should be added: The SDDA record type allows optional authentication of a trust anchor key when a resolver explicitly requests it (i.e. there is no automatic inclusion of an SDDA RR when target DNSKEY with the SEP bit set is included in a reply). A resolver would typically query SDDA RR when a) it is DNSSEC-aware, b) it encountered a DNSKEY with the SEP bit set for which it is not currently configured with an acceptable level of trust, and c) it supports one or more SDDA authentication mechanism. In [RFC4033], section 8, first sentence, the SDDA resource record type should be added to the enumeration of RRSIG, DNSKEY, DS, and NSEC. In [RFC4033], section 9, end of first paragraph (about the name server including RRSIG records et al. in the additional data of responses), the following text should be added: A name server SHOULD NOT include SDDA records in a response unless explicitly requested in a query. In [RFC4033], section 10, the present document should be included in the "DNSSEC protocol document set". 4.2 Impact on [RFC4034] Specifications In [RFC4034], the SDDA resource record type should be mentioned in the abstract and the introduction. In [RFC4034], section 2.1.1, second paragraph, the following text should be added after the second sentence (where the DNSKEY SEP bit is reported to have no special meaning for resolvers): The introduction of SDDA RR scheme creates an exception to this rule justified by the stated goal of support for automated trust anchor key rollover. If it is to be automated, such a rollover has to be triggered by a resolver encountering a previously unknown DNSKEY with the SEP bit with some expectation that a supported SDDA RR might target this DNSKEY. This fully complies with the original intent of the SEP bit as set forth in [RFC3757]. In the [RFC4034] section 7 on IANA considerations, it might be mentioned that DNSSEC algorithm numbers are used in the present specification. 4.3 Impact on [RFC4035] Specifications Moreau Standards Track [page 11] Internet-Draft SDDA-RR December, 2005 In [RFC4035], section 2.1, second paragraph (no secure entry point DNSKEY required for islands of security), the following text should be added: A DNSKEY RR acting as a secure entry point is also required if using an SDDA scheme for trust anchor key management. In [RFC4035], the last paragraph of section 2.2 should be extended with the following sentence: There MUST be an RRSIG for the SDDA RRset at a zone apex, if any, using each DNSKEY targeted by one of the SDDA RR. In [RFC4035], no change is required to section 4.2 since these provisions for DS record validation are not detailed enough to be varied by the introduction of the SDDA scheme. In [RFC4035], end of section 4.5 (Configured Trust Anchors), there should be a mention that SDDA schemes can assist trust anchor key management. In [RFC4035], section 5.1 (Special Considerations for Islands of Security), there should be a mention that SDDA schemes can assist configuration management for islands of security. In [RFC4035], end of section 5.3.1 (stating the DNSKEY RR authentication requirements for DNS response processing), a third option should be added: o the DNSKEY RR has the SEP bit set and the validator supports at least one SDDA scheme, retrieves the SDDA RRset from the same zone apex as the DNSKEY, and validates one of the SDDA RR targeting the DNSKEY RR following the rules of a supported SDDA scheme. 5. Security Considerations The present document specifies a DNS record format for authentication mechanisms that should rely on end-to-end cryptographic means for providing security services, i.e. trust anchor key authentication. The DNS as a transport mechanism for security-relevant information should be considered as an insecure transmission mechanism. Notably the digital signature present in a RRSIG record covering the SDDA RRset should not be trusted blindly (actually, if there is a reason to trust the signature of the SDDA RRset, there is almost certainly no justification to use an SDDA scheme in the first place). 6. IANA Considerations For the present DNS record type format specification to become Moreau Standards Track [page 12] Internet-Draft SDDA-RR December, 2005 effective, IANA would be requested to assign a DNS type code to the SDDA resource record from the Specification Required portion of the DNS Resource Record Type registry. If evolved into a recognized standard, the present document creates two "name spaces" ([RFC2434]) of relevance to IANA: the SDDA record Authentication Mechanism Type and the SDDA record Authentication Context Type. Other name spaces in the present document are either already covered by provisions of existing standards (algorithm types from [RFC4034]) or delegated to the specification for an authentication mechanism (authentication algorithm type). 7. Normative References [RFC1982] R. Elz, R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998 [RFC3548] S. Josefsson, Ed., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003 [RFC3757] O. Kolkman, J. Schlyter, E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004 [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 8. Informative References [TAKREM-DNSSEC] T. Moreau, "The Trust Anchor Key Renewal Method Applied to DNS Security (TAKREM-DNSSEC)", work-in- progress, Internet Draft draft-moreau-dnsext-takrem-dns-01.txt, December 2005 Document Revision History [[This document section to be removed upon RFC publication.]] >From revision -00 to revision -01 Moreau Standards Track [page 13] Internet-Draft SDDA-RR December, 2005 a) Removal of the digest fields from the in the SDDA RDATA definition. An authentication mechanism specification may use a digest field in the optional fields, e.g. as a set of algorithm-related fields. b) As a consequence of digest removal from the always present RDATA fields, a provision is made in above section 2.2.1 that an authentication mechanism specification MUST ensure that colliding key tags ambiguities can be resolved with the data contents of other fields. c) Introduction of authentication expiration and inception times, creating a semantic similar to the expiration and inception times of an RRSIG for a parental DS RRset. d) Introduction of a mandatory provision that an SDDA RRset is signed with the target DNSKEY of each SDDA RR in the set, thus mandating self-signed authentication for SDDA fields, notably the expiration and inception times. This is an application of the RRSIG semantic for enhanced security in the trust anchor key management. See above section 4.3, change to section 2.2 in [RFC4035]. e) Resolver procedures are now covered by the informational provisions of section 3. f) Editorial harmonizing changes for the above technical changes. g) An interim private SDDA RR type is specified in above section 2.1. h) 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 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 Moreau Standards Track [page 14] Internet-Draft SDDA-RR December, 2005 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. 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 15]