2008年12月30日

RFC 5280 の 4.1.2.5.2. GeneralizedTime

UTCTime と同様 GeneralizedTime も ASN.1 の基本の型になります
UTCTime と同様 UTC を書いたり各地域の時間も表現できます
UTCTime と同様末尾に Z を付けたり±hh:mm を付けたりします
唯一の違いは年が 4 桁なところでしょうか
X.680 には時刻の表記は ISO 8601 に従うと書いてあるんですが
どこだ ISO 8601 は
YYYYMMDDhhmmdd.fff と秒が小数点まで表示できるみたいです

RFC 5280 では GeneralizedTime は UTC で書かなくてはいけません (MUST)
また、秒が 0 秒だとしても秒まで書かなくてはいけません (MUST)
更に、秒は小数部分を表示してはいけません (MUST NOT)

つわけで RFC 5280 では
YYYYMMDDhhmmddZ という形の Ascii String が格納されることになります
ラベル:RFC5280 証明書 UTC ASN.1
posted by OJH at 01:07| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月29日

RFC 5280 の 4.1.2.5.1. UTCTime

UTC は  Coordinated Universal Time の略だそうですが
何で順番違っているの?
Wikipedia とか見てみたんですが
http://tf.nist.gov/general/misc.htm#Anchor-14550
によると ITU 的にはどの言語でも通じる略語を作りたかったんだけど
英語だと CUT だし仏語だと TUC だし (多分色々あって) UTC になったと

UT には UT1 というのもあってこれは天文学的に決められる時刻だそうです
地球の自転を 1 日 = 60 x 60 x 24 秒としたいんだけど
地球は毎日同じように回っているわけではないので観測して決めるということかな?
太陽と地球と自転は先ずあるじゃない、という立場ですね

一方で、それで正確なのを常に計っているのは面倒なので
1 秒を定義する努力というのは色々とされていて
今ではセシウム原子時計で 1 秒というのが定義されているのかな?
で、それを 1 秒として 1958 年 1 月 1 日 0 時 0 分 0 秒をスタートとして
時刻を表現しているのが UTC だそうです

で、もちろん、UTC は UT1 とずれてしまうわけですが
どっちが正解かっていうと UT1 を正解にしとかないと
いつかは昼と夜が逆転してしまうかもしれません
UTC と UT1 が 1 秒以上ずれないように閏秒というのが入って補正されています

ってそんなのとは全く関係無く、UTCTime というのは ASN.1 で定義されている
時刻のフォーマットのことです
中身は ASCII になりますが形式としては
YYMMDDhhmmssZ, YYMMDDhhmmss+hhmm, YYMMDDhhmmss-hhmm のどれかになります
最初のはUTC のことを多分指すはずで、例えば 20081228165652Z となります
日本標準時はコレから 9 時間進めることによって得られるので
20081229015652+0900 と後に UTC からどれだけ進めたか書いておきます

ちなみに、Zulu ってのは航空用語の GMT のことみたいです
GMT ってのは Greenwich Mean Time のことですが
これも UT1 とはちょっとずれていて
季節による変動を補正して平均化してるので標準時ということだそうです
あぁ、だから「航空用語の UT1」と言うのが正確なのかなぁ.....

や、だから、そうではなくて、
RFC 5280 に従う証明書は UTCTime として UTC を入れとかなくてはいけません
末尾は Z で、ということです (MUST)
更に、秒まで書いてなくてはいけません (MUST)
YY と年の部分が 2 桁しかないので、それに関しては次のように解釈します
50以上だったら 19YY 年だと解釈
50未満だったら 20YY 年だと解釈

4.1.2.5 には「2049 年までは UTCTime を使え」と書いてありましたね
次の節の GeneralizedTime ではなくて UTCTime を使えということです
ラベル:RFC5280 UTC ASN.1 証明書
posted by OJH at 02:11| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月28日

RFC 5280 の 4.1.2.5. Validity

発行者の次は有効期間
有効期間は notBefore と notAfter という 2 つの日付の列で表現されます
   Validity ::= SEQUENCE {
        notBefore      Time,
        notAfter       Time }
   Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }
  • notBefore = それ以前は有効ではない
  • notAfter = それ以降は有効ではない
ということで、有効期間の最初と最後です
どちらの日付も UTCTime か GeneralizedTime で表現されます

この二つに関しては続く 2 つのサブセクションで説明されるけど
UTCTime は YYMMDDhhmmss を数字の列として ASCII で
GeneralizedTime は YYYYMMDDhhmmss を数字の列として ASCII で
格納しています、タイムゾーンの話は置いといて

UTC は YY と年の部分が 2 桁なので、X.509 の場合
00 から 49 までは 2000 年代、50 から 99 までは 1900 年代として解釈します
ひどい! ひどいよ! と思われる方も多い?
まぁじゃぁ西暦 1 万年になったとき GeneralizedTime はどうするんだって?

が、しかし
RFC 5280 では 2049 年までは UTCTime で書きなさいと言っています (MUST)
2050 年以降を表現するときは流石に GeneralizedTime を使えと言ってます (MUST)
で、証明書の利用者は UTCTime も GeneralizedTime も解釈できないといけません (MUST)

場合によっては有効期限を設けたくない場合があるかもしれません
あんま想像できなんだけど
まぁ証明書を組み込んでしまったりする場合なんでしょうか
その機械が使われる限りは有効であるような証明書が望まれる場合もあるでしょう
よっぽど丈夫な秘密鍵用意しとかないと危険だと思いますが
「そんな場合には GeneralizedTime で 99991231235959Z と書いときなさい」
とのことです
(Z が最後に付いてるのは、グリニッジ標準時ですよって意味です)

そして、最後の段落の意味が分からない
RFC 3280 には無い部分なので既存の和訳を見ても分からない

こういうこと?
「発行者は、notAfter までに status information を maintain できなくなった
その証明書の信頼の階層が構築できないようにしなくてはいけない?
どうやってかっていうと階層に出てくる全ての認証局の証明書を失効させて
その証明書の署名を確認するのに使う公開鍵の利用を中止して」
何か凄い厳しいこと書いてあるんだけど証明書の失効とか書いてないし
認証局の証明書を失効させろって何か凄い話が大きくなっていない?
status information って誰の? その証明書の? CA の?? self-signed の話???
読み方間違っているのかなぁ、自信無いないなぁ

まぁとりあえず、notAfter 以前に問題があったら対応しないといけないですよね
ん〜、その方法がなぁ〜
posted by OJH at 02:19| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月27日

RFC5280 の 4.1.2.4. Issuer

署名アルゴリズムの次に記載されるのが認証局の名前です
Issuer は「発行者」と訳しましょう
つまり、その証明書に署名して発行しているのは誰か? ということが書かれます
ここは空ではいけません (MUST)

名前の記述方法は X.501 に書いてあります
X.500 番台ってのはディレクトリシステムっていう住所録の仕様を決めてました
もちろん何処の誰かを指し示す方法も決めてなくてはいけないわけですが
その指定の仕方を distinguished name (DN) と言います
区別できる名前ということですかね
具体的には国・住所・組織名・名前などを階層として並べて書きます
うだうだ書くより見た方が分かり易いですね
発行者
下から type -> value という形で階層下って見ていくと、
  • countryName (国名) -> US
  • organizationName (組織) -> VeriSign, Inc.
  • organizationalUnitName (組織単位) -> VeriSign Trust Network
  • organizationalUnitName (組織単位) -> Terms of use at https://www.verisign.com/rpa (c)07
  • commonName (一般名) -> VeriSign Class 3 Secure Server 1024-bit CA
って書いてあります
CA は Certification Authority = 認証局、でした

hex dump して発行者の部分を抜き出してみます
型はそれぞれ 30=SEQUENCE, 31=SET, 06=OID, 13=PrintableString です
30 81 [ 185 ]
   31 [ 11 ]
      30 [ 9 ]
         06 [ 3 ] 2.5.4.6
         13 [ 2 ] US
   31 [ 23 ]
      30 [ 21 ]
         06 [ 3 ] 2.5.4.10
         13 [ 14 ] VeriSign, Inc.
   31 [ 31 ]
      30 [ 29 ]
         06 [ 3 ] 2.5.4.11
         13 [ 22 ] VeriSign Trust Network
   31 [ 59 ]
      30 [ 57 ]
         06 [ 3 ] 2.5.4.11
         13 [ 50 ] Terms of use at https://www.verisign.com/rpa (c)07
   31 [ 51 ]
      30 [ 49 ]
         06 [ 3 ] 2.5.4.3
         13 [ 42 ] VeriSign Class 3 Secure Server 1024-bit CA
これの元になる ASN.1 モジュールとは次のように定義されています
Name ::= CHOICE { -- only one possibility for now --
  rdnSequence  RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::=
  SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
  type     AttributeType,
  value    AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType

DirectoryString ::= CHOICE {
      teletexString           TeletexString (SIZE (1..MAX)),
      printableString         PrintableString (SIZE (1..MAX)),
      universalString         UniversalString (SIZE (1..MAX)),
      utf8String              UTF8String (SIZE (1..MAX)),
      bmpString               BMPString (SIZE (1..MAX)) }
Name は CHOICE ってあるけど現状では 1 つしか選択肢がなく
その選択肢は RDN の列になります
RDN は relavite DN でパスみたいに絶対と相対があります
階層で書くわけですが、その名前を 1 つずつ上から書いてくわけですね
で、その各々の名前は SET(31) で表現されていて中身は
  • type (countryName とか organizationName とか) を示す OID
  • その OID の中身を表す「何か」(US とか)
です、がまぁ普通何かってのは文字列になるわけで
ANS.1 なんかで想定されてる文字の種類が DirectoryString で定義されてます

X.509 では文字列のタイプが沢山準備されているわけですが
RFC 5280 に従うならば認証局は
PrintableString か UTF8String しか使ってはいけません (MUST)
(但し互換性を保つのに必要な場合は除く (MAY))

国名や組織名などが ssl.seesaa.jp の証明書では使われていましたが
X.520 では一般的な型が定義されています
RFC 5280 では最低限こんだけはサポートしようぜ (MUST)、ってのが指定されています
  • country (国名)
  • organization (組織)
  • organizational unit (組織単位)
  • distinguished name qualifier
  • state or province name (州とか県とか)
  • common name (名前、サーバならホスト名とか IP address とか)
  • serial number (シリアル番号)
で、続いてサポートすべきなのが (SHOULD)
  • locality (市区町村)
  • title (肩書?)
  • surname (苗字)
  • given name (名前)
  • initials (頭文字)
  • pseudonym (ハンドルネーム? ペンネーム?)
  • generation qualifier (e.g., "Jr.", "3rd", or "IV")
と書かれています

更に RFC 4519 に定義されてるらしい domainComponent ってのも扱えるようにしろと
だったら上にまとめとけ、って思うんだけど何か違うんでしょうか
これは要するに DNS 名も扱えるようにってことみたいです
後で拡張領域で別名 (altervative name) を扱ってそこにも DNS 名入れるんですが
それとは別で DN のところに DNS 名を入れれるようにしましょうって話です
更に ASCII で表現できない日本語ドメインみたいなもんに関しては
7.3 を見ろって書いてあります

証明書の利用者は認証局と証明書の発行対象の名前を扱えないとだめで (MUST)
何でかっていうと証明書を検証する為です
ちゃんとした検証の方法に関しては 6. で見ますが
証明書が信頼できるかどうか調べるのには認証局の証明書・公開鍵が必要です
証明書があったら「発行者」を見て「発行者」の証明書から公開鍵取り出して
証明書の署名を検証して確かに発行者が認証したかどうかを確認するわけです
どの証明書を使うべきか探すべきかというのがこの発行者の DN で表示されてます
ここの比較が正しくできないと使うべき証明書が分からなくなってしまうので
「発行者」の名前は大切です、その比較方法は 7.1 で述べられます
ここが分からなくなっちゃうと証明書を正しく検証することがでません
文字列として何を使うかなどもとても大切な話となります

自己発行証明書の場合、この「発行者」と「サブジェクト」が一致します

それぞれの型の記述方法や OID に関しては Appedix. A も参照のこと
posted by OJH at 03:01| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月25日

RFC 5280 の 4.1.2.3. Signature

認証局が証明書に署名するのに使う署名アルゴリズムが記載されます
AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }
4.1 で見た通り
証明書の三大要素は「証明内容」「署名アルゴリズム」「署名」でした

ここでまた「署名アルゴリズム」が記載されています
「署名アルゴリズム」が 2 箇所に記載されることとなりますが
これらは同一のものでなくてはいけません (MUST)

4.1.1.2 でも見ましたが
RFC 3279RFC 4055RFC 4491 に想定されてるアルゴリズムが載っています
一応、載ってないアルゴリズムでも OK です (MAY)
ラベル:RFC5280 証明書 署名
posted by OJH at 03:38| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月24日

RFC 5280 の 4.1.2.2. Serial Number

バージョンの次にはシリアル番号が続きます
これは正の整数でなくてはいけません (MUST)
認証局が、それぞれの証明書を区別するように振り分けます
1 つの認証局が同じシリアル番号を異なる証明書に振ってはいけません (MUST)
つまり、
認証局の名前とそのシリアル番号が分かれば証明書が一意に求まる
ということが保証されなくてはいけないということです

ん?
The serial number MUST be a positive integer assigned by the CA to each certificate.
CAs MUST force the serialNumber to be a non-negative integer.
positive integer と non-negative integer と両方が MUST と書いてあります
こりゃどういうことか
発行する証明書は正整数じゃないといけないけど
自己署名証明書のシリアルは 0 でもいいということかな?
シリアル番号 0
まぁ、シリアルが 0 なんて証明書はオレオレか
幾つかの自己署名証明書でしか見たことないし
や、負はダメよ、ということか?

一意性を表現しなくてはいけないのでシリアル番号は大きな数字になります
RFC 5280 では 8 進で 20 桁までは検証できなくてはいけないと言っています (MUST)
10 進で 18 桁です、100 京ちょっとですね
良い子は 20 bytes 以上のでかいシリアル番号を使っちゃダメよ (MUST NOT)

注意として
シリアル番号として 0 とか負の数使ってるやつがあるかもしれないけど
そういうのも優雅に (gracefully) 扱っていきましょうね、だそうです
ラベル:RFC5280 証明書
posted by OJH at 01:24| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月23日

RFC 5280 の 4.1.2.1. Version

TBSCertificate の最初の項目は Version です
X.509 のどのバージョンに従った証明書かが示されます

取りうるバージョンの値とそれぞれの特徴

ここは 0 か 1 か 2 が入ってそれぞれバージョン 1, 2, 3 を表します
  • 拡張領域を使うならバージョン 3 じゃなきゃいけない (MUST)
  • UniqueIdentifier を使うならバージョン は 2 (SHOULD) か 3 (MAY)
  • どっちも無しで基本情報のみならバージョン 1 推奨 (SHOULD) または 2 or 3 (MAY)
で、バージョンが 1 なら省略も可能です
なのでコンテキストの番号 [0] が振られていました
次に出てくるシリアル番号も整数なので区別がつくように、ですね

実装する人に向けて

証明書に対応するからにはどのバージョンの証明書も受け入れられるべきです (SHOULD)
でもインターネット PKI を定義したい RFC 5280 的には
拡張領域をフルに使っていきたいわけですから
少なくともバージョン 3 には対応しといてくれないと話になりません (MUST)

RFC 5280 では バージョン 2 の証明書の利用が想定されていません
確かに UniqueIdentifier だけ使えるようになっても仕方無いのかな
何でバージョン 1 はアリかというと、既に普及してしまっているからかな?
例えば ssl.seesaa.jp は認証局 VeriSign から証明書を発行してもらってます
VeriSign Class 3 Public Primary Certification Authority
ルート証明書は 1996 年 1 月に署名された自己署名証明書で
X.509 が 1996 年 6 月に完成したとありましたから仕方無いですもんね

原則バージョン 3 で、まぁ 1 も機能絞るだけだから対応できるよね
って感じでしょうか
ラベル:X.509 RFC5280
posted by OJH at 03:20| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月21日

RFC 5280 の 4.1.2. TBSCertificate

TBSCertificate に載っているのは
エンドエンティティーと認証局に関する情報です。

もう少し詳しく述べ直すと
  • エンドエンティティーの名前
  • 認証局の名前
  • エンドエンティティーの公開鍵
  • 有効期間
  • バージョン
  • シリアルナンバー
  • 必要であれば名前の一意性を保証する情報
などが
また、拡張領域も用意されています

この節の部分節で各項目の書き方・意味を詳しく見ていきます
また、拡張領域に関しては 4.2 で見ます
posted by OJH at 23:46| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

RFC 5280 の 4.1.1.3. signatureValue

X.509 の証明書の三大構成要素の 3 つ目は「電子署名」
「証明内容」から「署名アルゴリズム」を用いて「電子署名」が得られます
なので、「電子署名」の値は BIT 列になります

署名するには先ず「証明内容」をバイト列に落とし込まないといけません
ASN.1 という形式で定義されていた「証明内容」ですが
これを ASN.1 の符号化方法の 1 つである
DER というエンコード方法でコード化します

DER では BIT 列で「型・長さ・内容」が羅列されます

例えば Linux なんかで OpenSSL が使える場合に
ssl.seesaa.jp の証明書を hex に dump すると
$ openssl s_client -connect ssl.seesaa.jp:443 < /dev/null | openssl x509 -outform der | od -t x1
0000000 30 82 05 26 30 82 04 8f a0 03 02 01 02 02 10 09
0000020 68 23 a2 c6 64 0e 2b 9d 7f 23 15 08 fb db bf 30
0000040 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 81
0000060 b9 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 17
.......
0002440 fe 7f a4 47 b1 8d d5 9d f1 dc
0002452
これをインデント付けて更に長さを表現する部分を [] で囲むと
30 82 [05 26]
   30 82 [04 8f]
      a0 [03]
         02 [01] 02
      02 [10] 09 68 23 a2 c6 64 0e 2b 9d 7f 23 15 08 fb db bf
      30 [0d]
         06 [09] 2a 86 48 86 f7 0d 01 01 05
         05 [00]
      30 81 [b9]
         31 [0b]
            30 [09]
               06 [03] 55 04 06
               13 [02] 55 53
         31 [17] ........
となりますが
最初からちょっと見てみると

16 進で 30 は 2 進で 00110000 ですが 00 1 10000 と分けます

最初の 2 bits は以下で表現されるもののクラスを表現するタグです
  • universal (00) は ASN.1 で一般に定義されてるもの
  • application (01) X.500 など特定の application で定義されるもの
  • context-specific (10) [0] [1] のように省略できる場合の識別子
  • private (11) その他の拡張に用いる??
みたいな感じでしょうか

次の 1 bit はデータの型が 1 つの値か、値の集まりかを表現します
  • 0 であれば simple types、整数や文字列など
  • 1 であれば structured types、SEQUENCE や SET など中身が複数

次の 5 bits で型が表現されます
10 進で型の番号を幾つか書くと
  • 2 -> 整数
  • 5 -> Null
  • 6 -> OBJECT IDENTIFIER
  • 16 -> SEQUENCE
  • 17 -> SET

というわけで 00110000 は SEQUENCE だということが分かりました

次の 1 バイトは長さの表現方法を表します
頭の 1 bit が
  • 0 であれば続く 7 bit が長さ
  • 1 であれば続く 7 bit が長さを表現するバイト列の長さを表現します

16 進の 82 は 2 進で 10000010 なので
頭が 1 ですから続く 0000010 -> 2 バイトが長さを表現することになります
16 進で 0526 は 10 進で 1318 ですから
最初に定義されてる SEQUENCE の中身は 1318 バイトなことが分かります
この SEQUENCE が rfc 5280 の 4.1 で定義されていた証明書
Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }
の SEQUENCE に対応しています
次が 30 82 [04 8f] ですが、これは TBSCertificate の SEQUENCE
TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     extensions      [3]  EXPLICIT Extensions OPTIONAL
                          -- If present, version MUST be v3
     }
に対応していて、長さは [04 8f] -> 1167 バイトになります

次の a0 は 2 進で 10 1 00000 これは version の [0] に対応してます
最初の 10 が context-specific で、中身に version が入ってるはずです
実際次の行が 02 [01] 02 ですが
  • 02 は 2 進で 00 0 00010 で整数型
  • 01 は 2 進で 00000001 で頭が 0 なので 1 バイトの整数であることを
  • 02 は中身なので version の数が 2
になりますが
Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
だったので v3、つまり X.509 バージョン 3 の証明書ということです

次の行の 02 [10] は 上と同じで 16 バイトの整数という意味で
09 68 23 a2 c6 64 0e 2b 9d 7f 23 15 08 fb db bf がシリアルになります

次の行の 30 [0d] は 13 バイトの SEQUENCE で
中身の 1 つめは 06 [09] 2a 86 48 86 f7 0d 01 01 05
型番号 06 は Object Identifier を表現していました
中身を 2 進で書くと
00101010 10000110 01001000 10000110 11110111 00001101 00000001 00000001 00000101
最初の 1 バイトは 42 = 1 x 40 + 2 と読むそうで OID の最初は 1.2.
残りのバイトは
頭が 1 なら残りの 7 bit を続けていって
頭が 0 なら残りの 7 bit で終わりとなります
分かりづらいですね、残りが
10000110 01001000 10000110 11110111 00001101 00000001 00000001 00000101
ですが、これを 0 始まりのもので切っていって
{ 10000110 01001000 } { 10000110 11110111 00001101 } { 00000001 } { 00000001 } { 00000101 }
頭の数字を取っていって
{ 00001101001000 } { 000011011101110001101 } { 0000001 } { 0000001 } { 0000101 }
これを 10 進に直すと
{ 840 } { 113549 } { 1 } { 1 } { 5 }
で、最初のとくっつけて 1.2.840.113549.1.1.5
これは sha-1WithRSAEncryption を指す OID でした

