Stephen Kent wrote: > > I recommend that the document not be approved by the IESG in its > current form. Section 6.1 states: > > >6.1. Support for GOST signatures > > > > DNSSEC aware implementations SHOULD be able to support RRSIG and > > DNSKEY resource records created with the GOST algorithms as > > defined in this document. > > There has been considerable discussion on the security area > directorate list about this aspect of the document. All of the SECDIR > members who participated in the discussion argued that the text in > 6.1 needs to be changed to MAY from SHOULD. The general principle > cited in the discussion has been that "national" crypto algorithms > like GOST ought not be cited as MUST or SHOULD in standards like > DNESEC. I refer interested individuals to the SECDIR archive for > details of the discussion. I agree with Stephen Kent. That needs to be a MAY. GOST is IMHO _not_ mature enough and not sufficiently understood and availble to justify a SHOULD or RECOMMENDED for its support/use in a core internet protocol. Over the past year we had our SSL/TLS supplier add support for GOST TLS ciphersuites to add OEM SSL/TLS implementation (in form of a third-party crypto plugin that can be certified by the relevant russian authorities). One of the problems with GOST is its lack of availability of documentation/specification and the meaning, purpose and characteristics of algorithm parameters. Admittedly, I know very little about the cryptographic details, but there are two GOST signature algorithms (GOST R34.10-1994 and GOST R34.10-2001). The earlier appears to bear some similarity with DH, the newer appears to bear similarity with ECDH. Whether and how much the -1994 version is deprecated is also a complete mystery. There are IETF documents listing specific algorithm Identifier parameters (sets), referenced by OIDs, and those OIDs are issued by one particular company. I haven't seen any documentation about the characteristics, purpose of these algorithm parameters sets and the means/process to define other parameter (sets). -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf