On Sat, Oct 31, 2026 at 11:56:41AM +0800, 胡水松 wrote:
> We have prepared an individual Internet-Draft, "DomainKeys Identified Mail
> (DKIM) Signatures with SM2 and SM3 Cryptographic Algorithms" (
> draft-xie-dkim-sm2-sm3-00
> <https://datatracker.ietf.org/doc/draft-xie-dkim-sm2-sm3/>).
>
> The draft proposes adding SM2-SM3 as an optional DKIM signing algorithm,
> including the associated signature and public key encodings, and updates
> RFC 6376.
>
> We understand that the DCRUP WG, which previously worked on DKIM
> cryptographic algorithm updates, has concluded. We would therefore like to
> ask whether the DKIM WG would be an appropriate venue for technical review
> and discussion of this proposal.
>
> We would appreciate any feedback on the draft, or suggestions for a more
> suitable venue within the IETF.
I've looked over the draft and I'm puzzled by the two distinct choices
of the SM2 "Distinguishing Identifier" signature parameter. If the
default value of "1234567812345678" is good enough for e.g. X.509
certificate signature validation in TLS (see Section 3.2.1 of RFC 8998),
why not just always use it also for DKIM?
Or, if for some reason, domain separation via a non-default
"Distinguishing Identifier" is particularly desirable, then I think it
should be mandatory. Requiring validators to first try the specified
DKIM-specific choice and failing that the default does not make much
sense to me.
FWIW, in the OpenSSL SM2 implementation "1234567812345678" is the
default value of the "Distinguishing Identifier" as of OpenSSL 4.0, when
no explicit value is specified by the application, via e.g.
EVP_PKEY_CTX_set1_id(3) or the `OSSL_PKEY_PARAM_DIST_ID`
parameter with EVP_DigestSignInit_ex(3).
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
