[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review
At 12:42 AM 3/27/2006, Eastlake III Donald-LDE008 wrote:
Hi Mike,
See below at @@@
Trimmed all of the text - readers can see previous emails in this
thread if they want more detail.
Don -
If I asked you a question of "how do I form a valid DNSKEY record
containing a DSA key" I believe you would claim that this ID taken
with 4034 provides sufficient detail to do so. I disagree. What I
get from 4034 is the general format of a DNSKEY RR. What I get from
this ID is the ordering of bits within a key blob of some form. What
I am missing is what format identifier (e.g. Algorithm identifier)
applies to this ID and where this key blob explicitly fits within the
DNSKEY RR. If you're saying this isn't the job of this ID, then my
question is "where is the ID that maps this ID into the DNSKEY RR"?
I refer to the Algorithm Identifier field as a format id because
that's really what it is. It describes the format of the PublicKey
field and needs to reference a specific document to do so rather than
the more generic algorithm name. To understand what I mean, let's
consider the RSA algorithm. The RSA public key has two common
representations - the Public/Exponent representation and the Chinese
Remainder Theorem representation. Neither of the two RSA related
Algorithm IDs in appendix a.1 of 4034 provide such representation. I
would need to define a third (or more) RFC with this format and the
assigned algorithm ID would refer specifically to that RFC.
You're proposing obsoleting 2546 and 4034 points at 2546 as being the
specific document which defines the format for Algorithm ID 3. You
need a replacement document which links that algorithm ID (3) to a
specific format. Its just a simple as that. This ID does not do that.
Also, the more I think about it, the less I like the current system
of assigning a single number for both the public key representation
and an associated signature representation. We're about to re-do RSA
with SHA1 into RSA with SHA256 and possibly other SHAs. I would
expect similar actions for DSA. I suggest we split the algorithm
assignments for key and signature as follows:
Algorithm IDs for Key representations:
0 - Reserved
1 - RSA (modulus/exponent form)
2 - DH
3 - DSA (Fips 182-6)
4 - ECC - not yet defined
5 - RSA (modulus/exponent form - same as 1)
Algorithm IDs for Signature representations
1 - RSA/MD5 - not recommended
2 - none (was DH)
3 - DSA with SHA1
4 - Reserved
5 - RSA/SHA1
6-127 reserved
127-255 - new signature algorithms.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>