]> CNNIC

xiejieling@cnnic.cn

CNNIC

huanlei@cnnic.cn

University of Electronic Science and Technology of China

wywang@uestc.edu.cn

University of Electronic Science and Technology of China

hi.shuisong@gmail.com

CNNIC

wangjiushuang@cnnic.cn

Security Network Working Group DKIM SM2 SM3 email authentication 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 Comments on this individual Internet-Draft are welcome. Please send feedback to the authors using the contact information at the end of this document.

Introduction DKIM 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 . It defines the SM2 message input, user identifier, signature encoding, and key encoding. The DKIM updates in , , , and continue to apply, with the algorithm-specific tag representation requirement in . The extension adds algorithm choices to Section 3.3 and syntax to Sections 3.5 and 3.6.1 of . 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.

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 when, and only when, they appear in all capitals, as shown here. Syntax uses ABNF and DKIM terminology from . || denotes octet-string concatenation. Base64 is the encoding in Section 4 of , 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-SM3 Signing Algorithm SM2 is the digital signature algorithm in . SM3 is the 256-bit hash algorithm in . 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: These are also the SM2 parameters listed in Section 3 of , 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 , using SM3. The Base64 encoding of the 32-octet digest is placed in bh=. The body hash does not include ZA.

Header Signature Input Let M be the canonicalized header input constructed under Section 3.7 of . 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 . The digest used by the SM2 signature calculations is: 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 and placed in b=. Verification reconstructs the same M, checks bh=, and verifies the SM2 signature with the public key in . The remaining signature and key checks, including failure handling, follow .

SM2 User Identifier and Identity Digest

Context-Aware Identifier The primary SM2 user identifier uses the parsed s= and d= values in the DKIM-Signature header field: 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 . 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 . 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.

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: 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 for the tradeoff.

Identity Digest The SM2 identity digest MUST be computed as specified in : 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.

Signature and Key Syntax

Signature Syntax The algorithm syntax in Section 3.5 of is extended as follows: The combination defined here is a=sm2-sm3. Other combinations using these new tokens are not defined by this document.

Key Syntax The key syntax in Section 3.6.1 of is extended as follows: 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 , 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 . 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.

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: 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 . Verifiers MUST NOT accept that raw format as an alternative encoding for b=.

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 and . 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.

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 . 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 accommodates providers restricted to the fixed identifier; it does not remove other DKIM verification requirements.

Security Considerations The security considerations of 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 . 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.

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.

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.

IANA Considerations IANA is requested to add these entries within "DomainKeys Identified Mail (DKIM) Parameters" . The existing _domainkey DNS node is reused. No additional underscored node registration is requested under .

DKIM Key Type

Type	Reference	Status
sm2	This document,	active

DKIM Hash Algorithms

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.

References Normative References DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm. The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications. Standardization Administration of China Standardization Administration of China In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC). This document is an Independent Submission to the RFC series and does not have consensus of the IETF community. IANA n.d.

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.

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

Public Key DNS Record The quoted strings form one TXT record and are concatenated without inserting whitespace:

Signed Message Each displayed line ends with CRLF, including the last body line. DKIM-Signature continuation lines begin with one space. To: Suzie Q 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. ]]>

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: The canonicalized header input M is 434 octets. Its Base64 encoding follows; concatenate the lines before decoding: Decoded M has no CRLF after its final b=. For this public key and ID, ZA and e = SM3(ZA || M) are, in hexadecimal: 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: This checks the SM2 signature only. Full DKIM verification also requires the message, body hash, DNS record, and tag checks specified above.