次の行の 05 [00] が署名アルゴリズムの SEQUENCE の 2 成分目で
sha-1WithRSAEncryption は特にオプションが要らないので NULL
型が 05、つまり NULL になっています

という風にバイト列から ASN.1 による定義を見直してみましたが
このように ASN.1 による定義がバイト列に変換されます
そのバイト列を署名アルゴリズムで署名に変換したものが
署名として証明書の最後に記述されることになります
ラベル:RFC5280 ASN.1 der 署名
posted by OJH at 03:16| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月20日

RFC 5280 の 4.1.1.2. signatureAlgorithm

X.509 の証明書の三大構成要素の 2 つ目
認証局が署名したその「署名アルゴリズム」は
AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }
アルゴリズムを指し示す OBJECT IDENTIFIER
及び必要であればそのパラメータで指定されます

アルゴリズムとして使用できる主なものは
RFC 3279 及びその更新である RFC 4055RFC 4491 に書かれていますが
他のアルゴリズムも許されています (MAY)
例えば RFC 3279 の 4 ページと 5 ページを見てみると
md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-1(1) 4  }
sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-1(1) 5  }
id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
     iso(1) member-body(2) us(840) x9-57 (10040)
     x9cm(4) 3 }
といった馴染み深い? 署名方法の OID (Object IDentifier) が書かれてます

OID というのは ITU-T や ISO が決めた何かを指し示すルールで
数字の列で階層構造になっています (真にディレクトリというやつかこれが)
  • 1 で始まると ISO が決めたということで
  • 次に 2 が来てるので ISO の加盟団体が定めたもので
  • 次に 840 が来てるけどそれは United States of America のことで
という感じで大きなカテゴリがら順番に書いていきます
上にある sha-1WithRSAEncryption なら
1.2.840.113549.1.1.5 という数字の列で示します

他の OID に関しても
例えば http://www.alvestrand.no/objectid/top.html で検索できます

で、ASN.1 でも OID は基本的な型として定義されているので
「署名アルゴリズム」を OID を用いて指定してやれば良いということになります

アルゴリズムによっては
パラメータを付記しないといけないものがあるかもしれないので
OID の後にそのパラメータを書く部分も用意されています

tbsCertificate にも署名アルゴリズムを書く部分が用意されていましたが
それはここで指定するものと同じでなくてはいけません (MUST)
だったら書かなくてもいいんじゃない? という気もするんですが
何故だろう、何でアルゴリズムを別に書いているんだろう?

ともかく、
これで、証明書にどんな形で署名されてるかが分かるようになりました
ラベル:RFC5280 署名 OID
posted by OJH at 07:04| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

RFC 5280 の 4.1.1.1. tbsCertificate

tbs は "to be singned"、つまり署名される予定の証明書?
署名前証明書って訳も見たんですが、何じゃそりゃ
証明書 - 署名 = 署名内容、のことです

内容は
  • 発行対象の名前
  • 発行者の名前
  • 発行対象の公開鍵
  • 有効期間
  • などなど

各項目の詳細に関しては 4.1.2 で
「などなど」の部分には「拡張」部分も含まれていて
「拡張」部分に関しては 4.2 で詳しく述べられるということで
この節も前置きで中身無しでした
ラベル:証明書 RFC5280
posted by OJH at 06:15| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月18日

RFC 5280 の 4.1.1. Certificate Fields

何が書いてあるかというと、

   The Certificate is a SEQUENCE of three required fields.  The fields
   are described in detail in the following subsections.

こんだけ。

"three required fields" っていうのは
  • 証明内容 (公開鍵・発行者・エンドエンティティー・公開鍵 などの情報)
  • 署名のアルゴリズム
  • 署名
のことでした
以下のサブセクションで各フィールドの詳細が述べられます
ラベル:証明書 RFC5280
posted by OJH at 02:12| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月17日

RFC 5280 の 4.1. Basic Certificate Fields

X.509 バージョン 3 で定義されてる証明書に関して概要が示してあります

大雑把に言うと証明書というのは
  • 証明内容 (公開鍵・発行者・エンドエンティティー・公開鍵 などの情報)
  • 署名のアルゴリズム
  • 署名
という 3 つの部分から成っています

証明内容に書かれているのは
  • X.509 のバージョン (バージョンが 1 か 2 か 3 か)
  • シリアル番号 (認証局の発行してる証明書の通し番号)
  • 署名のアルゴリズム
  • 認証局の名前などの情報
  • 有効期間
  • エンドエンティティーの名前などの情報
  • 公開鍵とそのアルゴリズム
  • (認証局の識別子)
  • (エンドエンティティーの識別子)
  • 複数の拡張領域・情報 (証明書のポリシーなど)
といった内容になります

上に現れている情報は
  • シリアルは CRL を参照するときに必要となります
  • 認証局の名前が分かると署名を検証するのに使うべき公開鍵が分かります
  • 発行された証明書は認証局が管理しない代わりに有効期間を定めました
  • 証明書は公開鍵とその対の秘密鍵の所有者を認証する為のものでした
  • 証明書の信頼の階層を検証したりするのに用いる情報も付記されます
と、今まで見てきた必要な情報が詰まっているということを示しています

これら情報を X.208 に従って DER というバイナリー形式に変換して
そのデータから「署名のアルゴリズム」で指定された方法で「署名」を作成して
最後に加えると証明書が完成します
X.208 に従って、と書きましたがそれだけではなくて
原本には X.509 に書かれている ASN.1 に従った証明書の構造も書いてあり
その構造を X.208 に従ってバイナリーに変換なんですが、細かな構造は略
posted by OJH at 01:44| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月15日

RFC 5280 の 4. Certificate and Certificate Extensions Profile

RFC 5280 の目的は
「X.509 をインターネットでの相互運用向けにカスタマイズ」
でした
特にメール・IPSec・WWW なんかが想定されています
その為にこの節では X.509 バージョン 3 で定義されてる証明書と
証明書の拡張部分について述べられます
更にインターネット向けに拡張部分の追加が行われます

X.509 バージョン 3 だと証明書は ASN.1 の 1997 年のもの記述されていますが
RFC 5280 だと ASN.1 の 1988 年のもので記述されるそうです
X.208 が 1988 年に CCITT から、その拡張の X.680 が 1997 年に ITU-T から
出ていて、それぞれ対応してるっぽいです
え? ASN.1??

ASN.1 とは Abstract Syntax Notation One の略で
どんなデータがどんな感じで並ぶかというデータの構造を定義しています
例えば RSA Laboratories - PKCS #1: RSA Cryptography Standard では
PKCS #1 という公開鍵の仕様が決められていますが
ASN Module for PKCS #1 v2.1 を見てみると
RSAPublicKey ::= SEQUENCE {
    modulus           INTEGER,  -- n
    publicExponent    INTEGER   -- e
}
といった記述があり、これは、
  • 「RSA 公開鍵」は
  • データの「列」で定義され、その列を構成するのは
  • 「整数」である「割る数」と
  • 「整数」である「(暗号化の為にする)巾乗の数」
と定義されています

で、実際には公開鍵のデータが決まったらそれをバイト列に変換しないと
机上の空論のまま終わってしまうわけなので
上のようなデータ構造の変換の仕方が別に用意されています
X.209 や X.690 がそれにあたります
  • ヘッダがあってデータの種類が書かれ
  • 次にデータの長さが書いてあって
  • 最後にデータが入ってる
  • それがずっと続く
みたいな感じです

ASN.1 での定義とその変換の仕方が合わさったものが
XML の場合の DTD に対応すると思えばいいのかな、と思います続きを読む
posted by OJH at 02:09| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月13日

RFC 5280 の 3.5. Management Protocols

Operational Protocols に続いて Management Protocols ということで
3.Figure 1. を見ると End entity が Repository や CA/RA と行う
やりとりの部分に Management transactions と名前が付けられています
PKIX の概要
利用者と認証局の間でやりとりするわけですから
証明書発行申請を受ける準備とかをしとく必要がありますもんね
他にどんなこと準備しとくべきかということが列挙されています

方法としてはインターネット PKI ってことでオンラインが多いでしょうが
オンラインに限定はせず郵送でも手渡しでも良いと書かれています
また、下で列挙された幾つかの機能がが
何か 1 つの仕組みで実現されていても問題ありません
メール・FTP・WWW など使う場合は他の PKIX な文章に従う必要があります

では、準備しとくべきことはというと

(a) registration:
登録申請を受けつけなくてはいけません
認証局がいきなり
「あなたの証明書を発行したいから公開鍵を提出しなさい」
なんて言ってきたりはしないので
先ずは利用者が認証局・登録局に申請を行うところから始まります
どうやって申請をすべきか・受けるべきか決めときましょう

(b) initialization:
初期設定、何の初期設定かというと、鍵関連の情報の設定です
例えば PKI を使っていくには信頼の階層のスタートとなる
認証局の自己署名証明書を手に入れなくてはいけません
証明書には認証局の公開鍵と認証してほしい情報が入ってるんでした
その証明書が確かにその認証局のもんだと確認しなくちゃいけません
また、証明書を発行してもらう場合も
先ずは鍵のペアを作るところから始まります
PKI のベースである鍵・鍵ペアを
何かしらのスタート地点として設定する必要があります

(c) certification:
証明する手順も準備しておかなくてはいけません
認証局のお仕事は証明書を発行することで証明書の内容を証明することでした
利用者の公開鍵が添えられた申請に署名をして証明書を作って
更にそれを利用者に渡すなりリポジトリで公開するなどしなくてはいけません

(d) key pair recovery:
鍵のバックアップというサービスもありえます。
秘密鍵を暗号化して保存してたんだけどそのパスワードを無くしてしまったり
そもそもサーバがクラッシュしてしまって秘密鍵が使えなくなってしまうと
証明書が使えなくなってしまい困ってしまいます
認証局が秘密鍵をバックアップしておいてくれると助かりますが
無くしたから頂戴なと言う人が本人かどうかとか
確認する手順・渡す手順も欲しいところです

(e) key pair update:
公開鍵暗号の鍵のペアは定期的に更新されるべきです
例えば証明書の有効期限が切れたから新しい証明書を発行してもらう
そのときに以前使った鍵のペアを再利用するというのは
あまり褒められたことではありません
新たな鍵が生成できたり、再利用ではないか確認したり?
できると良いのかな?

(f) revocation request:
失効要求もできなくちゃいけません
3.3 で失効に関して述べられていましたが失効が必要となるときがあります
秘密鍵が漏洩してしまったとか証明書の内容が変わってしまったとか
そんなときには利用者が発行されていた証明書の失効を依頼すべきでした
また、何かしら契約の違うことがあったら認証局は証明書を失効します
誰かが失効を依頼する方法・実際に失効する方法・リストを作って配布する方法
などが決まってなくちゃいけません

(g) cross-certification:
相互認証という仕組みがあると便利です
3.2 で「クロス証明書」と書きましたが「相互証明書」の方が分かりやすい?
認証局が他の認証局に対して発行する証明書を「相互証明書」と言いました
相互証明書を発行するということは審査とか任せてしまうということですから
どんなポリシーの証明書なら発行して良いかとか決めとかないといけません
好き勝手な証明書を発行されると信頼の失墜は基点の認証局にまで遡ります
なので相互証明書発行の手順も用意しておかなくちゃいけません
posted by OJH at 04:17| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月11日

暗号は暗号屋だし、セキュリティーはセキュリティー屋、なのか?

なぜ暗号は当事者しか読めないのか?という記事が
杜撰な研究者の日記さんで紹介されていました
記事は
出典:日経Windowsプロ 2004年8月号
 pp.84-89



(記事は執筆時の情報に基づいており,現在では異なる場合があります)
ということでちょっと? 古いですけど
  • シーザー暗号 -> 共通鍵暗号 -> 公開鍵暗号
という王道進行で暗号の解説がされています

で、何で杜撰な研究者の日記さんで紹介されていたかというと、
RSA の解読の困難さの根拠である素因数分解の難しさの話で
1024 bit な素数ってのは
log_10(2^1024) = 1024 * log_10(2) > 1024 * 0.301 > 300
なのでまぁ 300 桁はあります
512 bit つったら桁数半分としても 100 桁越えているわけで
4 年前でも 100 桁の素因数分解が大変とか言っちゃダメじゃないの?
ってツッコミ入れてらっしゃいました
「効率良く」ってことで「効率って何」って話もあるけど、と断りつつ

なんてこと言いながら自分は
  • 暗号は何年くらい持てば安全と言うのか
  • 暗号はどの程度の設備で解かれなければ安全と言うのか
  • 国家レベルとか個人レベルとかで安全の基準は 1 つなのか
とかって確かな認識があるわけではないので
512 bit な RSA が危険ってどういう危険なのかも良く分かってないし
そういうことも勉強していかないといけないなぁと思いました
CRYPTREC の報告書とか読んだらそういうの分かるようになるの???
posted by OJH at 01:27| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2008年12月10日

私も知らない PKI

あなたの知らない PKI というタイトルの特集記事がありました
全6回のうち3回までが掲載されていますが、目次は
  1. PKIのコア要素として、公開鍵暗号技術の概説
  2. PKIのコア要素として、電子証明書と認証局の概説
  3. PKIに関係する法令・制度として、電子署名の法的有効性などについて
  4. PKIに関係する法令・制度として、書面の電子化、本人確認での利用など
  5. PKIに関係する法令・制度として、行政機関でのPKI利用の例
  6. まとめとして、PKIの現状と今後の展望
「ポリシー」って連発しましたが
第2回で認証局のポリシーについても詳しく解説されてます
理屈は好きなんですが理屈ばっかり知っても仕方がないので
理屈のうえで実用の話も聞かせてもらえるこういう特集はありがたいです
posted by OJH at 23:56| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2008年12月09日

RFC 5280 の 3.4. Operational Protocols

Operational Protocol って何でしょうね <- バカ
3.Figure 1. で End entity と Repository の間のやりとりを
Operational transaction and management transaction と言ってますね
少なくともそこのやりとりの話だということは分かります
証明書を使うクライアントシステムに証明書や CRL を配るのに必要だそうです
証明書や CRL を配布する方法として LDAP, HTTP, FTP, X.500 が挙げられてます

X.500 は X.509 の親でディレクトリシステムを定義してるもんでした
「ディレクトリシステム」=「住所録? 参照用 DB?」を定義してるわけですから
そこから "さっ" と証明書や CRL を取り出せるようになってるはずです
場所の表現の仕方やなんかがちゃんと定義されています
LDAP は X.500 を簡単にしたもんだと言ってもあんまり語弊が無い? と思ってるので
まぁ LDAP で配布する方法もどこに置くかとか決めれるんでしょう

HTTP や FTP の場合は URI でもって置く場所が表現されることになるみたいです
Internet X.509 Public Key Infrastructure: Operational Protocols: FTP and HTTP
後で見るんだと思いますが X.509 の証明書は ASN.1 というフォーマットで記述され
どんな文字集合を置くかなんてことを定義されてます
一番小さい文字集合は PrintableString って言って ASCII の部分
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz '+,-./:=?
で表されるもののです、( と ) も使えるんだけど特別な場合なので除外
URI・メールアドレスを表現するには IA5String まで拡げる必要があります
IA5String はまぁ ASCII と思っちゃって良かったはず
証明書の中のどんな名前の拡張部分にどんな感じで URI を記述するか
そんなことを決めておかないとどこにあるか分からないと困ってしまいますもんね
あと、名前とか拡張子のルールも決まっていると分かり易い
更に HTTP だと MIME のような感じでデータが転送されますから
MIME type やらヘッダに付記すれき情報なんか決まってた方が良さそう

で、もちろん他の方法でも証明書や失効情報は配布できるわけで
それら場所の指定方法やら名前のルールやらを決めておいたり
最低限どんな情報を決めておけば利用者が参照してスムースに
必要なデータが得られるかということを考えて決めてあるみたいです

とすると、Operational Protocol ってのは「運用ルール」
もう少し言うなら「配布運用ルール」くらいがいいでしょうか
posted by OJH at 23:52| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2008年12月08日

RFC 5280 の 3.3. Revocation

証明書の失効に関してです
証明書を失効する必要性と
失効した証明書を利用者に伝える方法について述べられます

今まで証明書失効リストと書いていましたが面倒なのと
OCSP (Online Certificate Status Protocol) の和訳がアホくさいので
CRL (Certificate Revocation List) と記述してしまうことにします

証明書には有効期限が設定されているわけですが
必ずしも有効期限まで証明した内容が保持されるとは限りません
例えば社名が変更になると証明書に記載の組織名が変わってしまいます
また、秘密鍵が漏洩した危険性があると判断された場合にも
悪意のある人が漏洩した秘密鍵を用いて「なりすまし」する可能性があるので
認証局は証明書を無効として利用者に知らせるべきです

このような場合には X.509 では認証局が CRL を定期的に発行して
証明書が無効となったことを利用者に伝えることにしています
CRL には「失効された証明書のシリアルとその日付」がリストされ
更には認証局の署名が添えられて情報源の確かさが保証されます
Windows での CRL 表示 1Windows での CRL 表示 2
利用者は (なるべく) 最新の CRL を手に入れて
証明書を利用するときはそのポリシーと階層による証明書の有効性を確認し
更に失効されてないことまで確認してから証明書の利用を開始しなくてはいけません

失効された証明書が CRL に載るのは
失効が決まった後の最初の CRL の発行のときになります
また、証明書に記載されている有効期限が切れた場合には
CRL に載せる必要が無くなるのでリストから削除されます
有効期限が来るまでは一度載った証明書を CRL から除いてはいけません

CRL による失効の運用は
証明書と同じように配布の通信経路などを公開しておいても問題が無いので
簡単に行うことができます
一方で定期的に発行されるということから
失効と CRL の配布にタイムラグが発生してしまうという問題もあります
失効・配布・利用者が入手、それぞれの間にタイムラグが発生する可能性があります

ともかく、
証明書と同様に CRL もインターネットでの PKI の相互運用に大切なものなので
X.509 バージョン 3 で定義された証明書と共に
X.509 バージョン 2 で定義された CRL に関しても
RFC 5280 では詳しく述べられることになります

述べられてはいますが、RFC 5280 では CRL の利用を義務づけはしません
PKIX では最初でも名前を挙げた OCSP というプロトコルも用意されています
が、幸い (?) OCSP は RFC 5280 の守備範囲ではないので
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
を参照して下さい
(Certificate Revocation Tree という仕組みもあるようですが PKIX の範囲外みたい)
オンラインの失効リスト配布であれば時差は短かくできるので良いかもしれませんが
その仕組みの安全な実装・運用をしなくてはいけないので他の面倒も出てきます

CRL にしろ OCPS にしろ、どこで配布されているかは証明書に書かれています
3. Overview of Approach で証明書に記載のキャプチャーを貼ってあります
posted by OJH at 23:44| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

SSLを過信していませんか

SSLを過信していませんか――ネットバンキングに潜む誤解とは

怖いタイトルですね
でも、確かに、「鍵・錠のマークが出てれば安心」という認識は
セキュリティーの知識が無いよりも怖い事態を引き起こすかもしれません

SSL/HTTPS という仕組みで一体どのような対策がされるかというと
  • 暗号化による、ブラウザとサーバの間の「盗聴の防止」
  • 暗号化による、ブラウザとサーバの間の「データの改竄の防止」
  • 公開鍵証明書による「サーバー運営者の認証」
の 3 つです

南京錠のマークを見た時点で分かるのは HTTPS 通信だということなので
通信が暗号化されていて「盗聴」や「改竄」の心配が無さそうなことは確認できますが
「サーバー運営者の認証」に関しては実際にSSL証明書の中身を見てみて
ドメイン名や組織名などをちゃんと確認しなくてはいけませんし

ただ、それが分かったからといって通信相手が信頼できる人かというとまた話は別です
認証したからには自分が想定している通信相手なのかどうか確認する必要があります
悪い人が悪いことをしようとして立てたSSL的には正しいサイトかもしれません
まぁ、その場合は証明書に組織名まで書かれるようなものは用意できないと思われますが
例え、リンク先にあるように、「なりすまし」の対策として
ユーザーを大事にしている企業では、トップページなどに「当サイトのSSL証明書には次の様に記載されております」といった形で、内容が掲示されていることもあります。
で、証明書の中身とサイトの記述が一致しているからといって
証明書の記載が確かに自分の通信したい相手であるということが確認できなければ
クレジットカードの番号などの大切な情報を送らない方が良いということです
これは例え EV SSL サーバー証明書であったとしても同じことです
EV SSL サーバー証明書は「安全」であることを保証するものではありません

また、企業情報の載っていたいお安いSSL証明書もあって
その場合はドメイン名しか証明書に書いてなかったりしますが
そのドメインが信頼できるという確かな確信があるのでなければ
やはり大切な情報を送信するべきではありません
posted by OJH at 03:14| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。