Internet DRAFT - draft-moreau-dnsext-takrem-dns
draft-moreau-dnsext-takrem-dns
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
"<r[0],R[0]>"), the present document assumes that a different
procedure is being followed. Specifically, the TAKREM procedure
requires the initial generation of a series of future signature key
pairs (appendix A notation "<r[i],R[i]>" for "0<i<=n"), and the
computation of a series of cryptographic hash code values (appendix
A notation "D[i]" for "0<i<=n"). This computation uses the hash
function input syntax specification in appendix B.
The number of future key pairs (appendix A notation "n") should
accommodate the expected lifetime of the DNSSEC service for the
domain, and the trust anchor cryptoperiod policy: it might be in
the order of tens or hundreds.
The zone manager should safeguard the relevant data independently
Moreau Informational [page 4]
Internet-Draft TAKREM-DNSSEC April, 2006
for each future signature key pair (appendix A notation
"<r[i],R[i],N[i],p[i],s[i]>"). Bar code printouts in tamper-evident
sealed envelopes appears as a suitable storage media for storage of
individual key pairs in separate components. The term "dead
storage" applies to this storage type because the cryptographic key
material is remote from any live digital computing device.
2.2 Initial Trust Anchor Key Distribution
With the original DNSSEC, the signature public key (appendix A
notation "R[0]") is initially distributed with the domain name as
the initial trust anchor key, and the signature private key
(appendix A notation "r[0]") is put into production (e.g. to sign
ZSK DNSKEY resource records).
Initial trust anchor distribution mechanisms are outside of the
DNSSEC specifications. The TAKREM proposal does not change this.
However, the initial trust anchor configuration data (appendix A
notation "R[0]") is replaced by an integer reference number "f" and
the series of cryptographic hash code values. The integer reference
number "f" is a 32-bit value. For a given domain name, the integer
value range from "f+1" to "f+n" should not be re-used by another
initial trust anchor configuration.
In summary, in a resolver the initial trust anchor configuration is
received as TAK-i data comprising, for each domain name subject to
the present automated rollover scheme:
1) the domain name,
2) a series of cryptographic hash code values (appendix A
notation "D[1], D[2], ..., D[n]"), and
3) a 32-bit integer reference value "f".
No special attention is paid to the hash code values and the
reference at this initial configuration time: they are simply kept
for later reference. At a later time, the resolver is able to
support the automated trust anchor key rollover procedure specified
in the following document section.
3. Trust Anchor Key Rollover Overview
For trust anchor key rollover, the present document specifies that
the new signature key pair (appendix A notation "<r[i],R[i]>" for
some "i" in the range "0<i<=n") is not to be generated, but rather
retrieved from the storage of future keys initially generated per
above subsection 2.1 for the same domain name. This rule is not
enforced by cryptographic means, but if the new key has a different
domain name, it can not be authenticated with the present scheme.
In addition to the retrieval of the next digital signature key pair
from secure storage, the TAKREM basic procedure mandates the
publication of a rollover message, which for DNSSEC purposes turns
into the simultaneous publication of an SDDA resource record with
the DNSKEY record. The generic format for the SDDA record is
specified in [SDDA-RR] and its application to TAKREM is specified
Moreau Informational [page 5]
Internet-Draft TAKREM-DNSSEC April, 2006
in the present document section 4. An SDDA records "targets" a
DNSKEY record, alike a parental DS record.
Accordingly, the DNS trust anchor rollover (augmented with TAKREM)
can be described as a three phase procedure.
o In the first phase, the zone manager retrieves the relevant
data for the future signature key pair (appendix A notation
"<r[i],R[i],N[i],p[i],s[i]>") and sets
a) the new signature private key (appendix A notation
"r[i]") in the protected computing environment used for
generating zone digital signatures,
b) the new signature public key (appendix A notation "R[i]")
in a DNSKEY resource record, and
c) the key tag for the new signature public key and the
other TAKREM rollover message elements (appendix A
notation "<R[i],N[i],p[i],s[i]>"), plus the value "f+i",
where "f" is the 32-bit reference described in the above
subsection 2.2, in an SDDA resource record.
The zone manager includes the new DNSKEY record and the SDDA
record targeting it in the zone data at the same zone version
update. Obituary SDDA RRs may be added to signal or confirm
the expiry of a DNSKEY RR that is no longer present in the
DNSKEY RRset, or should never be present (obituary SDDA RRs
are defined in section 2.2.5 of [SDDA-RR]). Furthermore, the
zone signing operation must include an RRSIG record targeting
the SDDA RRset and using the new signature key. There are
mandatory provisions in section 2.4 of [SDDA-RR] for the
simultaneous publication of such DNSKEY, SDDA, and RRSIG
records. The simultaneous publication of these records in a
zone data completes the zone manager duties specific to a
trust anchor key rollover operation according to the present
authentication scheme.
o The second phase is the new KSK usage in DNS zone signing
according to DNSSEC specifications. If the new DNSKEY record
is to be authenticated also by a parental DS record, this
second phase may be delayed until this DS record has been
included in the parental zone.
o The third phase is run by resolvers having received the TAK-i
data configuration for this domain name. This is specified in
section 5.
3.1 Usage Scenarios
The manager of an island of trust or the DNS root can use the
present authentication scheme for trust anchor rollover, provided
the TAK-i data distribution was done according to the above
subsection 2.2.
A normal secure child zone may also use the present rollover
scheme, e.g. if it is suspected that some DNS resolver would not
Moreau Informational [page 6]
Internet-Draft TAKREM-DNSSEC April, 2006
have a trust anchor for validating the parent zone signatures.
In any case, only the DNS resolvers having been configured with the
TAK-i data for a domain name can authenticate its trust anchor
using the present authentication scheme.
4. Detailed Zone Management Processing for Trust Anchor Key Rollover
4.1 Procedures
This section specifies how a zone manager creates at once the SDDA
record and the targeted DNSKEY record for a trust anchor key
rollover. The DNSKEY record must have both the "Zone Key" and
"Secure Entry Point" flags set to 1. The lifetime of an SDDA record
should be the same as the one in the targeted DNSKEY.
The intended cryptoperiod for the DNSKEY signature public key
should be reflected in the SDDA record field pair for
Authentication Expiration and Authentication Inception.
Specifically, after the earliest SDDA expiration time ever
published for a given target DNSKEY signature public key, the zone
manager must not reuse the same signature public key value again.
Likewise, before the latest inception time ever published for a
given target DNSKEY signature public key, the zone manager must not
use the signature public key.
The DNS publication of the DNSKEY and SDDA records create or
augment corresponding RRsets. The RRSIG signatures for these DNSKEY
and SDDA RRsets are specified respectively in section 2.2 of
[RFC4035], and in section 2.4 of [SDDA-RR].
4.2 Data Formats
This section specifies the TAKREM application of SDDA RR wire
format and formation, using the notation from appendix A. The
generic provisions of [SDDA-RR] apply to the SDDA record formation
and the targeting to the appropriate DNSKEY record.
The SDDA RR Authentication Mechanism Type field ([SDDA-RR] section
2.2.3) must contain 1 for the present document to apply.
The SDDA RR Authentication Context Type field ([SDDA-RR] section
2.2.4) should be 2 or 0.
o When this field value is 2, the 32-bits opaque value in the
Authentication Context Data field must hold the value "f+i".
From the value "f+i", a resolver can efficiently identify a
most probable candidate digest "D[i]" for TAKREM hash code
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 "<r[0],R[0]>", "<r[1],R[1]>",
"<r[2],R[2]>", ..., "<r[n],R[n]>", allocating the pair
"<r[0],R[0]>" as the initial trust anchor key pair, and reserving
each key pairs "<r[i],R[i]>" for the cryptoperiod starting with the
"i"'th trust anchor renewal, for "1<=i<=n".
Actually, the initial key pair "<r[0],R[0]>" is not essential; the
DNS resolver may bootstrap with the validation of the key pair
"<r[1],R[1]>" using the normal TAKREM rollover validation
procedure. The initial key pair "<r[0],R[0]>" is mentioned to
relate the TAKREM description to the prior procedure of manual
trust anchor key configuration.
A separate MASH (Modular Arithmetic Secure Hash) instance "H[i]" is
created for each "R[i]". MASH is defined in International standard
document ISO/IEC 10118-4:1998 ([ISO10118-4]).
That is, the zone owner selects a large composite modulus number
"N[i]" used in the MASH round function and a prime number "p[i]"
used in the MASH final reduction function.
Then, the zone owner selects a random salt field "s[i]".
A hash computation gives a root key digest "D[i]" :
"D[i]=H[i](s[i]|R[i]|N[i]|P[i])" .
The digest "D[i]" is like an advanced notice of future trust anchor
key "R[i]".
The data tuple "<r[i],R[i],N[i],p[i],s[i]>" is set aside in dead
storage.
The trust anchor key initial distribution is
"R[0], D[1], D[2], ..., D[n]" .
Security rationale: with data tuple "<r[i],R[i],N[i],p[i],s[i]>"
totally concealed until the usage period for key pair
"<r[i],R[i]>", an adversary is left with the digest "D[i]" from
which it is deemed impossible to mount a brute force attack.
Moreau Informational [page 10]
Internet-Draft TAKREM-DNSSEC April, 2006
A trust anchor key rollover is triggered by a rollover message
carrying the following information:
"i,<R[i],N[i],p[i],s[i]>" .
Upon receipt of this message, the DNS resolver becomes in a
position to validate the trust anchor key digest "D[i]".
Moreau Informational [page 11]
Internet-Draft TAKREM-DNSSEC April, 2006
Appendix B - Hash Function Input Stream Details
This appendix is normative.
The TAKREM rollover message processing requires the unambiguous
definition of a cryptographic hash function input stream in a
format not necessarily typical of the DNS RR formatting rules. The
input format is based on the ASN.1 distinguished encoring rules
[ASN1-DER]. The input format is based on the X.509 public key
encoding standard. In addition to providing an unambiguous
canonical encoding, this approach supports the inclusion of new
digital signature algorithms in the initial TAK-i data
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]
