Re: draft-ietf-dnsext-dnssec-gost

[Olafur Gudmundsson <[e-mail]>]

On 15/02/2010 7:43 PM, Olafur Gudmundsson wrote:
> 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)
>
Martin,

Based on your comments and the possible confusion over registering the
memonic "GOST" for DNSSEC, I think it would be wise to change the DNSKEY 
Memonic to "ECC-GOST".

	Olafur (document shepeard)
PS: orignally we registered RSA for RSA/MD5 combination, then we got 
RSASHA1, RSASH256, RSASHA1NSEC3 ......, thus the first registered should 
not get a special shoter name than later variants :-)