Andrew Sullivan wrote: > > On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote: > > > > Martin Rex пиÑ?еÑ?: > > > >> I am somewhat illiterate to crypto math, so I'm wondering whether > >> it is technicall possible to use a GOST R34.10-1994 key agreement > >> (ephemeral keys) in conjunction with GOST R34.10-2001 certs&signatures, > > Never ever interested. ;) > > To address Martin Rex's point, however, we would not need to know > whether the draft's editors were ever interested, but whether it is > technically possible. This seems like a good (and so far unanswered) > question. I'm sorry for the confusion and off-topic that I created in the discussion. The dnssec-gost document appears to be OK in being very explicit and constrained in its usage of GOST, requiring the GOST R34.10-2001 signature algorithm and implying a single parameter set (A) for the signatures. The deprecated GOST R34.10-1994 algorithm is a non-issue for dnssec-gost. Ensuring that no reference to GOST signatures is without R34.10-2001 qualifier in the document should be sufficient to prevent any potential confusion. The use of GOST R34.11 for the hash algorithm should probably also be changed to include the year GOST R34.11 to prevent confusion with any future hash algorithms in the GOST R34.11 series. Mandating a particular parameter set for an ECC crypto algorithm is perfectly OK for interop. Whether or not to include a parameter set identifier in the DNS KEY RR is up to the DNSext working group (Implementations of GOST are likely to know all three GOST R34.10-2001 parameter sets listed in rfc-4357). The byte order of GOST-related values seems to be confusing: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-3 Quoting RFC 4490: "The signature algorithm GOST R 34.10-2001 generates a digital signature in the form of two 256-bit numbers, r and s. Its octet string representation consists of 64 octets, where the first 32 octets contain the big-endian representation of s and the second 32 octets contain the big-endian representation of r." http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-4 4. DS Resource Records GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest type {TBA2}.The wire format of a digest value is compatible with RFC4490 [RFC4490], that is digest is in little-endian representation. Since there are already RFCs out there using GOST (CMS) and there are implementations based on drafts (TLS) and maybe some under evaluation (XMLsec) it seems a little late to ask for "pure" ordering at this point in time. Re-using the format/ordering that is used in existing documents/protocols and implementations appear to be OK to _me_. IETF protocols provide more flexibility at this point than e.g. ASN.1. To me, it looks like there is a little mess in GOST byte ordering in various usage scenarios, so _I_ would not expect interop without interop testing, no matter what ordering DNSsec defines. :-/ I really appreciate the mentioning of key and hash sizes in the dnssec-gost document in section 5, because one can not easily "look it up" in rfc-4357. (It's in there, but not easy to determine). -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf