Re: draft-ietf-dnsext-dnssec-gost

[Martin Rex <[e-mail]>]

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"

  - 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.

    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.

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. 

As previously mentioned, current uses of GOST R34.11 should be
changed to GOST R34.11-1994 as well (prevent ambiguity with a
future/updated hash algorithm for GOST).


-Martin