DomainKeys Identified Mail (DKIM) Signatures with SM2 and SM3 Cryptographic Algorithms
draft-xie-dkim-sm2-sm3-00

Network Working Group                                             J. Xie
Internet-Draft                                                     A. Hu
Updates: 6376 (if approved)                                        CNNIC
Intended status: Standards Track                                 W. Wang
Expires: 3 May 2027                                                S. Hu
                University of Electronic Science and Technology of China
                                                                 J. Wang
                                                                   CNNIC
                                                         30 October 2026

     DomainKeys Identified Mail (DKIM) Signatures with SM2 and SM3
                        Cryptographic Algorithms
                       draft-xie-dkim-sm2-sm3-00

Abstract

   This document adds the SM2-SM3 signing algorithm to DomainKeys
   Identified Mail (DKIM).  It defines the signature and public key
   encodings and the SM2 user identifier used with this algorithm.  This
   document updates RFC 6376.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Comments on this individual Internet-Draft are welcome.  Please send
   feedback to the authors using the contact information at the end of
   this document.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 May 2027.

Xie, et al.                Expires 3 May 2027                   [Page 1]
Internet-Draft            DKIM with SM2 and SM3             October 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  SM2-SM3 Signing Algorithm . . . . . . . . . . . . . . . . . .   3
     3.1.  Header Signature Input  . . . . . . . . . . . . . . . . .   4
     3.2.  SM2 User Identifier and Identity Digest . . . . . . . . .   5
       3.2.1.  Context-Aware Identifier  . . . . . . . . . . . . . .   5
       3.2.2.  Compatibility Identifier  . . . . . . . . . . . . . .   5
       3.2.3.  Identity Digest . . . . . . . . . . . . . . . . . . .   6
   4.  Signature and Key Syntax  . . . . . . . . . . . . . . . . . .   6
     4.1.  Signature Syntax  . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Key Syntax  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Signature Encoding  . . . . . . . . . . . . . . . . . . .   7
   5.  Choice and Strength of Keys and Algorithms  . . . . . . . . .   8
   6.  Transition Considerations . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.1.  Identifier Binding and Compatibility  . . . . . . . . . .   9
     7.2.  Validation and Operational Limits . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  DKIM Key Type . . . . . . . . . . . . . . . . . . . . . .  10
     8.2.  DKIM Hash Algorithms  . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Example of a Signed Message  . . . . . . . . . . . .  12
     A.1.  Secret Key  . . . . . . . . . . . . . . . . . . . . . . .  12
     A.2.  Public Key DNS Record . . . . . . . . . . . . . . . . . .  12
     A.3.  Signed Message  . . . . . . . . . . . . . . . . . . . . .  12
     A.4.  Verification Inputs . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Xie, et al.                Expires 3 May 2027                   [Page 2]
Internet-Draft            DKIM with SM2 and SM3             October 2026

1.  Introduction

   DKIM [RFC6376] associates a signing domain with selected message
   header fields and a body hash.  A verifier obtains the public key
   from the DNS using the domain and selector in the DKIM-Signature
   header field.

   This document adds SM2 with SM3 as a DKIM signing algorithm,
   following the algorithm extension approach used for Ed25519 in
   [RFC8463].  It defines the SM2 message input, user identifier,
   signature encoding, and key encoding.  The DKIM updates in [RFC8301],
   [RFC8463], [RFC8553], and [RFC8616] continue to apply, with the
   algorithm-specific tag representation requirement in Section 3.2.

   The extension adds algorithm choices to Section 3.3 and syntax to
   Sections 3.5 and 3.6.1 of [RFC6376].  It defines the SM2 header
   hashing and signing operation for Section 3.7 while retaining that
   section's header-input construction.  No SMTP extension is required.
   Appendix A provides a test key, its DNS record, and a signed message.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Syntax uses ABNF [RFC5234] and DKIM terminology from [RFC6376]. ||
   denotes octet-string concatenation.  Base64 is the encoding in
   Section 4 of [RFC4648], with DKIM's folding whitespace rules.

   ID is the SM2 user identifier; ZA is the identity digest derived from
   ID, the curve parameters, and the public key.  Neither value is the
   DKIM Agent or User Identifier (AUID) in the i= tag.

