2009年02月28日

OpenSSL は桁が溢れる

openssl コマンドを使うと簡単に自己署名証明書が作れます
Extension をどうにかしようとすると設定ファイルを書かないといけませんが
$ openssl req -new -x509 -nodes
とすれば秘密鍵がファイルに保存されて証明書が PEM で標準出力に流れます
これだと 30 日有効な証明書が出るのですが
-days というオプションで有効日数を指定してやることもできます

試しに手元のパソコンで
$ openssl req -x509 -days 10553 -new -nodes | openssl x509 -noout -text
としてみたところ
Validity
    Not Before: Feb 27 17:44:15 2009 GMT
    Not After : Dec 14 11:15:59 1901 GMT
見事に 2038 年問題が発生しました
ASN.1 を parse してみたところ (作りなおしたので日付ずれますが)
112:d=3  hl=2 l=  13 prim: UTCTIME           :090227174633Z
127:d=3  hl=2 l=  15 prim: GENERALIZEDTIME   :19011214111817Z
notBefore と notAfter で型が違っていました
RFC 5280 には
CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime
と書いてあるのに何故 GeneralizedTime が出てくるのでしょう?
2038 年でも UTCTime なはずなんだけど
試しに 64bit な CPU で同じことをしてみたところ
111:d=3  hl=2 l=  13 prim: UTCTIME           :090227182337Z
126:d=3  hl=2 l=  13 prim: UTCTIME           :380119182337Z
溢れずに UTCTime で出てきました
ん〜続きを読む
posted by OJH at 03:27| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年02月26日

RFC 5280 の 4.2.1.6. Subject Alternative Name

4.2.1.6.  Subject Alternative Name

「サブジェクトの別名」を定義します。
サブジェクトの別名を定義したり、サブジェクトの名前を指定したりします。
CommonName に相当するものが複数追加できると思えば良いのだと思います。
id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
     otherName                       [0]     OtherName,
     rfc822Name                      [1]     IA5String,
     dNSName                         [2]     IA5String,
     x400Address                     [3]     ORAddress,
     directoryName                   [4]     Name,
     ediPartyName                    [5]     EDIPartyName,
     uniformResourceIdentifier       [6]     IA5String,
     iPAddress                       [7]     OCTET STRING,
     registeredID                    [8]     OBJECT IDENTIFIER }

