TLSチャンネルID 翻訳 - 2. Why not client certificates

TLSチャンネルIDの翻訳シリーズの第2回です。「2. Why not client certificates」までの翻訳結果を投稿します (第1回はこちら)。

2, なぜクライアント証明書ではないのか

2. Why not client certificates

TLS already supports a means of identifying clients without using bearer tokens: client certificates. However, a number of problems with using client certificates motivated the development of an alternative.

TLSはすでに、bearer tokenを用いないでクライアントを識別する方法 - クライアント証明書 - をサポートしている。しかし、クライアント証明書を用いることに対するいくつかの問題点が、代替の手段を開発する動機となっている。

Most importantly, it's not acceptable for a client identifier to be transmitted in the clear, because eavesdroppers in the network could use these identifiers to deanonymize TLS connections. Client certificates in TLS, however, are sent unencrypted. Although we could also define a change to the TLS state machine to move the client certificates under encryption, such changes eliminate most of the benefits of reusing something that's already defined.

最も重要なこととして、クライアントのidentifierが平文で送信されるのは許容されることではない。ネットワーク上の盗聴者が、このidentifierを、TLSコネクションの匿名性を奪うために利用できてしまうためである。 にもかかわらず、TLSにおいてクライアント証明書は暗号化されずに送信される。TLS state machineがクライアント証明書を暗号化して送るような変更を定義することもできるが、このような変更は、すでに定義されているものを再利用することによる利益のほとんどを、失わせてしまう。

TLS client certificates are also defined to be part of the session state. Even though the key material used for TLS client authentication might be protected from theft from compromised clients (for example, by employing hardware secure elements on the client), TLS session resumption information rarely is. Because client certificates are part of the session state, stolen session resumption information gives the attacker something equivalent to a stolen client private key. Our objective, however, is that attackers should not be able to give the impression that they can wield a private key unless they are actually in control of that private key.

TLSクライアント証明書は、session state*1 の一部としても定義される。TLSクライアント認証の鍵となる材料*2は、脆弱なクライアントから盗まれることから守られるかもしれない(例えば、セキュアエレメントのハードウェアを導入することによって)が、TLSセッションの復元に用いる情報にはほぼ当てはまらない。クライアント証明書は session state の一部なので、セッションの復元に用いる情報が盗まれると、攻撃者に、クライアントの秘密鍵を盗まれるのと等価な情報を与えてしまう。しかし我々の目的は、攻撃者に、実際に秘密鍵を管理できるのでない限り秘密鍵を使うことができない、ということを示すことである*3

Client-certificates typically identify a user, while we seek to identify machines. Since they are not, conceptually, mutually exclusive and as only a single client certificate can be provided in TLS, we don't want to consume that single slot and eliminate the possibility of also using existing client certificates.


Client certificates are implemented in TLS as X.509 certificates and we don't wish to require servers to parse arbitrary ASN.1. ASN.1 is a complex encoding that has been the source of several security vulnerabilities in the past and typical TLS servers can currently avoid doing ASN.1 parsing.


X.509 certificates always include a signature, which would be a self-signature in this case. Calculating and transmitting the self-signature is a waste of computation and network traffic in our use. Although we could define a null signature algorithm with an empty signature, such deviations from X.509 eliminate many of the benefits of reusing something that is already implemented.


Finally, client certificates trigger significant server-side processing by default and often need to be stored in their entirety for the duration of the connection. Since this design intended to be widely used, it allows servers to retain only a cryptographic hash of the client's public key after the handshake completes.


*1:「session state」は、ハンドシェイクによって合意されたTLSセッションの、各種パラメータのセットを指す。適当な訳が思い当たらないため原文のままとした。




*5:「null signature algorithm」の適切な役がわからなかったので、 「nullシグニチャアルゴリズム」としている。署名を持たないクライアント証明書を生成するアルゴリズムという意味だと思われる。