3.  SM2-SM3 Signing Algorithm

   SM2 is the digital signature algorithm in [GB-T-32918.2].  SM3 is the
   256-bit hash algorithm in [GB-T-32905].  Implementations MUST use the
   following curve over the prime field with modulus p, with equation
   y^2 = x^3 + a*x + b (mod p), base point G = (xG, yG), and group order
   n.  Other curves MUST NOT be used with this algorithm.

   The parameter values are hexadecimal; spaces and line breaks are for
   display only:

Xie, et al.                Expires 3 May 2027                   [Page 3]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
        FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
   a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
        FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
   b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
        F39789F5 15AB8F92 DDBCBD41 4D940E93
   xG = 32C4AE2C 1F198119 5F990446 6A39C994
        8FE30BBF F2660BE1 715A4589 334C74C7
   yG = BC3736A2 F4F6779C 59BDCEE3 6B692153
        D0A9877C C62A4740 02DF32E5 2139F0A0
   n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
        7203DF6B 21C6052B 53BBF409 39D54123

   These are also the SM2 parameters listed in Section 3 of [RFC9563],
   which describes their use in DNSSEC.  The encodings and identifier
   used for DKIM are defined by this document.

   For a=sm2-sm3, the body hash is computed as specified in [RFC6376],
   using SM3.  The Base64 encoding of the 32-octet digest is placed in
   bh=. The body hash does not include ZA.

3.1.  Header Signature Input

   Let M be the canonicalized header input constructed under Section 3.7
   of [RFC6376].  The b= value and its surrounding folding whitespace
   are removed from the DKIM-Signature field being signed or verified.
   That field is last in M and MUST NOT contribute a trailing CRLF.

   SM2 MUST sign M as its message, using the identifier in Section 3.2.
   The digest used by the SM2 signature calculations is:

   e = SM3(ZA || M)

   An SM2 message-signing API that computes this digest internally MUST
   receive M, not SM3(M).  Supplying SM3(M) would instead produce
   SM3(ZA || SM3(M)), which is a different algorithm.  A digest-signing
   API can be used if it receives the correct e without hashing it again
   or adding ZA again.

   The resulting signature is encoded as specified in Section 4.3 and
   placed in b=. Verification reconstructs the same M, checks bh=, and
   verifies the SM2 signature with the public key in Section 4.2.  The
   remaining signature and key checks, including failure handling,
   follow [RFC6376].

Xie, et al.                Expires 3 May 2027                   [Page 4]
Internet-Draft            DKIM with SM2 and SM3             October 2026

3.2.  SM2 User Identifier and Identity Digest

3.2.1.  Context-Aware Identifier

   The primary SM2 user identifier uses the parsed s= and d= values in
   the DKIM-Signature header field:

   ID = ASCII(selector) || 0x40 || ASCII(domain)

   The 0x40 octet is the ASCII at sign.  Implementations MUST use the
   ASCII tag values after removing permitted syntactic folding
   whitespace.  They MUST NOT append a terminating NUL, add a trailing
   DNS root dot, change letter case, or apply DNS name compression.

   For this algorithm, signers MUST represent internationalized names in
   s= and d= using ASCII A-labels, including in messages with
   internationalized header fields.  A-labels remain valid under
   [RFC8616].  A verifier MUST reject a signature containing a Unicode
   U-label in either tag before attempting SM2 verification; it MUST NOT
   translate those tag values into a different form and then retry.
   This restriction keeps the identifier input in the exact ASCII form
   above and does not change the processing of other header fields under
   [RFC8616].

   For s=k1 and d=example.com, ID is k1@example.com.  The i= tag does
   not participate in this construction.

   ID's bit length MUST fit the 16-bit SM2 ENTL field.  An octet-aligned
   ID therefore permits at most 8191 octets.  Longer identifiers MUST be
   rejected.

3.2.2.  Compatibility Identifier

   A signer SHOULD use the context-aware identifier.  A signer whose
   cryptographic provider cannot accept that identifier MAY use these 16
   ASCII octets as a compatibility identifier:

   1234567812345678

   A verifier MUST first attempt SM2 verification with the context-aware
   identifier.  If that cryptographic verification fails, it MUST make
   one further attempt with the compatibility identifier before
   reporting a signature mismatch.  It MUST NOT try arbitrary locally
   configured identifiers.  Syntax errors, unusable keys, and body hash
   mismatches MUST NOT trigger an identifier retry.

Xie, et al.                Expires 3 May 2027                   [Page 5]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   This behavior accommodates fixed-identifier providers, but successful
   verification does not prove that the signer used the context-aware
   identifier.  See Section 7.1 for the tradeoff.

3.2.3.  Identity Digest

   The SM2 identity digest MUST be computed as specified in
   [GB-T-32918.2]:

   ZA = SM3(ENTL || ID || a || b || xG || yG || xA || yA)

   ENTL is ID's length in bits as a two-octet unsigned big-endian
   integer.  The curve coefficients a and b, base-point coordinates xG
   and yG, and public key coordinates xA and yA each occupy 32 octets as
   unsigned big-endian integers.  These are field elements, not
   hexadecimal text or ASN.1 encodings.  The full public key coordinates
   are used even when the point was transported in compressed form.

4.  Signature and Key Syntax

4.1.  Signature Syntax

   The algorithm syntax in Section 3.5 of [RFC6376] is extended as
   follows:

   sig-a-tag-k =/ "sm2"
   sig-a-tag-h =/ "sm3"

   The combination defined here is a=sm2-sm3.  Other combinations using
   these new tokens are not defined by this document.

4.2.  Key Syntax

   The key syntax in Section 3.6.1 of [RFC6376] is extended as follows:

   key-k-tag-type =/ "sm2"
   key-h-tag-alg  =/ "sm3"

   A key for a=sm2-sm3 MUST have an explicit k=sm2 tag.  If the key
   record has an h= restriction, its list MUST include sm3.

   For k=sm2, a nonempty p= value MUST contain the Base64 encoding of
   one DER-encoded SubjectPublicKeyInfo structure using the structure
   and EC point representation described in [RFC5480], with these
   choices:

   *  The algorithm object identifier is id-ecPublicKey
      (1.2.840.10045.2.1).

Xie, et al.                Expires 3 May 2027                   [Page 6]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   *  The parameters field contains the named curve object identifier
      1.2.156.10197.1.301 for the SM2 curve.

   *  The subjectPublicKey BIT STRING has zero unused bits and contains
      a compressed EC point of exactly 33 octets.

   The point encoding is 0x02 when Y is even or 0x03 when Y is odd,
   followed by the 32-octet, unsigned, big-endian X coordinate.  Leading
   zero octets in X MUST be retained.  Compressed-point support is
   required for this DKIM profile even when a provider's other
   applications use uncompressed points.

   Signers MUST publish compressed points.  Verifiers MUST support
   compressed points and MAY reject uncompressed points for this key
   type.  If accepted, an uncompressed point MUST use 0x04 || X || Y,
   with 32 octets per coordinate and the same algorithm and curve
   identifiers.  Hybrid points and the point at infinity MUST NOT be
   accepted.

   Verifiers MUST reject malformed DER, unexpected object identifiers,
   trailing data, and invalid public points.  Point decompression and
   public key validation MUST establish that the result is a nonidentity
   member of the specified group before using it for verification.

   An empty p= revokes the key under [RFC6376].  It MUST NOT be
   interpreted as an empty encoded public key.

   The required compressed SubjectPublicKeyInfo occupies 59 DER octets
   and 80 Base64 characters.  This reduces key size relative to an
   uncompressed point, but does not guarantee that every DNS response
   will fit a particular transport size limit.

4.3.  Signature Encoding

   An SM2 signature consists of integers r and s.  The b= tag MUST
   contain the Base64 encoding of the DER encoding of this ASN.1
   structure:

   SM2Signature ::= SEQUENCE {
       r INTEGER,
       s INTEGER
   }

Xie, et al.                Expires 3 May 2027                   [Page 7]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   Both integers MUST be in the range 1 through n - 1, where n is the
   SM2 group order.  DER INTEGER values use the minimal signed encoding;
   a leading zero octet is required when needed to represent a positive
   integer.  Verifiers MUST reject negative, zero, out-of-range, or
   nonminimally encoded values, extra sequence members, and trailing
   data.

   This differs from DNSSEC's fixed-length, 64-octet r || s format in
   Section 4.2 of [RFC9563].  Verifiers MUST NOT accept that raw format
   as an alternative encoding for b=.

5.  Choice and Strength of Keys and Algorithms

   Support for SM2-SM3 is OPTIONAL.  An implementation claiming support
   for signing or verifying it MUST implement the corresponding
   procedures and encodings in this document.  This extension does not
   replace existing DKIM algorithm requirements, including the updates
   in [RFC8301] and [RFC8463].

   The curve has 256-bit field elements, and SM3 produces a 256-bit
   digest.  These sizes do not establish equivalence or superiority to
   other DKIM algorithms.  Algorithm choice remains a deployment policy
   decision.

6.  Transition Considerations

   Signers can attach an SM2-SM3 signature alongside a signature using
   an existing DKIM algorithm.  Each algorithm uses a different selector
   and key record; the signatures can use the same d= and i= identities.
   Each signature is verified independently under [RFC6376].

   During key rollover, old and new selectors can coexist so that
   messages signed before the change remain verifiable.  Operators need
   to account for message delivery time and DNS caching when retiring an
   old key.

   Providers need to use the specified SM2 identifier for each signing
   context.  The compatibility procedure in Section 3.2 accommodates
   providers restricted to the fixed identifier; it does not remove
   other DKIM verification requirements.

Xie, et al.                Expires 3 May 2027                   [Page 8]
Internet-Draft            DKIM with SM2 and SM3             October 2026

7.  Security Considerations

   The security considerations of [RFC6376] continue to apply.  SM2
   signers MUST generate the secret per-signature scalar with a
   cryptographically secure random source and follow the generation and
   retry rules in [GB-T-32918.2].  Reuse or predictability can expose
   the private key.  Implementations MUST protect private keys and
   secret intermediates and SHOULD use providers that resist side-
   channel attacks.

7.1.  Identifier Binding and Compatibility

   The context-aware ID binds ZA to a selector and domain, but does not
   contain an explicit protocol label.  Accepting the compatibility ID
   means that not every successful signature used the context-aware ID.
   Neither choice establishes complete cross-protocol isolation.
   Operators SHOULD use dedicated DKIM keys instead of reusing an SM2
   private key across unrelated protocols.

   The d= and s= tags remain in the signed header input even when the
   compatibility ID is used.  A retry MUST NOT alter them, omit the
   signature field, or bypass a failed body hash or key check.

7.2.  Validation and Operational Limits

   Public point validation and strict DER parsing are required as
   specified in Section 4.  Implementations SHOULD bound message
   processing, DNS processing, signature count, and verification work.
   This profile permits at most two SM2 verification attempts per
   otherwise usable signature.

   Compressed keys reduce record size; they do not authenticate DNS
   answers or guarantee that a DNS response fits a particular transport
   limit.  The risks associated with DKIM's l= tag and unauthenticated
   appended content also continue to apply.  If weaknesses are found in
   SM2 or SM3, operators need to migrate keys and algorithms.

8.  IANA Considerations

   IANA is requested to add these entries within "DomainKeys Identified
   Mail (DKIM) Parameters" [IANA-DKIM].

   The existing _domainkey DNS node is reused.  No additional
   underscored node registration is requested under [RFC8553].

Xie, et al.                Expires 3 May 2027                   [Page 9]
Internet-Draft            DKIM with SM2 and SM3             October 2026

8.1.  DKIM Key Type

              +======+============================+========+
              | Type | Reference                  | Status |
              +======+============================+========+
              | sm2  | This document, Section 4.2 | active |
              +------+----------------------------+--------+

                                 Table 1

8.2.  DKIM Hash Algorithms

                     +======+===============+========+
                     | Type | Reference     | Status |
                     +======+===============+========+
                     | sm3  | This document | active |
                     +------+---------------+--------+

                                  Table 2

   The combined identifier sm2-sm3 is defined by this document's
   signature syntax.  There is no separate "DKIM Signature Algorithms"
   registry in the existing registry group; this document requests no
   new registry.

9.  References

9.1.  Normative References

   [GB-T-32905]
              Standardization Administration of China, "Information
              security techniques -- SM3 cryptographic hash algorithm",
              GB/T 32905-2016, 29 August 2016,
              <https://openstd.samr.gov.cn/bzgk/gb/
              newGbInfo?hcno=45B1A67F20F3BF339211C391E9278F5E>.

   [GB-T-32918.2]
              Standardization Administration of China, "Information
              security technology -- Public key cryptographic algorithm
              SM2 based on elliptic curves -- Part 2: Digital signature
              algorithm", GB/T 32918.2-2016, 29 August 2016,
              <https://std.samr.gov.cn/gb/search/
              gbDetailed?id=pRGWJWHKqAM%3D&mode=p>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Xie, et al.                Expires 3 May 2027                  [Page 10]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/rfc/rfc4648>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
              <https://www.rfc-editor.org/rfc/rfc5480>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/rfc/rfc6376>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8301]  Kitterman, S., "Cryptographic Algorithm and Key Usage
              Update to DomainKeys Identified Mail (DKIM)", RFC 8301,
              DOI 10.17487/RFC8301, January 2018,
              <https://www.rfc-editor.org/rfc/rfc8301>.

   [RFC8463]  Levine, J., "A New Cryptographic Signature Method for
              DomainKeys Identified Mail (DKIM)", RFC 8463,
              DOI 10.17487/RFC8463, September 2018,
              <https://www.rfc-editor.org/rfc/rfc8463>.

   [RFC8553]  Crocker, D., "DNS Attrleaf Changes: Fixing Specifications
              That Use Underscored Node Names", BCP 222, RFC 8553,
              DOI 10.17487/RFC8553, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8553>.

   [RFC8616]  Levine, J., "Email Authentication for Internationalized
              Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019,
              <https://www.rfc-editor.org/rfc/rfc8616>.

9.2.  Informative References

   [IANA-DKIM]
              IANA, "DomainKeys Identified Mail (DKIM) Parameters",
              n.d., <https://www.iana.org/assignments/dkim-parameters/>.

Xie, et al.                Expires 3 May 2027                  [Page 11]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   [RFC9563]  Zhang, C., Liu, Y., Leng, F., Zhao, Q., and Z. He, "SM2
              Digital Signature Algorithm for DNSSEC", RFC 9563,
              DOI 10.17487/RFC9563, December 2024,
              <https://www.rfc-editor.org/rfc/rfc9563>.

Appendix A.  Example of a Signed Message

   This appendix provides a public verification example.  The key is for
   testing only and MUST NOT authenticate production messages.  SM2
   signatures are randomized; signing the same input can produce another
   valid signature.  The displayed t= is historical test data, not a
   claim about when this document was prepared.

A.1.  Secret Key

   The following PKCS #8 PEM key is intentionally published for this
   test example.  It corresponds to the public key in Appendix A.2 and
   MUST NOT be used to authenticate production messages.

   -----BEGIN PRIVATE KEY-----
   MIGHAgEAMBMGByqGSM49AgEGCCqBHM9VAYItBG0wawIBAQQgtXPjROYO6eJ0xpIv
   Q2pF4FFMQPAGFg+E2LiGtC4oDeOhRANCAARMb4fKF0X2wu6E5/M5xVFoMG9Q9IE4
   KLZUbbAreZuaD3CbjMvCLaa7rlwOSMUJvg1qBgEYj572RcdWr6L+9dkV
   -----END PRIVATE KEY-----

A.2.  Public Key DNS Record

   The quoted strings form one TXT record and are concatenated without
   inserting whitespace:

   sm2._domainkey.football.example.com. 3600 IN TXT (
     "v=DKIM1; k=sm2; p="
     "MDkwEwYHKoZIzj0CAQYIKoEcz1UBgi0DIgADTG+HyhdF9sLuhOfz"
     "OcVRaDBvUPSBOCi2VG2wK3mbmg8="
   )

A.3.  Signed Message

   Each displayed line ends with CRLF, including the last body line.
   DKIM-Signature continuation lines begin with one space.

