Re: draft-ietf-dnsext-dnssec-gost

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15/02/2010 6:37 PM, Martin Rex wrote:
Mark Andrews wrote:

In message<201002151420.o1FEKCMx024227@xxxxxxxxxxxxxxxxxxx>, 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]