Re: draft-ietf-dnsext-dnssec-gost

[Olafur Gudmundsson <[e-mail]>]

On 15/02/2010 6:37 PM, Martin Rex wrote:
> Mark Andrews wrote:
>>
>> In message<[e-mail]>, 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)