Xie, et al.                Expires 3 May 2027                  [Page 12]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   DKIM-Signature: v=1; a=sm2-sm3; c=relaxed/relaxed;
    d=football.example.com; i=@football.example.com;
    q=dns/txt; s=sm2; t=1528637909;
    h=from:to:subject:date:message-id;
    bh=CjilxR9ltODIjw8xJGWrdn3kjU6qds8AgqPeu3REZ9U=;
    b=MEUCIBc6Q5FyKBrnAHeL9q+9RIioEFc3SCFzy7lNeYTGUbMcAiEAolrdqTdZ+sWY
    IWnwsBXYElu6NovZEOfQpfVsJTZIx80=
   From: Joe SixPack <joe@football.example.com>
   To: Suzie Q <suzie@shopping.example.net>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <20030712040037.46341.5F8J@football.example.com>

   Hi.
   We lost the game.
   Are you hungry yet?
   Joe.

A.4.  Verification Inputs

   ID is sm2@football.example.com, 24 octets long; ENTL is 00c0 in
   hexadecimal.  The relaxed body input is 51 octets.  Its Base64 SM3
   digest is:

   CjilxR9ltODIjw8xJGWrdn3kjU6qds8AgqPeu3REZ9U=

   The canonicalized header input M is 434 octets.  Its Base64 encoding
   follows; concatenate the lines before decoding:

   ZnJvbTpKb2UgU2l4UGFjayA8am9lQGZvb3RiYWxsLmV4YW1wbGUuY29tPg0KdG86
   U3V6aWUgUSA8c3V6aWVAc2hvcHBpbmcuZXhhbXBsZS5uZXQ+DQpzdWJqZWN0Oklz
   IGRpbm5lciByZWFkeT8NCmRhdGU6RnJpLCAxMSBKdWwgMjAwMyAyMTowMDozNyAt
   MDcwMCAoUERUKQ0KbWVzc2FnZS1pZDo8MjAwMzA3MTIwNDAwMzcuNDYzNDEuNUY4
   SkBmb290YmFsbC5leGFtcGxlLmNvbT4NCmRraW0tc2lnbmF0dXJlOnY9MTsgYT1z
   bTItc20zOyBjPXJlbGF4ZWQvcmVsYXhlZDsgZD1mb290YmFsbC5leGFtcGxlLmNv
   bTsgaT1AZm9vdGJhbGwuZXhhbXBsZS5jb207IHE9ZG5zL3R4dDsgcz1zbTI7IHQ9
   MTUyODYzNzkwOTsgaD1mcm9tOnRvOnN1YmplY3Q6ZGF0ZTptZXNzYWdlLWlkOyBi
   aD1DamlseFI5bHRPRElqdzh4SkdXcmRuM2tqVTZxZHM4QWdxUGV1M1JFWjlVPTsg
   Yj0=

   Decoded M has no CRLF after its final b=. For this public key and ID,
   ZA and e = SM3(ZA || M) are, in hexadecimal:

   ZA = 2940ad2fb8df156eb21183807ecc1c1dc808e0bb93d15dae0a15783573a7e940
   e  = 2dc20ac757e01992d7241f93c8e89210e00051703235f0d087629c292ff30de7

Xie, et al.                Expires 3 May 2027                  [Page 13]
Internet-Draft            DKIM with SM2 and SM3             October 2026

   Decode p= to public-key.der, b= to signature.der, and the header
   input above to header-input.bin.  An example invocation with an
   SM2-capable OpenSSL provider is:

   openssl pkeyutl -verify -pubin -inkey public-key.der \
     -keyform DER -in header-input.bin -sigfile signature.der \
     -rawin -digest sm3 \
     -pkeyopt distid:sm2@football.example.com

   This checks the SM2 signature only.  Full DKIM verification also
   requires the message, body hash, DNS record, and tag checks specified
   above.

Authors' Addresses

   Jieling Xie
   CNNIC
   Email: xiejieling@cnnic.cn

   Anlei Hu
   CNNIC
   Email: huanlei@cnnic.cn

   Wenyong Wang
   University of Electronic Science and Technology of China
   Email: wywang@uestc.edu.cn

   Shuisong Hu
   University of Electronic Science and Technology of China
   Email: hi.shuisong@gmail.com

   Jiushuang Wang
   CNNIC
   Email: wangjiushuang@cnnic.cn

Xie, et al.                Expires 3 May 2027                  [Page 14]