Hi Nils, Thanks for the comment. >Hi Cathy, > >are there any implementations of this available?
Unfortunately, as far as I know, there is no such implementation yet. Of course it's a good idea to start real coding work. We'd like to support the new algorithm in: * DNS sevice, * DNS server software, * DNS tools, * at least a prototype system for test. It depends. And because Openssl has supported SM2/SM3 since version 1.1.1, It's convenient to have a try for people who are interested in. I think the protocol and the implementation are like two feet. You have to decide to lift which one first when walking. Besides introducing the format of PUBKEY, SIGNATURE, DIGEST of SM2/SM3 in DNS RR, another motivation to submit such a draft is to apply new algorithm numbers to avoid confliction in advance, although there are so many numbers available for new algorithms. If there is any implementation that supports SM2/SM3 algorithm, I'll tell you as soon as I know. > >In Sec. 2, it draft says > >> The implementation of SM3 in DNSSEC follows the >> implementation of SHA-256 as specified in RFC 4509[RFC4509] except >> that the underlying algorithm is SM3, the digest value is 32 bytes >> long, and the digest type code is 17 [to be determined]. > >RFC 4509 states that SHA-256 has 32 byte digest length, so the "except" >above is a bit misleading. You're right. Thanks for the correction. I should delete the following words. "the digest value is 32 bytes long, " >While the digest type code is to be >determined, it should be 6 to be consistent with the rest of the draft. 6 is for new digest algorithm while 17 is for new signature algorithm. The draft applies two number for different usage. Best regards, Cahty Zhang > >Best, >Nils > >On Wed, 2022-08-10 at 16:55 +0800, zhangcuiling wrote: >> Dear dnsop, >> >> According to Paul's comment, I modified the draft. There are two >> major changes. >> >> 1. Replace a reference document with a free one. >> In the former version, the draft referenced an ISO standard >> [ISO/IEC14888-3:2018] that is not freely available, so I replace it >> with another one. >> And additionally, I noticed that there is a RFC which introduces SM >> Cipher Suites for TLS 1.3 [RFC8998]. >> >> 2. Add a few words to describe why it's reasonable to introduce >> another ECC-based algorithm. >> Explain the differences between SM2 and ECDSA from the point of view >> of the curve it uses and the process. >> >> Any comments and suggestion will be appreciated. >> >> Best regards, >> >> Cathy Zhang >> >> 8/10/2022 >> >> > A new version of I-D, draft-cuiling-dnsop-sm2-alg-01.txt >> > has been successfully submitted by Cuiling Zhang and posted to the >> > IETF repository. >> > >> > Name: draft-cuiling-dnsop-sm2-alg >> > Revision: 01 >> > Title: SM2 Digital Signature Algorithm for DNSSEC >> > Document date: 2022-07-27 >> > Group: Individual Submission >> > Pages: 6 >> > URL: >> https://www.ietf.org/archive/id/draft-cuiling-dnsop-sm2-alg-01.txt >> > Status: >> https://datatracker.ietf.org/doc/draft-cuiling-dnsop-sm2-alg/ >> > Htmlized: >> https://datatracker.ietf.org/doc/html/draft-cuiling-dnsop-sm2-alg >> > Diff: >> https://www.ietf.org/rfcdiff?url2=draft-cuiling-dnsop-sm2-alg-01 >> > >> > Abstract: >> > This document describes how to specify SM2 Digital Signature >> > Algorithm keys and signatures in DNS Security (DNSSEC). It lists >> > the curve and uses SM3 as hash algorithm for signatures. >> > >> > >> >> > >> > >> > The IETF Secretariat >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >-- >deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany > >Vorstandsvorsitz: Nils Wisiol >Registergericht: AG Berlin (Charlottenburg) VR 37525 > > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
