Subject: DNSSEC editing process (Monthly posting)

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Thu, 14 Mar 2002 13:04:29 -0500

The DNSEXT working group has started a rewrite of the DNSSEC
specification into a documents that better reflect the protocol
and allow a test plan to be constructed from the specification.

To accomplish this, a team of volunteers has been formed to generate
the documents. The document editing team is tasked with documenting
the protocol as specified in RFC's generated by this group and id's
that have been passed on by the working group to the IESG.

The editors are NOT ALLOWED to make ANY changes in the protocol.
If clarifications are needed due to conflicting definitions,
imprecise specification, omission or other reason, the editors MUST
bring these issues to the attention of the working group on the
namedroppers mailing list.

To assist the editors, a small group of people with good understanding
of DNSSEC have been recruited to review document drafts and
answer questions that the editors have.
For simplified communication a mailing list has been created, anyone
can send messages to the editors via this mailing list
[email-masked].

Archive of this mailing list will be made available.

Please send minor corrections, comments, suggestions about the
DNSSECbis documents to [email-masked].

All major issues should be brought up on namedroppers, editors
MAY forward any correspondence to namedroppers, without asking
permission, if they deem the issues raised require wider attention.

DNSEXT co-chair Ólafur Guðmundsson approves new members on
the dnssec-editors malling list.

DNSSEC-editors is NOT a design group, it is a document maintenance
group.

The current members of the mailing list are:
Editors:
	Dan Massey
	Scott Rose
	Matt Larson
	Roy Arends

Advisors:
	Donald Eastlake
	Brian Wellington
	Edward Lewis
	Randy Bush
	Olafur Gudmundsson

The current set of documents produced by dnssec-editors is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-00.txt

A document on the DNSSEC protocol is scheduled to be released in April.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Daniel Massey <[email-masked]>
Date: Thu, 14 Mar 2002 17:11:36 -0500

Hi,

There are some differences between the rewrite and RFC 2535, but
none of these changes are new to the rewrite.  The rewrite attempts
to incorporate RFC 2535 and all the subsequent updates/changes.

The KEY record usage is different from that found in RFC 2535 and 
many of the flags/protocol octet values in the KEY record are gone.  
But this change is not new to the rewrite and can be found in:

  draft-ietf-dnsext-restrict-key-for-dnssec-01.txt

Note also the key chaining mechanism (storing SIGs from the
parent in the child) will not be in the rewrite and the rewrite
will use only the DS key chaining method.  Since both of these
drafts are currently in last call, they are included in the
rewrite.  

Dan

Simon Josefsson wrote:
> 
> Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]> writes:
> 
> Section 2 of draft-ietf-dnsext-dnssec-records-00 and section 3.2 of
> draft-ietf-dnsext-dnssec-intro-01 is one major change.
> 
> It changes both high level issues -- the intended usage of DNSSEC as a
> whole -- and low level issues -- the interpretation of the KEY RR
> protocol syntax.
> 
> Perhaps either the change should be reverted, or it should be made
> clear that this effort is targetting a DNSSECv2 that will be
> incompatible and lack major features present in RFC 2535.  IMHO the
> editorial rewrite has forbidden the single most important feature of
> RFC 2535.
> 
> As a memory jog, re-read the abstract of RFC 2535 and compare it with
> the current drafts:
> 
> ...
>    The extensions provide for the storage of authenticated public keys
>    in the DNS.  This storage of keys can support general public key
>    distribution services as well as DNS security.  The stored keys
>    enable security aware resolvers to learn the authenticating key of
>    zones in addition to those for which they are initially configured.
>    Keys associated with DNS names can be retrieved to support other
>    protocols.  Provision is made for a variety of key types and
>    algorithms.
> ...
> 
> It is clear that the goal of RFC 2535 included a general public key
> distribution mechanism.
> 
> If the goal of DNSSEC has changed, which one could understand since
> time has passed, that should be documented together with the reasons
> for that change.  Changing the goal of DNSSEC in a editorial rewrite
> smells fishy to me.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 Mar 2002 22:13:58 +0100

[ post by non-subscriber ]

...

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Mar 2002 16:31:43 -0800

> for that change.

the change became official when the wg reached consensus on

randy