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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf