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.
我々は装置を識別するものを求めているが、クライアント証明書は一般的にはユーザーを識別するものである。TLSにおいて、（端末毎に）ひとつのクライアント証明書が提供されるのであれば、概念として排他的なものではないが、そのような使い方をすることで、既存のクライアント証明書を使うことの可能性をも失ってしまいたくはない*4。
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.
TLSにおけるクライアント証明書はX.509証明書として実装されているが、サーバーに対して、恣意的なASN.1でパーズすることを要求したくはない。ASN.1は複雑なエンコーディングで、過去に幾つかのセキュリティの脆弱性の原因になっており、今では、一般的なTLSサーバーはASN.1によるパージングを避ける可能性がある。
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.
X.509証明書は、常に署名を含んでおり、このケースでは自己署名の場合がある。自己署名の生成と送信は、我々の使用方法においては、計算資源とネットワークトラフィックの浪費である。我々は署名を含まないnullシグニチャアルゴリズムを定義することもできるが、そのようにしてX.509からの逸脱するのは、既に実装されているものを再利用することによる利益の多くを失わせてしまう*5。
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セッションの、各種パラメータのセットを指す。適当な訳が思い当たらないため原文のままとした。
*2:クライアント証明書を言い換えているだけだと思われる。
*3:この文は誤りのように思われる。直訳すると「攻撃者が、実際に秘密鍵を管理できるのでない限り秘密鍵を使うことができない、という印象を与えることができないようにすることである。」となるが、上記の役では修正している。
*4:「手段」はクライアント証明書を端末の識別に用いることを指す。
*5:「null signature algorithm」の適切な役がわからなかったので、 「nullシグニチャアルゴリズム」としている。署名を持たないクライアント証明書を生成するアルゴリズムという意味だと思われる。
