aka:SSL Basics

• SSL/TLS
  • References
    • http://ja.wikipedia.org/wiki/Secure_Sockets_Layer
    • http://en.wikipedia.org/wiki/Transport_Layer_Security
    • http://tools.ietf.org/html/rfc5246
    • http://my.safaribooksonline.com/book/-/9780470920411
  • Memo
    • 本メモでは、SSL/TLSと書くのは煩雑なので、TLSをその総称として用いる。これは、現在SSLと呼ばれるものの実態がTLS1.Xであることからしても悪くない選択肢であろう。
    • TLSについては、事情があって、多少知っている。そこで、「TLSのちょっとわからないところ」からとりあえず始めてみる。他の項目とは違う進め方。
    • このページでは、TLSの基本ツールの実装としてOpenSSLを想定します。
  • TLSのちょっとわからないところ
    • 標準としてのあり方、他の技術や標準との関係
      • Q:TLSの仕様って、どの標準化団体で、どのように決っているの？
        • A: IETF。なので、RFC方式。
      • Q: PKIとの関係は？
        • A:
          • そもそもPKIって何だっけ？ aka:PKI Basicsへ。
          • なるほど、PKIというのは、公開鍵を利用した認証基盤という抽象度の高い概念なんですね。
          • 技術的観点で言うと、TLSはPKIではないし、TLSを使うためにPKIが必須な訳ではない。またこれらの逆も真である。
          • 接点となるのは、TLSが証明書としてX.509v3証明書を指定しているところだ。ただし、後述するようにX.509規格はX.509証明書だけを規定しているのではなくて、PKIやPMIの一つのあり方を規定しているフレームワークである。この状況から、なんとなく「TLSとPKIって技術的に関係あるかも？」と思ってしまうが、実は技術的には関係がない。
          • しかし、TLSを使って、「認証された通信」すなわち通信相手が正しく意図された通信、を実施するためには、CAの存在と、そのCAによって発行されたX.509v3証明書が必要だ。CAの存在とそこ発行の証明書、というのはまさにPKIの機能の一部だ。
          • なので現在のWWWのように、TLSを実際に使って（HTTPSを実際に使って）前項のような通信を実現するためには、PKI的なものの存在が必要である。それがベリサイン社などが担っている部分。
      • Q: PKCSとの関係は？
        • A:
          • まず、PKCSの基本を。 aka:PKCS Basics。
          • RFC5246では、RSAを暗号化または署名方式として使うところではそれを定義した（アルゴリズ等を定義した）文書としてPKCS1 (RFC3447) を参照している、というか、ベースとしてる。
      • Q: TLSの証明書はX.509互換だとかなんとかいうけど、それってどういう価値や意味があるの？
        • A:
          • そもそもX.509って何だっけ？ aka:X.509 Basicsへ。
          • TLSの証明書はX.509 public-key certificateである、ということがRFCで定義されている。RFCには、"The certificate type MUST be X.509v3, unless explicitly negotiated otherwise."とある。
          • Wikipedia英語版によると、X.509証明書（のみ？）ではなく、OpenPGP証明書を用いるとしたRFC5246改訂ドラフトもあるようだ (TLSPGP)。http://en.wikipedia.org/wiki/Secure_Sockets_Layer#cite_note-openpgp-30
          • RFC5246では、SSLで使えるCertificate Key Typeの規定がある。使えるのは、RSA, RSA_PSK, DHE_RSA, ECDHE_RSA, DHE_DES, DH_DSS, DH_RSA, ECDH_ECDSA, ECDH_RSA, ECDHE_ECDSA。
          • Q: X.509仕様書では、証明書のエンコーディングルールが指定されていない。TLSについてはどこでどのように定義されているの？
            • A: TLS(RFC5246)では定義されていないようだ。

                    opaque ASN.1Cert<1..2^24-1>;
              
                    struct {
                        ASN.1Cert certificate_list<0..2^24-1>;
                    } Certificate;
              

              とだけ記述されている。
          • Q: それではどうやってASN.1Certをデコードするのだろう。ASN.1Certがある意味Boxedなデータであって、受け取った側はあらゆるエンコーディングルールに対応してデコードする、ということ？それともHTTPSとか別のところで定義されているの？
            • A: HTTPS (RFC2818)では定義されていない。T.B.D.
      • Q: SSHとはどういう関係があるの？　特にユーザ鍵。
        • A: T.B.D.
      • Q: PGPやGPGとはどういう関係があるの？　特にPGP鍵とかGPG鍵。
        • A: T.B.D.

• サーバ証明関係
  • Q: サーバ証明書について、HTTPSでチェックしているのは、1)そのHTTPS通信におけるURLのFQDN部分の文字列と証明書のCommon Nameの文字列とが一致するかどうか、2)有効期限内かどうか、3)issuerになっているCAから確かに発行された証明書か、の三点だと思うが、正しい？
    • A: だいたい正しい。ただし、Common Nameを使うのは慣行ではあるが、RFCでは非推奨となっている。FQDNの場合は、dNSNameに名前を格納することが推奨されており、この項目が証明書に存在する場合、クライアントは必ずこの項目を使ってFQDNとのマッチングをしなければならあい。また、FQDNを持たずIPアドレスでURL内が代替されている場合は、Common Nameはマッチングに使えない。その場合、iPAddress subjectAltNameに格納されているIPアドレスとマッチングがなされる。http://tools.ietf.org/html/rfc2818

• クライアント証明関係
  • Q: TLSのクライアント証明書って何に使えるの？ 標準的な用途というか機能というか。ユーザ認証、署名、通信暗号化、ファイル暗号化、でいいのかね？
    • A:
      • ユーザ認証：使える。ただし、クライアント証明書を保持している人のみ接続可能、という粒度であれば、一般的にユーザ認証というかアクセス制限として使える。それより細かい粒度のユーザ認証に使えるかどうかは、システム次第。
      • 署名：使える。ただし、TLSとして、ではなくX.509証明書だから、という位置付けにて。OpenSSLは、クライアント証明書を利用した署名機能を有している。
      • 通信暗号化：使える。ただし、使おうと思えば、ということであり、TLSではクライアント証明書は通信の暗号化には使わない。クライアント証明書はクライアント認証に利用するだけ。
      • ファイル暗号化：使える。ただし、TLSとして、ではなくX.509証明書だから、という位置付けにて。OpenSSLは、クライアント証明書を利用したファイル暗号化機能を有している
  • Q: クライアント証明書をユーザ認証に使えるとして、認証以降のオーソリとかにその認証情報を使えるの？ 例えばHTTPSで。原理的な側面と、それが可能なソフトウエアが存在するかどうかの両面から。
    • A: T.B.D.
  • Q: クライアント証明書って、PKCS#12で配布してWebブラウザに読み込ませてHTTPSで使ったことしかないんだけど、他にどんな使い方があるの？　そして他の使い方の場合は鍵の形態や管理方法（設置場所、セキュリティ等）はどうなってるの？
  • Q: PKCS#12とかで一回しかインポートできなくするにはどうするんだっけ？
    • A: T.B.D.

• CRL関係
  • Q: CRL (Certificate Revocation List) の運用って標準的なものがあるの？
    • A: T.B.D.