How to encode the C509 name in CertificateAuthorities in TLS

[xipki]

Both TLS 1.2 (RFC 5246), TLS 1.3 (RFC 8446) and RFC 6066 requires the certificate authorities to be encoded as DER-encoded X.501 distinguished name.

1. A straightforward idea is to convert the C509 name to the DER-encoded X.501 name, this however 1) requires complicated conversion between both formats, and 2) it is difficult to distinguish from the real X.501 name (it is possible to have both C.509 and X.509 certificate authorities if both certificate types are supported in one handshake).

2. Another idea is to define a new Attribute Type (say id-c509-name) with the encoded C509-name binary as the content. This solves the problems above.
   For this solution, a new OBJECT IDENTIFIER id-c509-name needs to be applied at IANA.

For better understanding, below are the snippets from the TLS specifications:

Section 7.4.4 in RFC 5246:

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

certificate_authorities
      A list of the distinguished names [X501] of acceptable
      certificate_authorities, represented in DER-encoded format.  These
      distinguished names may specify a desired distinguished name for a
      root CA or for a subordinate CA; thus, this message can be used to
      describe known roots as well as a desired authorization space.  If
      the certificate_authorities list is empty, then the client MAY
      send any certificate of the appropriate ClientCertificateType,
      unless there is some external arrangement to the contrary.

Section 4.2.4 in RFC 8446:

struct {
          DistinguishedName authorities<3..2^16-1>;
      } CertificateAuthoritiesExtension;

   authorities:  A list of the distinguished names [X501] of acceptable
      certificate authorities, represented in DER-encoded [X690] format.
      These distinguished names specify a desired distinguished name for
      a trust anchor or subordinate CA; thus, this message can be used
      to describe known trust anchors as well as a desired authorization
      space.

   The client MAY send the "certificate_authorities" extension in the
   ClientHello message.  The server MAY send it in the
   CertificateRequest message.

Section 6 in RFC 6066:

   In order to indicate which CA root keys they possess, clients MAY
   include an extension of type "trusted_ca_keys" in the (extended)
   client hello.  The "extension_data" field of this extension SHALL
   contain "TrustedAuthorities" where:

      struct {
          TrustedAuthority trusted_authorities_list<0..2^16-1>;
      } TrustedAuthorities;

      struct {
          IdentifierType identifier_type;
          select (identifier_type) {
              case pre_agreed: struct {};
              case key_sha1_hash: SHA1Hash;
              case x509_name: DistinguishedName;
              case cert_sha1_hash: SHA1Hash;
          } identifier;
      } TrustedAuthority;

     ...
-  "x509_name": contains the DER-encoded X.509 DistinguishedName of
      the CA.

[xipki]

Following the second idea, let id-c509-name be "1.3.6.1.4.1.45522.4.1" (an OID under my private PEN number), and we have the C509 subject "CN=rsa test CA" which is CBOR encoded as follows:

6B                        # text(11)
   6563632D63612074657374 # "ecc-ca test"

Then the corresponding X500 Name is as follows:

301E311C301A060A2B0601040182E3520401040C6B6563632D63612074657374

The dumped output is:

0:d=0  hl=2 l=  30 cons: SEQUENCE
  # 30 (SEQUENCE) 1E (length 30)       
2:d=1  hl=2 l=  28 cons:  SET
    # 31 (SET) 1C (length 28)
4:d=2  hl=2 l=  26 cons:   SEQUENCE
      # 30 (SEQUENCE) 1A (length 26)     
6:d=3  hl=2 l=  10 prim:    OBJECT            :1.3.6.1.4.1.45522.4.1 
        # 06 (OID) 0A (length 10)
        #  2B0601040182E3520401 (1.3.6.1.4.1.45522.4.1) 
18:d=3  hl=2 l=  12 prim:    OCTET STRING      :kecc-ca test       
        # 04 (OCTET STRING) 0C (length 12)
        #   6B6563632D63612074657374 (the CBOR encoded C509 subject)

I tested this in the extensions trusted_ca_keys (TLS 1.2) and certificate_authorities (TLS 1.3), and in the CertificateRequest (TLS 1.2 & 1.3) using adapted (bcgit/bc-java#2165) bouncycastle tls library.

[xipki]

wireshark-localhost-tls.pcapng.zip

This is the wireshark capture file for a complete TLS 1.2 handshake with client certificate authentication using C509 certificates.

• Packet 1: Client Hello
  • Extensions server_certificate_type and client_certificate_type: contains list of certificate types consisting of single value 3 (not registered anywhere, I use it just for test purpose) for the type C509 certificate
  • Extension trusted_ca_keys: contains two entries for the CA's subject (CN=ecc-ca test and CN=rsa-ca test).
• Packet 2: Server Hello
  • Extensions server_certificate_type and client_certificate_type: contains the certificate type (value 3) selected by the server.
• Packet 3: Certificate
  • Payload is the server's C509 certificate
• Packet 5: CertificateRequest
  • Distinguished Names: Contains two entries for the CA's subject (CN=ecc-ca test and CN=rsa-ca test).
• Packet 7:
  • Payload is the client's C509 certificate