Subject: [TLS] RFC 8998

From: Russ Housley <[email-masked]>
Date: Wed, 10 Mar 2021 16:28:32 -0500

This RFC includes:
3.3.3.  Certificate

   When a server sends the Certificate message containing the server
   certificate to the client side, several new rules are added that will
   affect the certificate selection:

   *  The public key in the certificate MUST be a valid SM2 public key.

   *  The signature algorithm used by the CA to sign the current
      certificate MUST be "sm2sig_sm3".

   *  The certificate MUST be capable of signing; e.g., the
      digitalSignature bit of X.509's Key Usage extension is set.
The object identifiers for the SM2 public key and the "sm2sig_sm3" is not provided.  Do these need paramters?
Russ

> On Mar 10, 2021, at 3:30 PM, [email-masked] wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>        RFC 8998
> 
>        Title:      ShangMi (SM) Cipher Suites for TLS 1.3 
>        Author:     P. Yang
>        Status:     Informational
>        Stream:     Independent
>        Date:       March 2021
>        Mailbox:    [email-masked]
>        Pages:      13
>        Updates/Obsoletes/SeeAlso:   None
> 
>        I-D Tag:    draft-yang-tls-tls13-sm-suites-06.txt
> 
>        URL:        https://www.rfc-editor.org/info/rfc8998
> 
>        DOI:        10.17487/RFC8998
> 
> This document specifies how to use the ShangMi (SM) cryptographic
> algorithms with Transport Layer Security (TLS) protocol version 1.3.
> 
> The use of these algorithms with TLS 1.3 is not endorsed by the IETF.
> The SM algorithms are becoming mandatory in China, so this document
> provides a description of how to use the SM algorithms with TLS 1.3
> and specifies a profile of TLS 1.3 so that implementers can produce
> interworking implementations.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC

---

From: "Paul Yang" <[email-masked]>
Date: Thu, 11 Mar 2021 15:41:35 +0800

Well, the “sm2sig_sm3” OID is defined in a Chinese national standard named GM/T 0006-2012, as an appendix. The English translation of the appendix is: http://gmssl.org/docs/oid.html <http://gmssl.org/docs/oid.html>. Those OIDs are listed on http://www.oid-info.com/ <http://www.oid-info.com/> as well.

In the OID definition table, sm2sig_sm3 is defined as ‘1.2.156.10197.1.501’.

For the SM2 public key type, there is no OID definition yet. This is because an SM2 public key is actually an ECC key with a special curve and a specific key generation method which has subtle differences from ECDSA. In OpenSSL we have summarized this before: https://github.com/openssl/openssl/issues/8435#issuecomment-481540010 <https://github.com/openssl/openssl/issues/8435#issuecomment-481540010>

So in an SM2 certificate, the public key type is still id-ecPublickey but with a special curve named sm2p256v1. Sm2p256v1 is also defined in the above OID table originated from GM/T 0006-2012.

The reason that I didn’t include these OID stuffs into this RFC is that I think these stuffs are related to digital certificate realm instead of TLS. Besides, we have discussed before in OpenSSL project if we need to have a standalone SM2 public key type instead of re-using id-ecPublickey’s OID. But related work are still in progress, so there is still no conclusion yet.

Regards,

Paul Yang

> On Mar 11, 2021, at 5:28 AM, Russ Housley <[email-masked]> wrote:
> 
> This RFC includes:
> 3.3.3.  Certificate
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls