Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

[John Gilmore <[e-mail]>]

> For host with an A RR that points to the zone-name (instead of
> a hostname under the zone-name) and without any knowledge, this
> clash could happen, but then two unlikely things are happening
> (a system administrator putting his "ipsec/ssh" host at the
> top of his zone and a user whois aware of ipsec/ssh but unaware
> of where to look for the ipsec/ssh key-RR).

There's nothing wrong with putting an IPSEC KEY record at the top
of a zone, along with the zone keys.  That's why the keys have flags
and protocol fields in them, to differentiate the various sorts that
a domain name or host might have.

The parent that signs the KEY records at a zone top should be prepared
to sign any number of KEY records in the RRset, with any flags desired
by the zone owner.  The signature is defined to be on the entire
RRset, there is no way for the parent to "just sign the zone key".

My zone, toad.com, will one day have both a zone key and an IPSEC key.
That RRset will be signed by the parent zone, assuming it isn't VeriSign.
(VeriSign will probably try to charge big bucks for signing your zone,
since they currently charge big bucks for signing your SSL key, and
signed DNS keys could easily obsolete SSL certificates.  I think they 
bought NSI to be able to make money either way.)

Many SLDs have a web server at the SLD (e.g. slashdot.org as well
as www.slashdot.org).  If it supports IPSEC, its key will be there;
if it supports SSL, its key could be there in the DNS, etc.

There is no reason for TLD DNSSEC automation to refuse to sign RRsets
that contain keys like this.  And many reasons, generality and
non-discrimination being the most obvious, to sign whatever keys the
lower zone wants to put at its top label.  It does own its zone, and
should be able to control its contents...

	John Gilmore

PS: The last few releases of the FreeS/WAN software (www.freeswan.org)
contain support for fetching keys out of the DNS, and the current
snapshot contains prototype code for attempting opportunistic
encryption using such keys.  (Opportunistic encryptors see if an IPSEC
key is published for any destination IP address, and if so, attempt to
negotiate a tunnel before sending any packets to it.)


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