I reviewed this document as part of the security directorate's ongoing  


effort to review all IETF documents being processed by the IESG.   


These comments were written primarily for the benefit of the security  


area directors.  Document editors and WG chairs should treat these  


comments just like any other last call comments.






This document defines formats for DNSKEY, RRSIG, and DS records that  


use the GOST suite of cryptographic algorithms, namely GOST 34.10-2001  


for signing and GOST 34.11-94 for digest computation.






The document is generally clearly written and usable, but I'm  


concerned about how the document manages algorithm parameters. The  


cryptographic computations described in this document all use a single  


set of parameters, even though RFC 4357 defines at least four other  


sets of signing parameters, and parameter selection is permitted by  


several analogous drafts: RFC 3110 (RSA/SHA1 for DNSSEC) allows the  


RSA modulus to be specified, and RFCs 4490 and 4491 (the analogous  


documents for PKIX and CMS) allow the use of arbitrary GOST  


parameters.  "Hard-wiring" algorithm parameters to an algorithm  


number, as this draft does, increases the burden on the algorithm  


number space because it requires a separate number for each  


combination of parameters that can be used.






I also agree with the comments from Steve and Paul that the "SHOULD  


support GOST" in Section 6.1 should be a "MAY".




Detailed comments follow.

--Richard



Section 1, second paragraph:


It would be helpful to refer to the english versions of the algorithm  


descriptions (draft-dolmatov-cryptocom-gost*) at this point.




Section 1, fourth paragraph:
There should be an "and" before "GOST 28147-89".

Section 2.1:



It would be really helpful if you could explain what this sequence of  


bytes means.  Putting on my ASN.1/DER thinking cap, I managed to  


figure out that it's creating a SubjectPublicKeyInfo structure; I  


would suggest saying that, and maybe including a diagram like the  


following (which makes it even clearer that the algorithm parameters  


are being fixed):




SubjectPublicKeyInfo {
   algorithm: AlgorithmIdentifier {
       algorithm: id-GostR3410-2001
       params: GostR3410-2001-PublicKeyParams {
           publicKeyParamSet: id-Gost3410-2001-CryptoPro-A-ParamSet
           digestParamSet: id-Gost3411-94-CryptoProParamSet


           encryptionParamSet: id-Gost3411-94-CryptoProParamSet  


[default]



       }
   }
   subjectPublicKey: GostR3410-2001-PublicKey [64 key bytes]
}



Of course, if implementations are going to be tied to this data  


structure, the only possible parameters they can use are ones that  


have an OID, e.g., those defined in RFC 4357 (this limitation is due  


to the fact that the GostR3410-2001-PublicKeyParams structure only  


allows parameters to be defined by reference).  However, you could  


still allow any OID to be used in the *ParamSet fields and provide  


some simple instructions on how to patch together a  


SubjectPublicKeyInfo structure out of them.




Section 3, second paragraph:


For clarity, it would be helpful to use the notation of RFC 4034 here,  


e.g.:



 hash = GOST3411( RRSIG_RDATA | RR(1) | RR(2) | ... )

Section 3.1, last paragraph:


In order to let people use this example as a test vector, you should  


include the random value that was used to compute this signature.





Section 5:


This section seems unnecessary, since GOST has only one size for keys,  


signatures, and digests.




Section 6.2:
Should the "required" here be "REQUIRED"?

Section 6.3:


This paragraph contradicts Section 3 (and thus RFC 4490), which says  


the signatures are provided in big-endian order.  I think the general  


point is that you're sticking with the byte orders that have been  


previously defined.