OtherName ::= SEQUENCE {
     type-id    OBJECT IDENTIFIER,
     value      [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {
     nameAssigner            [0]     DirectoryString OPTIONAL,
     partyName               [1]     DirectoryString }
具体的に何が指定できるかというと
  • メールアドレス
  • DNS 名
  • IP アドレス
  • URI
などが一般に使われますが、他も、全くもって独自なものも、使えます。
サブジェクトの別名として上記属性が記載されているならば
証明書を解釈するときにそれら項目は使われなくてはいけません (MUST)。

サブジェクトの別名も正式な名前として認識されるべきものなので、
認証局はこれらの名前もサブジェクトのエンティティーを指すことを
しっかりと審査しなくてはいけません (MUST)。
別名だからといって、適当なものを書いてはいけません。

更に、サブジェクトの識別子として指定するものが
メールアドレス等や DNS 名などサブジェクトの別名に書くも「だけ」の場合
サブジェクトは空としてサブジェクトの別名に記載しなくてはいけません (MUST)
ザブジェクトが空なら、サブジェクトの別名はクリティカルでなくてはいけません (MUST)
サブジェクトが空でない場合にはクリティカルにはしないべきです (SHOULD)

ちなみに、RFC 5280 の 4.1.2.4. Issuer
DistinguishedName に入れる属性 (RDN?) を見ました
domainComponent というのもありましたが
ここの DNS 名 (dNSName) とは別ものなので注意しましょう。

メールアドレスの記載は rfc822Name として記載しなくてはいけません (MUST)。
RFC 2821 の 4.1.2 で定義されている Mailbox という形式で記載します。
これは、よくある abc@def.gji のような name@domain の形です
(@ が入っているので PrintableString ではなく IA5String になります)。
メールの From や To には「"山田 太郎" <taro@example.com>」のように
色々と飾りを付けることもできますが
RFC 2821 で定義されてる Mailbox というのは taro@example.com だけの形式になります
ドメインが国際化ドメインの場合の話は
7.5. Internationalized Electronic Mail Addresses で行います。

IP アドレスを記載する場合には iPAddress にとして記載します。
RFC 791 で定義されているように
アドレスをネットワークバイトオーダーなバイト列で表現します。
IPv4 なら 32bits, IPv6 なら 128bits, 省略せずに書きます。(MUST)

DNS 名を記載する場合には dNSName に入れます
(IA5String だと書いてあるんですが何故でしょ? Printable では足りない??)。
DNS 名は RFC 1034 RFC 1123 に記載されてるのでそれに従います。
特に、大文字・小文字は区別しません。
" " も DNS 名として認められていますが使ってはいけません (MUST NOT)。
メールアドレスを DNS 名風に書いて (@ -> .) 載せてもいけません (MUST NOT)。
rfc822Name を使いましょう
(っていうか誰がそんなことを? と思ったけれどメールアドレスの所有者が
その DNS 名が書かれた証明書を発行できてしまうと問題がありそうですね。
攻撃したい DNS 名のホスト名部分が local name なメールアドレスは取れちゃうかもだし。
国際化ドメインに関しては 7.2 で。

URI を記載する場合には uniformResourceIdentifier に入れます (MUST)。
(やっぱり IA5String になります)
  • 相対 URI ではいけません (MUST NOT)
  • RFC 3986 で指定される記法・エンコーディングに従わなくてけはいけません (MUST)
  • URI は http や ftp から始めて : の後も全部書かないといけません (MUST)
  • authority = [userinfo"@"]host[":"port] の host は FQDN or IP アドレス (MUST)
Internationalized Resource Identifiers (IRIs) に関しては 7.4 で

RFC 3986 の 6.2.2.1. Case Normalization では
  • スキームは大文字小文字を区別しない
  • ホスト名部分大文字小文字を区別しない
  • その他の部分は大文字・小文字を区別する
とあります。
CN と同等なものなので比較の方法が決まっていないといけませんが
その方法に関しても 7.4 で述べられます

DN を記載するときは directoryName に記載します。
格納するものは 4.1.2.4. Issuer で述べたのと同じとします。
特に? サブジェクトの DN と認証局のペアから
エンティティーは一意に決まらなくてはいけませんでしたし (MUST)
認証局は 1 つの DN に対してそれがサブジェクトとなる証明書を
何枚も発行することができました (MAY)

サブジェクトの別名として事前に想定されていないタイプの名前は
otherName として格納することができます (MAY)
otherName には type-id と value のペアを記述します。
type-id は OID です。
名前は OID に則した形で value に入れます。
例として Kerberos のことが書いてあるけど、省略。

サブジェクトの別名はサブジェクトと同様に
4.2.1.10. Name Constraints を用いて制限を加えることができます (MAY)

サブジェクトの別名が拡張として入っていたら
GeneralName は少なくとも 1 つは入っていなくてはいけません (MUST)
サブジェクトは空でも OK でしたが
別名の GeneralName の中身は空ではいけません (MUST NOT)
例えば IA5String は空でも OK ですが
RFC 5280 的には rfc822Name が空なのはアウトです。
「そんな証明書に関しての検証方法は書きません」って書いてあるんですが
これは拒否しろということでしょうか。

サブジェクトの別名にワイルドカードが入ってる場合の解釈の仕方を
RFC 5280 では定義しません
ワイルドカードが必要な場合もあるでしょうが
そのときは解釈の方法を各次で定義しましょう
posted by OJH at 02:20| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年02月21日

CRYPTRECシンポジウム2009


電子政府推奨暗号リストの更新に向けてシンポジウムが開かれました
今のリストは 2003 年に提出されています
10年使える暗号を目指してたらしいですが既に老朽化が激しいと
ぽんぽん変更できるものでもありませんが IT の流れからすると 10 年ってやっぱり長いんですね

「サイドチャネル攻撃耐性への評価手法に懸念」ってことですが
一般的な評価方法ってないんですかね? 最低限満たさなくてはいけない基準とか
確かに実装特有の脆弱性があるかどうかってのは評価は難しいと思うので
差分での攻撃とか、それくらいの耐性くらいは評価できないのかなぁ
SASEBO ってそういうのに使うんでしたっけ、どうでしたっけ

記事のタイトルにあるのは横浜国立大学の松本勉さんの
「(署名やブロック暗号,ハッシュ関数など)カテゴリごとに2種類あれば十分ではないか」
という提言からだそうです
今のは多すぎると、29コあります
カテゴリが8コなので16コで十分なんじゃない? ってことですね大体半分

今度からリストを
  • 電子政府推奨暗号リス
  • 推奨暗号候補リスト
  • 互換性維持暗号リスト
に分けるらしいし、電子政府推奨暗号リスは数絞って
推奨暗号候補リストで層の厚さを見せるって感じになるんですかね
例えば現行だと署名アルゴリズムは
  • DSA
  • ECDSA
  • RSASSA-PKCS1-v1_5
  • RSA-PSS
ですが、これは DSA と ECDSA が生き残りのバトルってことになるのかなぁ
まぁ、DSA が勝つか、そしたら

ベンダーフリーであること前提でリストが絞られると分かりよくていいですね
続きを読む
posted by OJH at 00:53| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2009年02月14日

RFC 5280 の 4.2.1.5. Policy Mappings

ポリシーマッピングは認証局の証明書に記載されます
中身はどんなものかというと
issuerDomainPolicy と subjectDomainPolicy のペアが
ずらずらと並んでいます
id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
     issuerDomainPolicy      CertPolicyId,
     subjectDomainPolicy     CertPolicyId }

CertPolicyId ::= OBJECT IDENTIFIER
何を意味するかというと、
証明書ポリシーが「OID とオプションのペア」でしたが
PolicyInformation ::= SEQUENCE {
     policyIdentifier   CertPolicyId,
     policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                             PolicyQualifierInfo OPTIONAL }
サブジェクトに記載の認証局のポリシーが
発行者の認証局のポリシーと同等であるということを保証します

発行者である CA を信頼している場合にはそのポリシーを受け入れてるわけですが
ポリシーマッピングによって他の認証局のポリシーが同等であると保証されるので
受け入れてもいいんじゃなかろうか、ということになるというわけです

ポリシーマッピングに現れる issuerDomainPolicy は
証明書ポリシーにも登場しているべきです (SHOULD)
また、anyPolicy ってのがありましたが
これはポリシーマッピングに入れてはいけません (MUST NOT)

This extension MAY be supported by CAs and/or applications.
って書いてあるけどそりゃ RFC に書いてるんだからそうだろ
って思うのは英語の読解の弱さでしょうか。
RFC 5280 に従うならばこの拡張はクリティカルとしましょう。

で、具体的にどんな場合に使うかが書かれているんですが、
p1 っていうポリシーを使ってるんだけど p2 っていうポリシーに変更しようとすると
移行期間を設定してその間は両方のポリシーを使えるようにしたいです
そんな場合にはどうするかというと、どうしてるんでしょうこれ?
多分自己署名証明書を 3 つ用意していて
  • 1 つは最初からある p1 な自己署名証明書 A
  • 1 つは今後使っていきたい p2 な自己署名証明書 B
  • 1 つは p1 なんだけど (p1, p1), (p1, p2) という 2 つのペアのマッピング付き C
A と B、または B と C があれば p1 も p2 もどっちも受け入れられるということかな?
で、最終的には B だけにできそうです
posted by OJH at 23:33| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年02月05日

RFC 5280 の 4.2.1.4. Certificate Policies

「証明書ポリシー」
証明書ポリシーはポリシーを表現する OID とオプションのペアで
1 つだけではなく幾つも記載することができます
各 OID、つまり各ポリシーは 1 つの証明書で 1 つだけ載せることができます (MUST NOT)
また、オプションはポリシーの定義を変えてしまうようなものではダメとあります (MAY)
are not expected to change the definition of the policy
ってポリシーを変えるようなオプションってどんなオプションなんでしょうねぇ

エンドエンティティーの場合、証明書ポリシーで表現されるのは
  • その証明書はどんなポリシーの下で発行されたか
  • その証明書はどんなどんな用途で使われることが想定されてるか

認証局の証明書の場合、証明書ポリシーで表現されるのは
  • その証明書を含む階層で使えるポリシーの制限
認証局は、使えるポリシーを制限したくない場合
anyPolicy (OID 2.5.29.32.0) というポリシーを使うことができます (MAY)

証明書ポリシーがクリティカルな場合には、
階層検証時にオプション含めこの拡張を理解できないといけません (MUST)
分からない OID 等が入っていたらその証明書を拒否しないといけません (MUST)

相互運用の為には各ポリシーは OID だけでオプション無しがお薦めです (RECOMMENDS)
OID だけでは足りない場合にはオプションを付けてもいいですが
オプションは RFC 5280 に載ってる "CPS Pointer" と "User Notice" だけ使いましょう
でも、anyPolicy が指定されている場合、オプションで制限を受けなくてはいけません
Only those qualifiers returned as a result of path validation are considered.
これの意味が分からないので保留
「階層の検証に使うんではなくて検証が済んだ後に見るべきもの」ってこと?

さっきも書いた通り、RFC 5280 ではポリシーのオプションを 2 つ用意しています
"CPS Pointer" と "User Notice" です
「CPS がどこに置いてあるか」と「利用者への注意」ですね
ポリシーを書いたり証明書を発行するときに指定します

CPS Pointer は認証局の発行している CPS の場所を示します
CPS とは? あなたの知らないPKI(2)--PKIのコア要素/電子証明書と認証局
CPS Pointer は URI で記述します
拡張がクリティカルかどうかに関係なくこのオプションの処理方法は個々に任されています

User notice はその証明書を使う人達に提示する内容です
若し同じ user notice が複数あったら 1 つだけ表示します
重複を避ける為に user notice はエンドエンティティーか
又は他の認証局から発行された認証局証明書にのみ載せるべきです (SHOULD)

User notice は更に 2 つオプションを持ちます
noticeRef と explicitText です
RFC 5280 では noticeRef は使うべきではありません (SHOULD NOT)
noticeRef は文章の場所を指していて、explicitText は直接載せています

拡張のオプションに noticeRef と explicitText の両方が載っている場合
noticeRef で示される文章が確認できるならそちらを表示すべきです (SHOULD)
noticeRef の方がダメであれば explicitText を表示すべきです (SHOULD)

注意:
explicitText は最大 200 文字ですが
無頓着な認証局はこれを越える文字を証明書に載せています
なので、証明書を解釈するものを作る場合は柔軟な実装をすべきです (SHOULD)
posted by OJH at 19:42| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする
×

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