3. Structure of the Raw Public Key Extension

3. Structure of the Raw Public Key Extension

This section defines the two TLS extensions client_certificate_type and server_certificate_type, which can be used as part of an extended TLS handshake when raw public keys are used. Section 4 defines the behavior of the TLS client and the TLS server using these extensions.

This specification uses raw public keys whereby the already available encoding used in a PKIX certificate in the form of a SubjectPublicKeyInfo structure is reused. To carry the raw public key within the TLS handshake, the Certificate payload is used as a container, as shown in Figure 1. The shown Certificate structure is an adaptation of its original form [RFC5246].

   opaque ASN.1Cert<1..2^24-1>;

   struct {
       select(certificate_type){

            // certificate type defined in this document.
            case RawPublicKey:
              opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;

           // X.509 certificate defined in RFC 5246
           case X.509:
             ASN.1Cert certificate_list<0..2^24-1>;

           // Additional certificate type based on
           // "TLS Certificate Types" subregistry
       };
   } Certificate;

Figure 1: Certificate Payload as a Container for the Raw Public Key

The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC 5280 [PKIX] and not only contains the raw keys, such as the public exponent and the modulus of an RSA public key, but also an algorithm identifier. The algorithm identifier can also include parameters. The SubjectPublicKeyInfo value in the Certificate payload MUST contain the DER encoding [X.690] of the SubjectPublicKeyInfo. The structure, as shown in Figure 2, therefore also contains length information. An example is provided in Appendix A.

      SubjectPublicKeyInfo  ::=  SEQUENCE  {
           algorithm               AlgorithmIdentifier,
           subjectPublicKey        BIT STRING  }

      AlgorithmIdentifier   ::=  SEQUENCE  {
           algorithm               OBJECT IDENTIFIER,
           parameters              ANY DEFINED BY algorithm OPTIONAL  }

Figure 2: SubjectPublicKeyInfo ASN.1 Structure

The algorithm identifiers are Object Identifiers (OIDs). RFC 3279 [RFC3279] and RFC 5480 [RFC5480], for example, define the OIDs shown in Figure 3. Note that this list is not exhaustive, and more OIDs may be defined in future RFCs.

   Key Type            | Document                   | OID
   --------------------+----------------------------+-------------------
   RSA                 | Section 2.3.1 of RFC 3279  | 1.2.840.113549.1.1
   ....................|............................|...................
   Digital Signature   |                            |
   Algorithm (DSA)     | Section 2.3.2 of RFC 3279  | 1.2.840.10040.4.1
   ....................|............................|...................
   Elliptic Curve      |                            |
   Digital Signature   |                            |
   Algorithm (ECDSA)   | Section 2 of RFC 5480      | 1.2.840.10045.2.1
   --------------------+----------------------------+-------------------

Figure 3: Example Algorithm Object Identifiers

The extension format for extended client and server hellos, which uses the "extension_data" field, is used to carry the ClientCertTypeExtension and the ServerCertTypeExtension structures. These two structures are shown in Figure 4. The CertificateType structure is an enum with values taken from the "TLS Certificate Types" subregistry of the "Transport Layer Security (TLS) Extensions" registry [TLS-Ext-Registry].

   struct {
           select(ClientOrServerExtension) {
               case client:
                 CertificateType client_certificate_types<1..2^8-1>;
               case server:
                 CertificateType client_certificate_type;
           }
   } ClientCertTypeExtension;

   struct {
           select(ClientOrServerExtension) {
               case client:
                 CertificateType server_certificate_types<1..2^8-1>;
               case server:
                 CertificateType server_certificate_type;
           }
   } ServerCertTypeExtension;

Figure 4: CertTypeExtension Structure