[Proposal] Integrate Support for Chinese National Standards (SM2, SM3, SM4) to Enhance RFC 8998 and WebPKI Compatibility

[kintaiW]

Motivation
The adoption of Chinese National Standards (GuoMi) is rapidly increasing, particularly in China's government, finance, and IoT sectors. With the release of RFC 8998 ("Transport Layer Security (TLS) Protocol Version 1.3 Support for Cryptographic Algorithms from the People's Republic of China"), a standardized method for using SM2, SM3, and SM4 in TLS 1.3 has been established.
Currently, the Rust ecosystem lacks a high-assurance, no_std-compatible, and thoroughly-audited implementation of these algorithms that seamlessly integrates with webpki certificate verification. Integrating native support into ring would:
Enable Rust apps to authenticate SM2-signed certificates in WebPKI.
Provide a secure foundation for TLS 1.3 implementations (e.g., rustls) to support RFC 8998 cipher suites.
Unify the cryptographic backend for Chinese compliance under ring's security model.
Proposed Implementation Strategy
I recognize ring's strict policy against external C dependencies and FFI. Thus, I propose a "Vendor-in" approach, leveraging an existing high-quality pure Rust implementation as a base, which will be extensively refactored to meet ring's coding standards.
Source Baseline: libsmx (Pure Rust, Apache-2.0 licensed).
Integration Method:
Incorporate core algorithm logic directly into ring's source tree (e.g., src/sm2, src/sm3, src/sm4).
Remove all external crate dependencies; integrate code into ring itself.
Refactor error handling to match ring's Result/Unspecified pattern.
Ensure all operations are constant-time and side-channel attack-resistant, aligning with ring's security guarantees.
Implement necessary traits (SignatureAlgorithm, DigestAlgorithm, AeadAlgorithm) for public API access.
Technical Scope
Initial scope includes:
SM3: Hash function (compatible with ring::digest).
SM4: Block cipher and AEAD modes (compatible with ring::aead).
SM2:
Elliptic Curve operations (key generation, ECDH).
Digital Signature Algorithm (compatible with ring::signature).
OID Registration: Register standard OIDs (e.g., 1.2.156.10197.1.301 for SM2) for webpki to recognize and verify SM2 certificates.
Note: SM9 (Identity-Based Cryptography) is excluded from this initial proposal due to architectural differences but can be considered separately.
Questions for Maintainers
Before proceeding with a Proof of Concept (PoC) PR, I seek alignment on:
Acceptance Criteria: Is the "Vendor-in pure Rust code" strategy acceptable, assuming rigorous review for constant-time correctness and style?
API Design: Any preferences for presenting SM2 signatures (e.g., emulate existing ECDSA API)?
RFC 8998 Alignment: Is supporting RFC 8998 cipher suites a priority?
I am ready to handle most implementation, refactoring, and testing, subject to your guidance and review.
Thank you for considering this proposal to boost ring's global interoperability.