On 15/02/2010 6:37 PM, Martin Rex wrote:
Mark Andrews wrote:
In
message<201002151420(_dot_)o1FEKCMx024227(_at_)fs4113(_dot_)wdf(_dot_)sap(_dot_)corp>,
Martin Rex writes
:
OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?)
parameter sets are explicitly listed in last paragraph of section 2
of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what to
do if GOST R34.10-2001 signatures with other parameter sets are encountered.
Since each end adds the parameters and they are NOT transmitted this
can never happen. If one end was to change the parameters then nothing
would validate.
OK. I didn't know anything abouth DNSSEC when I entered the disussion...
Having scanned some of the available document (rfc-4034,rfc-4035,rfc-2536
and the expired I-D draft-ietf-dnsext-ecc-key-10.txt) I'm wondering
about the following:
- the DNS security algorithm tag ought to be GOST R34.10-2001
and not just "GOST"
This is a good point, adding a version label is a possiblity in this
case or just in the future cases, but I think slapping one on
this is fine.
- DSA and the expired ECC draft spell out the entire algorithm
parameters in the key RRs, which preclues having to assign
additional algorithm identifiers if a necessity comes up to
use different algorithm parameters.
DSA did not cover the case if the key is > 1024 bit.
ECC draft was killed due to the fact it was impossible to guarantee that
a implementation supporting ECC would be able to handle all the
possible curves that the proposal allowed.
Wouldn't it be sensible to do the same for GOST R34.10-2001 keys --
i.e. list the parameter set as part of the public key data?
Given the procedure of the standardization body that defines GOST
the parameter set OID could be used in alternative to spelling
out each of the element in the parameter set in full.
Implying the paramter set A for the GOST R34.10-2001 algorithm does
not seem very "agile", given the limited number range for the algorithm
field in DNS security.
For interoperability reasons we WANT MINIMAL flexibility for
implementors/users. Thus we stripped all that out and picked ONE
possible GOST/2001 curve.
Given the differences between -1994 and -2001 versions,
any successor GOST R34.10-201X standard may not be able to reuse
the DNSKEY record anyway and need a new algorithm identifier.
And at that point, an unqualified label "GOST" would become
ambiguous.
see above,
Olafur (document shepeard)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf