[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
one review of the DS thingy by WestWes
Quoting http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-01.txt:
#1. Introduction
#
# The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
# zones to distribute a cryptographic digest of a child's Key Signing
# Key (KSK) DNSKEY RR. This DS RR is signed using the parent zone's
# private half of it's DNSKEY and the signature is published in a RRSIG
# record.
The DS RRset is signed by at least one of the parent zone's private
zone data signing keys for each algorithm in use by the parent. Each
signature is published in an RRSIG resource record, owned by the same
domain as the DS RRset and with a type covered of DS.
(Just cleaning up the "private half" colloquialism. Personally, I
hate trying to sign with half of a key. ;))
#2. Implementing the SHA-256 algorithm for DS record support
#
# This document specifies that the digest type code [XXX: To be
# assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] for
Good job - that request is in the IANA considerations section.
# use within DS records. The results of the digest algorithm MUST NOT
# be truncated and the entire 32 byte digest result is to be published
# in the DS record.
#
...
#2.2. DS Record with SHA-256 Wire Format
#
# The resulting packet format for the resulting DS record will be [XXX:
# IANA assignment should replace the 2 below]:
I would not use "packet format" but rather something like
"on-the-wire" (okay, laugh about my use of an anachronism after
telling you I didn't like a colloquialism). The reason I'm saying
this is that the "packet" would also have the DNS header, yadda,
yadda, yadda. I just don't want anyone to think that this is a new
DNS packet format.
#
# 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
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# | Key Tag | Algorithm | DigestType=2 |
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# / /
# / Digest (length for SHA-256 is 32 bytes) /
# / /
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
#
#2.3. Example DS Record Using SHA-256
#
# The following is an example DSKEY and matching DS record. This
s/DSKEY/DNSKEY/
...
#
#3. Implementation Requirements
#
# Implementations MUST support the use of the SHA-256 algorithm in DS
# RRs.
This is always a sticky point. It's up to an implementation to decide if it
will support RFC wxyz.
E.g., if I were to be writing a test plan for code, I really need to
know what it means for code to accurately implement an RFC. Whether
the RFC is pertinent is part of an operations "profile" of a standard.
I know that this is a continuing rat-hole discussion in the IETF so I
don't expect a resolution, but I just want to note that the above
MUST is one that won't translate will to a test plan.
# Validator implementations MUST be able to prefer DS records
# containing SHA-256 digests over those containing SHA-1 digests. This
# behavior SHOULD by the default. Validator implementations MAY
s/by/be/
# provide configuration settings that allow network operators to
# specify preference policy when validating multiple DS records
# containing different digest types.
Unlike the earlier comment (of substance), these "operational"
requirements makes sense in developing a test plan.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
3 months to the next trip. I guess it's finally time to settle down and
find a grocery store.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>