Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 25 Mar 2006 20:29:21 -0500

Hi Mike,

I'd like to know exactly what you mean. What assumptions do you have to
make?

Let's just talk about DNSKEY to be specific. Seems to me that RFC 4034
does a reasonable job of defining the wire encoding of DNSKEY except for
the interior of the part of the RDATA which it calls "Public Key" in
Section 2.1 of RFC 4034. Do you think the problem is that draft 2536bis
is ambiguous in defining the wire encoding of DSA keys? I can see how it
could be improved to be a little clearer in that regard. Or is that you
alternatively or additionally think that, even in the face of a
hypothetical perfect description in 2536bis of the octet wire encoding
sequence for a DSA key in the DNS, that RFC 4034 isn't clear enough
about where to stuff the data? Or what?

2536bis specifies the order of the subfields within the "Public Key"
data for a DSA key and explicitly says the octets within a subfield are
stored in 'stored in "big-endian" network order'...

Thanks,
Donald

-----Original Message-----
From: Mike StJohns [mailto:[email-masked]] 
Sent: Saturday, March 25, 2006 8:01 PM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

At 06:46 PM 3/25/2006, Eastlake III Donald-LDE008 wrote:
>@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if 
>that's what you mean by "connective tissue") but not the algorithm 
>dependent data format. At this point, the DNS DSA key format is usable 
>in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The 
>DNS DSA signature format is usable in RRSIG and SIG (to support
SIG(0)).
>Things like the "algorithm number" are different in DNSKEY and
IPSECKEY.
>I believe it is contemplated that there might be additional application

>specific key RRs, like IPSECKEY, defined in the future.

The problem is that you'd actually have to specify the actual way you
fit this into DNSKEY and RRSIG to be useable.  This document is not
sufficient to do that without making some possibly ambiguous
assumptions.  Which means you'd need yet another document to fulfill
that requirement.  And that makes this document somewhat useless and
pointless.

Mike

--
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: Mike StJohns <[email-masked]>
Date: Sat, 25 Mar 2006 20:55:22 -0500

>about where to stuff the data? Or what?

How does "
the structure of the
    relevant part of the RDATA part of the RR being used is the fields
    listed below in the order given." map to "put this in the 
PublicKey field of the DNSKEY RR"?  E.g. why (without going back and 
reading 2536) should I assume that "relevant part of the RDATA part" 
maps to the PublicKey field?

Also, "which algorithm ID do you use for this in the DNSKEY?  2536 
explictly said it was ID 3 - but that's for 'DSA/SHA1' and that's 
obviously a signature algorithm not a key representation so 
WTF?"  E.g. if the DNSKEY is now used for DSA/SHA256 does the 
algorithm ID change?  Can I use the same DNSKEY for both DSA/SHA1 and 
DSA/SHA256?  (Ditto for RSA....)

A document which obsoletes another document should be able to be read 
on its own and have a complete meaning. This one can't be. This 
document needs to specify:

1) The algorithm ids specific to this representation both for DNSKEY 
and for RRSIG.

2) The actual and specific placement of the fields described here 
within the DNSKEY and RRSIG.

Enjoy.  Mike