| Internet-Draft | DKIM with SM2 and SM3 | October 2026 |
| Xie, et al. | Expires 3 May 2027 | [Page] |
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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].¶
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.¶
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.¶
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.¶
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.¶
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.¶
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).¶
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.¶
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
}
¶
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=.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
| Type | Reference | Status |
|---|---|---|
| sm2 | This document, Section 4.2 | active |
| Type | Reference | Status |
|---|---|---|
| sm3 | This document | active |
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.¶
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.¶
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-----¶
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=" )¶
Each displayed line ends with CRLF, including the last body line. DKIM-Signature continuation lines begin with one space.¶
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¶
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.¶