Subject: [dnsop] DNSSEC and EPP Review Request

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 5 Aug 2004 12:36:44 -0400

[Sorry if this is a repeat.  I sent a similar message to the list yesterday,
but it doesn't appear to have been redistributed.  I may have sent it from
an unsubscribed address, dooming it to moderation purgatory.]

As a follow-up to my presentation at yesterday's dnsop working group
meeting, this is the document that I would like to have reviewed by people
with DNS operations and management experience:

http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-03.txt

There is also a question of whether or not this document should be a dnsop
work item.  I've been working it as an individual submission for the last
few years and I'm perfectly happy to continue doing so, but I'd also happily
submit to wg processes if that makes sense.  So, if I could please ask two
questions:

1. Would working group members please take a look at the document to ensure
that I got things right with the child-parent key information exchange?

2. Should this document become a dnsop work item?

There is some specific text in the document that describes some of the
issues with child-parent key management.  That text in particular could
stand some review.

Thanks,
-Scott-

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 26 Aug 2004 12:44:55 -0400

Thanks for the comments, Sam.  More below.

-Scott-

> -----Original Message-----
> From: Samuel Weiler [mailto:[email-masked]] 
> Sent: Thursday, August 26, 2004 11:34 AM
> To: [email-masked]
> Cc: Scott Hollenbeck
> Subject: Re: [dnsop] DNSSEC and EPP Review Request
> 
> 
> Comments on draft-hollenbeck-epp-secdns-03.txt:
> 
> Perhaps I'm missing something, but Section 2.2 and Section 7 (security
> considerations) both refer to sending signatures, presumably over EPP,
> yet I see no mention of those data elements in the schema.  Which is
> correct?  I suspect it's sufficient to say "you need to authenticate
> this somehow", which section 7 does.

Section 4, this element:

<element name="sigVal" type="secDNS:keySigType"/>

> In section 3.1.2, the nxt attribute implies the use of opt-in.  This
> should probably be removed or discussed only as a "future extension"
> bit.  Also s/NXT/NSEC/.

Thanks for catching this.  It's an artifact of older thinking.

> There are elements for start/end dates on publication, but nothing for
> sig lifetime.  It may be useful for a client to be able to request a
> sig lifetime much shorter than the EXPECTED key publication interval.
> If the start/end dates are meant to be that, this needs to be
> clarified.

OK, what's really useful from a deployment perspective?  Are the start-end
dates good enough, or is something else needed?  What are the implications
of the sig lifetime and start-end dates being different?  I'm open to ideas.

> The startDate/endDate elements appear to be part of dsData but not key
> (they're in keyData, but not key).  The rem element requires either a
> key or dsData.  Hence, rem'ing a dsData appears to require sending
> those dates.  It may not be wise to require the registrar to remember
> what start/end dates it (or another registrar) originally requested in
> order to remove a DS record.

Clients don't have to remember the dates.  They can be retrieved via an
<info> query.  The text makes that clear, but I suppose the example could be
better.

> Also: can you remove something created
> as keyData by removing dsData? Or the other way around?  I'm surprised
> that rem requires recitation of the entire old dsData when chg does
> not.

Nope, there's a one-for-one relationship.

> Formats of data: the date field formats aren't specified.  For other
> fields, refer specificallly to the "presentation formats" in 2535 (and
> successor docs).  Consider whether you need any further escaping or
> other encoding for each field.

Date field formats are specified in the schema using the XML Schema
"dateTime" data type.  Other field formats *are* referenced to
draft-ietf-dnsext-dnssec-records.  Did I miss something somewhere?

> Update the doc to reference DNSSECbis.

Where (section 1 maybe?) and in what context?  There is no outdated
reference to replace.

-Scott-

.