1. 引言
1. 引言
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:
-
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].
-
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.
-
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 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.
第 3 节 定义两个新的 TLS 扩展 client_certificate_type 和 server_certificate_type 的结构, 当要使用原始公钥时, 这些扩展可作为扩展 TLS 握手的一部分使用. 第 4 节 定义 TLS 客户端和 TLS 服务器的行为. 第 5 节 描述示例交换. 第 6 节 描述这种方法的安全考虑事项. 最后, 在 第 7 节 中, 本文档向 IANA "TLS Certificate Types" 子注册表注册一个新值, 以支持原始公钥.