Subject: singing-auth & simple-secure-update drafts

From: Brian Wellington <[email-masked]>
Date: Wed, 4 Oct 2000 18:33:10 -0700 (PDT)

In the process of trying to move these drafts to RFCs, a few minor changes
have been made.  The SSU one is my fault - I probably should have
submitted a new draft a few months ago, but forgot.  Sorry.

The main change to signing auth is the following text:

--
The combination of signer's name, key tag, and algorithm MUST identify a
zone key if the SIG is to be considered material.  The only exception that
the signer's name field in a SIG KEY at a zone apex SHOULD contain the
parent zone's name, unless the KEY set is self-signed.
--

which allows self signed key sets, which will be necessary for DNSSEC to
be effective.

In simple-secure-update, the "Interaction with DNSSEC section" was cleaned
up, and the only major change is that the server is no longer required to
verify signatures generated by zone keys.  The text is below, since the
draft will likely not show up for a few days (it was just submitted).

--
4 - Interaction with DNSSEC

Although this protocol does not change the way updates to secure zones
are processed, there are a number of issues that should be clarified.

4.1 - Adding SIGs
An authorized update request MAY include SIG records with each RRset.
Since SIG records (except SIG(0) records) MUST NOT be used for
authentication of the update message, they are not required.

4.1 - Adding SIGs
An authorized update request MAY include SIG records with each RRset.
Since SIG records (except SIG(0) records) MUST NOT be used for
authentication of the update message, they are not required.

If a principal is authorized to update SIG records and there are SIG
records in the update, the SIG records are added without verification.
The server MAY examine SIG records and drop SIGs with a temporal
validity period in the past.

4.2 - Deleting SIGs

If a principal is authorized to update SIG records and the update
specifies the deletion of SIG records, the server MAY choose to override
the authority and refuse the update.  For example, the server may allow
all SIG records not generated by a zone key to be deleted.

4.3 - Non-explicit updates to SIGs

If the updated zone is secured, the RRset affected by an update
operation MUST, at the completion of the update, be signed in accordance
with the zone's signing policy.  This will usually require one or more
SIG records to be generated by one or more zone keys whose private
components MUST be online [signing-auth].

When the contents of an RRset are updated, the server MAY delete all
associated SIG records, since they will no longer be valid.

4.4 - Effects on the zone

If any changes are made, the server MUST, if necessary, generate a new
SOA record and new NXT records, and sign these with the appropriate zone
keys.  Changes to NXT records by secure dynamic update are explicitly
forbidden.  SOA updates are allowed, since the maintenance of SOA
parameters is outside of the scope of the DNS protocol.
--

If no one objects to these changes, the drafts should be able to move
forward very soon...

Brian

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.