Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC

zhangcuiling <> Tue, 12 April 2022 08:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA5BD3A06E7 for <>; Tue, 12 Apr 2022 01:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MhBWjk0PbLPe for <>; Tue, 12 Apr 2022 01:38:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D12C43A077C for <>; Tue, 12 Apr 2022 01:38:20 -0700 (PDT)
Received: from CNNIC-PC (unknown []) by (Coremail) with SMTP id AQAAf0BZYXl4OlVi7hxZAA--.4635S2; Tue, 12 Apr 2022 16:38:16 +0800 (CST)
Date: Tue, 12 Apr 2022 16:38:17 +0800
From: zhangcuiling <>
To: Paul Wouters <>
Cc: dnsop <>
References: <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart321488411677_=----"
X-Coremail-Antispam: 1UD129KBjvJXoWxAFy8KFW7GrW7WFy5uw1UGFg_yoW5Aw18pF Wxtw1ktaykJFnxGas2gw4xWayFvrZ5Gw4UGFn8JrWvywn8ZFnavryIkay5Way3Wrn3ZF1j qr4IvFyDAan8CaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Gb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVC2j2CE jI02ccxYII8I67AEr4CY67k08wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI 0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy2 64kE64k0F24lc2xSY4AK67AK6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r 1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CE b7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0x vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI 42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0V AYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU5drcDUUUUU==
X-CM-SenderInfo: x2kd0wxfxlzxlqj6u0xqlfhubq/
Archived-At: <>
Subject: Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Apr 2022 08:38:28 -0000

Many thanks for reading the draft.

> from: "Paul Wouters" <> on Mon, 2022-04-11
> to: zhangcuiling <>
> cc: dnsop <>
> subject: Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC
> On Mon, 11 Apr 2022, zhangcuiling wrote:
> > And the main purpose is to improve the diversity of DNSSEC algorithms, and to make it convenient for people who want to use SM2
> > digital signature algorithm as an alternative for DNSSEC.
> We actually want to prevent as much diversity as we can, to avoid
> creating more new long tails of deployment of algorithms. So a new

That sounds reasonable. It does need additional work to support 
SM2 Digital Signature Algorithm for DNS software implementation. 
The good news is that Openssl has supported it since version 1.1.1. 
And I think Openssl is widely used among DNS software.

> algorithm should really offer something the others do not. Also having
> a number of ECC based algorithms would likely mean if one ends up
> broken, all of them end up broken.
> So based on:
>   Due to the similarity between SM2 and ECDSA with curve P-256, some
>   of the material in this document is copied liberally from RFC 6605
>   [RFC6605].
> I don't see a strong reason to adopt another ECC type of algorithm.

Sorry that maybe I didn't make it clear. 

About SM2 and ECDSA:
SM2 and ECDSA are similar in the following aspects: the length of the 
private key (32 octets), public key (64 octets) and the signature 
(64 octets) are the same. 
But there is an important difference between these two algorithms, 
which is the process of signature calculation. So SM2 is a different 
algorithm from ECDSA.
By the way, compared to a totally different algorithm, 
the similarity between SM2 and ECDSA can reduce the complication of 
supporting SM2 to some extent.

About the security of ECC-based algorithms:
As far as I know, the security of ECC-based algorithms is strongly 
influenced by the curve it uses. Sometimes it's hard to say which 
curve is much safer. Elliptic curve secp256r1 (for DNSSEC) and 
secp256k1 (for blockchain) are relatively popular for ECDSA. 

SM2 uses a different curve and has different process with the signature
generation and validation, so I'd like to consider it as an alternative

> Additionally, in this case SM2/SM3 seems to be ISO standards that are
> not freely available, so these are additionally problematic.

I agree with you. I should specify a document that could be downloaded freely.
Here is another one introducing SM2/SM3 in detail:
"Information security technology --- Public key cryptographic algorithm 
SM2 based on elliptic curves --- Part 2: Digital signature algorithm"
It's written in English, but unfortunately it's not an international standard.
I will keep on trying to find a more proper document.

Thank you again for your time and your helpful comment.

Best regards,

Cathy Zhang