From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7250.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc7250.txt (limited to 'doc/rfc/rfc7250.txt') diff --git a/doc/rfc/rfc7250.txt b/doc/rfc/rfc7250.txt new file mode 100644 index 0000000..2eec98d --- /dev/null +++ b/doc/rfc/rfc7250.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Wouters, Ed. +Request for Comments: 7250 Red Hat +Category: Standards Track H. Tschofenig, Ed. +ISSN: 2070-1721 ARM Ltd. + J. Gilmore + Electronic Frontier Foundation + S. Weiler + Parsons + T. Kivinen + INSIDE Secure + June 2014 + + + Using Raw Public Keys in Transport Layer Security (TLS) + and Datagram Transport Layer Security (DTLS) + +Abstract + + This document specifies a new certificate type and two TLS extensions + for exchanging raw public keys in Transport Layer Security (TLS) and + Datagram Transport Layer Security (DTLS). The new certificate type + allows raw public keys to be used for authentication. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7250. + + + + + + + + + + + + + + + +Wouters, et al. Standards Track [Page 1] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Structure of the Raw Public Key Extension . . . . . . . . . . 4 + 4. TLS Client and Server Handshake Behavior . . . . . . . . . . 7 + 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Client Authentication . . . . . . . . . . . . . . . . . . 9 + 4.4. Server Authentication . . . . . . . . . . . . . . . . . . 9 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.1. TLS Server Uses a Raw Public Key . . . . . . . . . . . . 10 + 5.2. TLS Client and Server Use Raw Public Keys . . . . . . . . 11 + 5.3. Combined Usage of Raw Public Keys and X.509 Certificates 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 9.2. Informative References . . . . . . . . . . . . . . . . . 15 + Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 17 + + + + + + + + + + + + + + + +Wouters, et al. Standards Track [Page 2] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +1. Introduction + + Traditionally, TLS client and server public keys are obtained in PKIX + containers in-band as part of the TLS handshake procedure and are + validated using trust anchors based on a [PKIX] certification + authority (CA). This method can add a complicated trust relationship + that is difficult to validate. Examples of such complexity can be + seen in [Defeating-SSL]. TLS is, however, also commonly used with + self-signed certificates in smaller deployments where the self-signed + certificates are distributed to all involved protocol endpoints out- + of-band. This practice does, however, still require the overhead of + the certificate generation even though none of the information found + in the certificate is actually used. + + Alternative methods are available that allow a TLS client/server to + obtain the TLS server/client public key: + + o The TLS client can obtain the TLS server public key from a DNSSEC- + secured resource record using DNS-Based Authentication of Named + Entities (DANE) [RFC6698]. + + o The TLS client or server public key is obtained from a [PKIX] + certificate chain from a Lightweight Directory Access Protocol + [LDAP] server or web page. + + o The TLS client and server public key is provisioned into the + operating system firmware image and updated via software updates. + For example: + + Some smart objects use the UDP-based Constrained Application + Protocol [CoAP] to interact with a Web server to upload sensor + data at regular intervals, such as temperature readings. CoAP can + utilize DTLS for securing the client-to-server communication. As + part of the manufacturing process, the embedded device may be + configured with the address and the public key of a dedicated CoAP + server, as well as a public/private key pair for the client + itself. + + This document introduces the use of raw public keys in TLS/DTLS. + With raw public keys, only a subset of the information found in + typical certificates is utilized: namely, the SubjectPublicKeyInfo + structure of a PKIX certificate that carries the parameters necessary + to describe the public key. Other parameters found in PKIX + certificates are omitted. By omitting various certificate-related + structures, the resulting raw public key is kept fairly small in + comparison to the original certificate, and the code to process the + keys can be simpler. Only a minimalistic ASN.1 parser is needed; + code for certificate path validation and other PKIX-related + + + +Wouters, et al. Standards Track [Page 3] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + + processing is not required. Note, however, the SubjectPublicKeyInfo + structure is still in an ASN.1 format. To further reduce the size of + the exchanged information, this specification can be combined with + the TLS Cached Info extension [CACHED-INFO], which enables TLS peers + to exchange just fingerprints of their public keys. + + The mechanism defined herein only provides authentication when an + out-of-band mechanism is also used to bind the public key to the + entity presenting the key. + + Section 3 defines the structure of the two new 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 to + be used. Section 4 defines the behavior of the TLS client and the + TLS server. Example exchanges are described in Section 5. Section 6 + describes security considerations with this approach. Finally, in + Section 7 this document registers a new value to the IANA "TLS + Certificate Types" subregistry for the support of raw public keys. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + We use the terms "TLS server" and "server" as well as "TLS client" + and "client" interchangeably. + +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]. + + + + + + + + + + +Wouters, et al. Standards Track [Page 4] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + + 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. + + + + + + + + +Wouters, et al. Standards Track [Page 5] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + + 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 + + + + + + + + + + +Wouters, et al. Standards Track [Page 6] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +4. TLS Client and Server Handshake Behavior + + This specification extends the ClientHello and the ServerHello + messages, according to the extension procedures defined in [RFC5246]. + It does not extend or modify any other TLS message. + + Note: No new cipher suites are required to use raw public keys. All + existing cipher suites that support a key exchange method compatible + with the defined extension can be used. + + The high-level message exchange in Figure 5 shows the + client_certificate_type and server_certificate_type extensions added + to the client and server hello messages. + + client_hello, + client_certificate_type, + server_certificate_type -> + + <- server_hello, + client_certificate_type, + server_certificate_type, + certificate, + server_key_exchange, + certificate_request, + server_hello_done + certificate, + client_key_exchange, + certificate_verify, + change_cipher_spec, + finished -> + + <- change_cipher_spec, + finished + + Application Data <-------> Application Data + + Figure 5: Basic Raw Public Key TLS Exchange + +4.1. Client Hello + + In order to indicate the support of raw public keys, clients include + the client_certificate_type and/or the server_certificate_type + extensions in an extended client hello message. The hello extension + mechanism is described in Section 7.4.1.4 of TLS 1.2 [RFC5246]. + + The client_certificate_type extension in the client hello indicates + the certificate types the client is able to provide to the server, + when requested using a certificate_request message. + + + +Wouters, et al. Standards Track [Page 7] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + + The server_certificate_type extension in the client hello indicates + the types of certificates the client is able to process when provided + by the server in a subsequent certificate payload. + + The client_certificate_type and server_certificate_type extensions + sent in the client hello each carry a list of supported certificate + types, sorted by client preference. When the client supports only + one certificate type, it is a list containing a single element. + + The TLS client MUST omit certificate types from the + client_certificate_type extension in the client hello if it does not + possess the corresponding raw public key or certificate that it can + provide to the server when requested using a certificate_request + message, or if it is not configured to use one with the given TLS + server. If the client has no remaining certificate types to send in + the client hello, other than the default X.509 type, it MUST omit the + client_certificate_type extension in the client hello. + + The TLS client MUST omit certificate types from the + server_certificate_type extension in the client hello if it is unable + to process the corresponding raw public key or other certificate + type. If the client has no remaining certificate types to send in + the client hello, other than the default X.509 certificate type, it + MUST omit the entire server_certificate_type extension from the + client hello. + +4.2. Server Hello + + If the server receives a client hello that contains the + client_certificate_type extension and/or the server_certificate_type + extension, then three outcomes are possible: + + 1. The server does not support the extension defined in this + document. In this case, the server returns the server hello + without the extensions defined in this document. + + 2. The server supports the extension defined in this document, but + it does not have any certificate type in common with the client. + Then, the server terminates the session with a fatal alert of + type "unsupported_certificate". + + 3. The server supports the extensions defined in this document and + has at least one certificate type in common with the client. In + this case, the processing rules described below are followed. + + The client_certificate_type extension in the client hello indicates + the certificate types the client is able to provide to the server, + when requested using a certificate_request message. If the TLS + + + +Wouters, et al. Standards Track [Page 8] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + + server wants to request a certificate from the client (via the + certificate_request message), it MUST include the + client_certificate_type extension in the server hello. This + client_certificate_type extension in the server hello then indicates + the type of certificates the client is requested to provide in a + subsequent certificate payload. The value conveyed in the + client_certificate_type extension MUST be selected from one of the + values provided in the client_certificate_type extension sent in the + client hello. The server MUST also include a certificate_request + payload in the server hello message. + + If the server does not send a certificate_request payload (for + example, because client authentication happens at the application + layer or no client authentication is required) or none of the + certificates supported by the client (as indicated in the + client_certificate_type extension in the client hello) match the + server-supported certificate types, then the client_certificate_type + payload in the server hello MUST be omitted. + + The server_certificate_type extension in the client hello indicates + the types of certificates the client is able to process when provided + by the server in a subsequent certificate payload. If the client + hello indicates support of raw public keys in the + server_certificate_type extension and the server chooses to use raw + public keys, then the TLS server MUST place the SubjectPublicKeyInfo + structure into the Certificate payload. With the + server_certificate_type extension in the server hello, the TLS server + indicates the certificate type carried in the Certificate payload. + This additional indication enables avoiding parsing ambiguities since + the Certificate payload may contain either the X.509 certificate or a + SubjectPublicKeyInfo structure. Note that only a single value is + permitted in the server_certificate_type extension when carried in + the server hello. + +4.3. Client Authentication + + When the TLS server has specified RawPublicKey as the + client_certificate_type, authentication of the TLS client to the TLS + server is supported only through authentication of the received + client SubjectPublicKeyInfo via an out-of-band method. + +4.4. Server Authentication + + When the TLS server has specified RawPublicKey as the + server_certificate_type, authentication of the TLS server to the TLS + client is supported only through authentication of the received + client SubjectPublicKeyInfo via an out-of-band method. + + + + +Wouters, et al. Standards Track [Page 9] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +5. Examples + + Figures 6, 7, and 8 illustrate example exchanges. Note that TLS + ciphersuites using a Diffie-Hellman exchange offering forward secrecy + can be used with a raw public key, although this document does not + show the information exchange at that level with the subsequent + message flows. + +5.1. TLS Server Uses a Raw Public Key + + This section shows an example where the TLS client indicates its + ability to receive and validate a raw public key from the server. In + this example, the client is quite restricted since it is unable to + process other certificate types sent by the server. It also does not + have credentials at the TLS layer it could send to the server and + therefore omits the client_certificate_type extension. Hence, the + client only populates the server_certificate_type extension with the + raw public key type, as shown in (1). + + When the TLS server receives the client hello, it processes the + extension. Since it has a raw public key, it indicates in (2) that + it had chosen to place the SubjectPublicKeyInfo structure into the + Certificate payload (3). + + The client uses this raw public key in the TLS handshake together + with an out-of-band validation technique, such as DANE, to verify it. + + client_hello, + server_certificate_type=(RawPublicKey) // (1) + -> + <- server_hello, + server_certificate_type=RawPublicKey, // (2) + certificate, // (3) + server_key_exchange, + server_hello_done + + client_key_exchange, + change_cipher_spec, + finished -> + + <- change_cipher_spec, + finished + + Application Data <-------> Application Data + + Figure 6: Example with Raw Public Key Provided by the TLS Server + + + + + +Wouters, et al. Standards Track [Page 10] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +5.2. TLS Client and Server Use Raw Public Keys + + This section shows an example where the TLS client as well as the TLS + server use raw public keys. This is one of the use cases envisioned + for smart object networking. The TLS client in this case is an + embedded device that is configured with a raw public key for use with + TLS and is also able to process a raw public key sent by the server. + Therefore, it indicates these capabilities in (1). As in the + previously shown example, the server fulfills the client's request, + indicates this via the RawPublicKey value in the + server_certificate_type payload (2), and provides a raw public key in + the Certificate payload back to the client (see (3)). The TLS server + demands client authentication, and therefore includes a + certificate_request (4). The client_certificate_type payload in (5) + indicates that the TLS server accepts a raw public key. The TLS + client, which has a raw public key pre-provisioned, returns it in the + Certificate payload (6) to the server. + +client_hello, +client_certificate_type=(RawPublicKey) // (1) +server_certificate_type=(RawPublicKey) // (1) + -> + <- server_hello, + server_certificate_type=RawPublicKey // (2) + certificate, // (3) + client_certificate_type=RawPublicKey // (5) + certificate_request, // (4) + server_key_exchange, + server_hello_done + +certificate, // (6) +client_key_exchange, +change_cipher_spec, +finished -> + + <- change_cipher_spec, + finished + +Application Data <-------> Application Data + + Figure 7: Example with Raw Public Key provided by the TLS Server and + the Client + + + + + + + + + +Wouters, et al. Standards Track [Page 11] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +5.3. Combined Usage of Raw Public Keys and X.509 Certificates + + This section shows an example combining a raw public key and an X.509 + certificate. The client uses a raw public key for client + authentication, and the server provides an X.509 certificate. This + exchange starts with the client indicating its ability to process an + X.509 certificate, OpenPGP certificate, or a raw public key, if + provided by the server. It prefers a raw public key, since the + RawPublicKey value precedes the other values in the + server_certificate_type vector. Additionally, the client indicates + that it has a raw public key for client-side authentication (see + (1)). The server chooses to provide its X.509 certificate in (3) and + indicates that choice in (2). For client authentication, the server + indicates in (4) that it has selected the raw public key format and + requests a certificate from the client in (5). The TLS client + provides a raw public key in (6) after receiving and processing the + TLS server hello message. + +client_hello, +server_certificate_type=(RawPublicKey, X.509, OpenPGP) +client_certificate_type=(RawPublicKey) // (1) + -> + <- server_hello, + server_certificate_type=X.509 // (2) + certificate, // (3) + client_certificate_type=RawPublicKey // (4) + certificate_request, // (5) + server_key_exchange, + server_hello_done +certificate, // (6) +client_key_exchange, +change_cipher_spec, +finished -> + + <- change_cipher_spec, + finished + +Application Data <-------> Application Data + + Figure 8: Hybrid Certificate Example + + + + + + + + + + + +Wouters, et al. Standards Track [Page 12] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +6. Security Considerations + + The transmission of raw public keys, as described in this document, + provides benefits by lowering the over-the-air transmission overhead + since raw public keys are naturally smaller than an entire + certificate. There are also advantages from a code-size point of + view for parsing and processing these keys. The cryptographic + procedures for associating the public key with the possession of a + private key also follows standard procedures. + + However, the main security challenge is how to associate the public + key with a specific entity. Without a secure binding between + identifier and key, the protocol will be vulnerable to man-in-the- + middle attacks. This document assumes that such binding can be made + out-of-band, and we list a few examples in Section 1. DANE [RFC6698] + offers one such approach. In order to address these vulnerabilities, + specifications that make use of the extension need to specify how the + identifier and public key are bound. In addition to ensuring the + binding is done out-of-band, an implementation also needs to check + the status of that binding. + + If public keys are obtained using DANE, these public keys are + authenticated via DNSSEC. Using pre-configured keys is another out- + of-band method for authenticating raw public keys. While pre- + configured keys are not suitable for a generic Web-based e-commerce + environment, such keys are a reasonable approach for many smart + object deployments where there is a close relationship between the + software running on the device and the server-side communication + endpoint. Regardless of the chosen mechanism for out-of-band public + key validation, an assessment of the most suitable approach has to be + made prior to the start of a deployment to ensure the security of the + system. + + An attacker might try to influence the handshake exchange to make the + parties select different certificate types than they would normally + choose. + + For this attack, an attacker must actively change one or more + handshake messages. If this occurs, the client and server will + compute different values for the handshake message hashes. As a + result, the parties will not accept each others' Finished messages. + Without the master_secret, the attacker cannot repair the Finished + messages, so the attack will be discovered. + + + + + + + + +Wouters, et al. Standards Track [Page 13] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +7. IANA Considerations + + IANA has registered a new value in the "TLS Certificate Types" + subregistry of the "Transport Layer Security (TLS) Extensions" + registry [TLS-Ext-Registry], as follows: + + Value: 2 + Description: Raw Public Key + Reference: RFC 7250 + + IANA has allocated two new TLS extensions, client_certificate_type + and server_certificate_type, from the "TLS ExtensionType Values" + subregistry defined in [RFC5246]. These extensions are used in both + the client hello message and the server hello message. The new + extension types are used for certificate type negotiation. The + values carried in these extensions are taken from the "TLS + Certificate Types" subregistry of the "Transport Layer Security (TLS) + Extensions" registry [TLS-Ext-Registry]. + +8. Acknowledgements + + The feedback from the TLS working group meeting at IETF 81 has + substantially shaped the document, and we would like to thank the + meeting participants for their input. The support for hashes of + public keys has been moved to [CACHED-INFO] after the discussions at + the IETF 82 meeting. + + We would like to thank the following persons for their review + comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, + Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba, + Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John + Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn + Gillmor, Peter Sylvester, Hauke Mehrtens, Alexey Melnikov, Stephen + Farrell, Richard Barnes, and James Manger. Nikos Mavrogiannopoulos + contributed the design for reusing the certificate type registry. + Barry Leiba contributed guidance for the IANA Considerations text. + Stefan Jucker, Kovatsch Matthias, and Klaus Hartke provided + implementation feedback regarding the SubjectPublicKeyInfo structure. + + Christer Holmberg provided the General Area (Gen-Art) review, Yaron + Sheffer provided the Security Directorate (SecDir) review, Bert + Greevenbosch provided the Applications Area Directorate review, and + Linda Dunbar provided the Operations Directorate review. + + We would like to thank our TLS working group chairs, Eric Rescorla + and Joe Salowey, for their guidance and support. Finally, we would + like to thank Sean Turner, who is the responsible Security Area + Director for this work, for his review comments and suggestions. + + + +Wouters, et al. Standards Track [Page 14] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +9. References + +9.1. Normative References + + [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, April 2002. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Elliptic Curve Cryptography Subject Public Key + Information", RFC 5480, March 2009. + + [TLS-Ext-Registry] + IANA, "Transport Layer Security (TLS) Extensions", + . + + [X.690] ITU-T, "Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2002, + 2002. + +9.2. Informative References + + [ASN.1-Dump] + Gutmann, P., "ASN.1 Object Dump Program", February 2013, + . + + [CACHED-INFO] + Santesson, S. and H. Tschofenig, "Transport Layer Security + (TLS) Cached Information Extension", Work in Progress, + February 2014. + + [CoAP] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained + Application Protocol (CoAP)", RFC 7252, June 2014. + + + +Wouters, et al. Standards Track [Page 15] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + + [Defeating-SSL] + Marlinspike, M., "New Tricks for Defeating SSL in + Practice", February 2009, . + + [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol + (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, August 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wouters, et al. Standards Track [Page 16] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +Appendix A. Example Encoding + + For example, the hex sequence shown in Figure 9 describes a + SubjectPublicKeyInfo structure inside the certificate payload. + + 0 1 2 3 4 5 6 7 8 9 + +------+-----+-----+-----+-----+-----+-----+-----+-----+----- + 1 | 0x30, 0x81, 0x9f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, + 2 | 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x81, + 3 | 0x8d, 0x00, 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xcd, + 4 | 0xfd, 0x89, 0x48, 0xbe, 0x36, 0xb9, 0x95, 0x76, 0xd4, 0x13, + 5 | 0x30, 0x0e, 0xbf, 0xb2, 0xed, 0x67, 0x0a, 0xc0, 0x16, 0x3f, + 6 | 0x51, 0x09, 0x9d, 0x29, 0x2f, 0xb2, 0x6d, 0x3f, 0x3e, 0x6c, + 7 | 0x2f, 0x90, 0x80, 0xa1, 0x71, 0xdf, 0xbe, 0x38, 0xc5, 0xcb, + 8 | 0xa9, 0x9a, 0x40, 0x14, 0x90, 0x0a, 0xf9, 0xb7, 0x07, 0x0b, + 9 | 0xe1, 0xda, 0xe7, 0x09, 0xbf, 0x0d, 0x57, 0x41, 0x86, 0x60, + 10 | 0xa1, 0xc1, 0x27, 0x91, 0x5b, 0x0a, 0x98, 0x46, 0x1b, 0xf6, + 11 | 0xa2, 0x84, 0xf8, 0x65, 0xc7, 0xce, 0x2d, 0x96, 0x17, 0xaa, + 12 | 0x91, 0xf8, 0x61, 0x04, 0x50, 0x70, 0xeb, 0xb4, 0x43, 0xb7, + 13 | 0xdc, 0x9a, 0xcc, 0x31, 0x01, 0x14, 0xd4, 0xcd, 0xcc, 0xc2, + 14 | 0x37, 0x6d, 0x69, 0x82, 0xd6, 0xc6, 0xc4, 0xbe, 0xf2, 0x34, + 15 | 0xa5, 0xc9, 0xa6, 0x19, 0x53, 0x32, 0x7a, 0x86, 0x0e, 0x91, + 16 | 0x82, 0x0f, 0xa1, 0x42, 0x54, 0xaa, 0x01, 0x02, 0x03, 0x01, + 17 | 0x00, 0x01 + + Figure 9: Example SubjectPublicKeyInfo Structure Byte Sequence + + The decoded byte sequence shown in Figure 9 (for example, using Peter + Gutmann's ASN.1 decoder [ASN.1-Dump]) illustrates the structure, as + shown in Figure 10. + + Offset Length Description + ------------------------------------------------------------------- + 0 3+159: SEQUENCE { + 3 2+13: SEQUENCE { + 5 2+9: OBJECT IDENTIFIER Value (1 2 840 113549 1 1 1) + : PKCS #1, rsaEncryption + 16 2+0: NULL + : } + 18 3+141: BIT STRING, encapsulates { + 22 3+137: SEQUENCE { + 25 3+129: INTEGER Value (1024 bit) + 157 2+3: INTEGER Value (65537) + : } + : } + : } + + Figure 10: Decoding of Example SubjectPublicKeyInfo Structure + + + +Wouters, et al. Standards Track [Page 17] + +RFC 7250 Using Raw Public Keys in TLS/DTLS June 2014 + + +Authors' Addresses + + Paul Wouters (editor) + Red Hat + + EMail: pwouters@redhat.com + + + Hannes Tschofenig (editor) + ARM Ltd. + 6060 Hall in Tirol + Austria + + EMail: Hannes.tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + John Gilmore + Electronic Frontier Foundation + PO Box 170608 + San Francisco, California 94117 + USA + + Phone: +1 415 221 6524 + EMail: gnu@toad.com + URI: https://www.toad.com/ + + + Samuel Weiler + Parsons + 7110 Samuel Morse Drive + Columbia, Maryland 21046 + US + + EMail: weiler@tislabs.com + + + Tero Kivinen + INSIDE Secure + Eerikinkatu 28 + Helsinki FI-00180 + FI + + EMail: kivinen@iki.fi + + + + + + + +Wouters, et al. Standards Track [Page 18] + -- cgit v1.2.3