2009年03月31日

RFC 5280 の 4.2.1.11. Policy Constraints

「ポリシー制約」拡張も認証局に発行された証明書に記載されます。
「ポリシー制約」は 2 通りの方法で信頼の階層の構築を制約します。
の 2 つです
id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }

PolicyConstraints ::= SEQUENCE {
     requireExplicitPolicy           [0] SkipCerts OPTIONAL,
     inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)
inhibitPolicyMapping が記載されている場合にはその値の数字で
その後に許されるポリシーマッピングの書かれた証明書の枚数を指定します
1 だったら、ポリシーマッピングが許されるのはその証明書までです。

requireExplicitPolicy が記載されている場合にはその値の数字で
その証明書以降何枚目からポリシーが要求されるかが記載されます
指定された場合には受け入れられるポリシーの記載が必要です
受け入れられるポリシーとは?
  • 証明書の利用者に要求されるポリシー識別子
  • ポリシーマッピングで等価であると宣言されたポリシーの識別子
のどちらかのことです

アプリケーションは requireExplicitPolicy が処理できないといけません (MUST)。
また、inhibitPolicyMapping が処理できるべきです (SHOULD)。
inhibitPolicyMapping が処理できたら policyMappings も処理できないといけません (MUST)。
inhibitPolicyMapping が処理できないアプリは
policyConstraints がクリティカルで inhibitPolicyMapping が記載されてる証明書を。
拒否しなくてはいけません (MUST)。

認証局が RFC 5280 に準拠する為にはポリシー制約を空で記載してはいけません。
空のポリシー制約を受けとってしまった場合に関しては特に述べません。

このポリシー制約拡張はクリティカルでなくてはいけません (MUST)。
posted by OJH at 03:02| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年03月25日

『「10大脅威」の相関図 』がちょっと素敵

去年あったセキュリティーに対する攻撃を振り返って
色々みんなで言い合った結果が発表されているようです

攻撃方法を知ることは利用者にとっても管理者にとっても大切なことですよね
  • 何か危ないらしいけど平気だろう
  • 何か危ないらしいけどどうしたら良いか分からないなぁ
みたいなことが無いように最新情報に目を向けとかないと

で、1 つ 1 つの脅威ってのもあると思うんですが
1 つ破られるとその後ドミノ倒し的に色々情報が!! なんてこともあり得ると思うので
相関図ってのはとっても素敵だなと思いました

でも、ちょっと残念なのは少し見辛いかなぁ
紙ベースのものをディスプレイで見てるのがいけないのかなぁ
posted by OJH at 13:39| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

RFC 5280 の 4.2.1.10. Name Constraints

「名前制限」は認証局証明書の中でだけ使える拡張です (MUST)  。
その証明書を含む信頼の階層の中に現れるサブジェクトの名前に制限を加えます。
具体的な対象は Subject と Subject Alternative Name です 。
                                                                                                                                                                        
拡張では Directory Name や FQDN やメールアドレスなど何かしらの形式で
その証明書以降の階層で使える・使えない名前が指定されます 。
制限が適用されるのは該当する形式の名前が指定されている場合で
制限が与えられていても該当する形式が無ければその証明書は有効となります 。
                                                                                                                                                                        
自己発行証明書に対しては「名前制限」は一般には適用されません 。
(例外はその自己発行証明書が階層の最後にくるとき) 
例えば鍵の更新などの場合に発行する証明書の場合は適用されないので
スムースな運用が期待できます。
id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }

NameConstraints ::= SEQUENCE {
     permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
     excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
     base                    GeneralName,
     minimum         [0]     BaseDistance DEFAULT 0,
     maximum         [1]     BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)
NameConstraints は permittedSubtrees と excludedSubtrees で構成されます。
permittedSubtrees は許可される方で excludedSubtrees が除外される方です。
excludedSubtrees にマッチしたら permittedSubtrees にマッチしてても除外です。
permittedSubtrees があったら permittedSubtrees にマッチしなかったら除外
excludedSubtrees があったら excludedSubtrees にマッチしたら除外、かな?

この拡張はクリティカルでなくてはいけません (MUST)
X.400 Address 形式で名前を載せるべきではありません (SHOULD NOT)
NameConstraints が空な証明書を発行してはいけません (MUST NOT)

証明書を処理する場合には、「名前制限」の名前の形式として
  • directoryName
には対応していなくてはいけません (MUST)。また、
  • rfc822Name
  • uniformResourceIdentifier
  • dNSName
  • iPAddress
の形式には対応しているべきです (SHOULD)
(これらは Subject Alternative Name で出てきた名前の形式ですね)

クリティカルな「名前制限」にとある形式で制限が記述されていて、
検証したい階層の「名前制限」のある証明書の下位の階層の証明書の
「サブジェクト」か「サブジェクトの別名」にその形式の名前があるなら
「名前制限」に従って制限を加えるか
若しくはその証明書を拒否しなくてはいけません (MUST)

RFC 5280 では minimum と maximum は使いません
なので minimum は記述するなら 0 でなくてはいけません (MUST)
maximum は記述してはいけません (MUST)
しかし、若し minimum や maximum が記述された証明書に遭遇してしまったら
正しく解釈してやるかその階層を拒否するかしなくてはいけません (MUST)

各形式に関して

■ 制限の対象が URI の場合、URI のホスト名部分を制限します。
制限は FQDN を指定するものでなくてはいけません (MUST)。
ホスト若しくはドメイン部分を指定することができます (MAY)。
例えば "host.example.com" とか ".example.com" の形です。
"." で始まる場合、
".example.com" の場合はその前に色々なものが来ていてもマッチします。
例えば "host.example.com" や "my.host.example.com" が対象となります。
しかし "example.com" はマッチしません。
"." では始まらない場合、
ホスト名が指定されていると解釈されます。
もし、
  • URI に関する制限が書いてあって
  • 下位の証明書に SubjectAlternativeName があって URI が書いてあって
  • URI の authority 成分にホスト名が含まれてない場合 (空とか IP アドレスとか)
その下位の証明書は拒否されなくてはいけません (MUST)

■ 制限の対象がメールアドレスの場合、以下のものが指定できます (MAY)
  1. 特定のメールボックス
  2. 特定のホストの全てのメールボックス
  3. 特定のドメインの全てのメールボックス
1. の場合はメールアドレスを完全な形で記述します。
2. の場合はホスト名を指定します
3. の場合は "." で始めてドメインを表現します
この場合やはり ".example.com" は "example.com" にはマッチしません

古い実装だと emailAddress がサブジェクトの DN に記載されていることがあります。
(4.1.2.6 を参照)
「名前制限」に rfc822Name 形式で記載がある場合には
サブジェクトの emailAddress にも適用されなくてはいけません (MUST)。
emailAddress の ASN.1 での書き方と OID は Appendix A に書かれています。

■ 制限の対象が DNS 名の場合 "host.example.com" のような形で書きます。
DNS 名の場合指定された文字列の左に何か足されたものもマッチします。
例えば上の場合 "www.host.example.com" もマッチします。
"host1.example.com" はマッチしません。

■ 制限の対象が directoryName の場合、空でない場合にはサブジェクトと
更にサブジェクトの別名に適用しなくてはいけません (MUST)。

directoryName の制限を確認する場合には、DN を比較しなくてはいけません (MUST)。
最低でも Section 7.1 で述べられるルールに従い比較しなくてはいけません (MUST)。
「認証局は ISO の完全な DN 比較アルゴリズムを仮定してはいけない」(MUST)
と書いてあるんですが、何でですしょう、厳しすぎるんでしょうか??
エンコーディングはサブジェクトやサブジェクトの別名に準じます (MUST)

■ 制限の対象が x400Address の場合、
サブジェクトの別名の x400Address 形式の名前を制限します。

■ 制限の対象が IP アドレスの場合、
Section 4.2.1.6 の書式に加えて以下の要件を満たさなくてはいけません (MUST)。
IPv4 の場合、8 octets を RFC 4632 の CIDR 形式で 記述します。(MUST)
IPv6 の場合、32 octets を同様の形式で記述します。(MUST)
例えば class C の 192.0.2.0 は "C0 00 02 00 FF FF FF 00" になりますが
CIDR 形式で 192.0.2.0/24 と記述します。


otherName, ediPartyName, registeredID に関しては RFC 5280 では述べません。
他の文章で指定されるのでそちらを見ましょう。

その他、符号化の話や比較については Section 7 を参照して下さい。
posted by OJH at 03:31| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年03月16日

「不況に勝つための SSL 投資」

SoftwareDesign 2009 年 3 月号の "Hosting Department" っていう特別連載で
EV SSL サーバ証明書の解説が載ってたんですが
? って思ったところがあったので重箱の隅を備忘録

H-2 ページの上の段落で
EV SSL 証明書も従来の SSL 証明書と同様にセキュアなハッシュ関数を含んでおり
多分これは「ハッシュ関数」ではなくて「電子署名」のことを言っているんだと
この後から特に断りが入らず Windows 環境に特化したような話になってしまって
OCSP 機能では後述のようにブラウザのアドレスバーの表示を緑色に変えることで EV SSL 証明書の有効性を示しますが
IE7 などでは緑で表示するのに OCSP でのチェックを通る必要があるのかもしれませんが
OCSP は通常の証明書でも利用されている機能で EV とは特別な関係にはない、はず
と思ったら Firefox も OCSP 切ると緑じゃなくなったな
OCSP は必須になったんですか? 教えて偉いひと

まぁ、Firefox はオープンソースなのでちゃんと読めばアルゴリズム分かるんでしょうが
他のブラウザに関してはリーバースエンジニアリング的にしか
EV で表示が緑っぽくなるアルゴリズムが分からない状況なので
色々混乱しちゃったりする部分もあるのかなぁ、と思いました
アルゴリズム公開してほしいですネ!!
ラベル:EV ssl
posted by OJH at 00:02| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年03月13日

新たな中間者攻撃にはEV SSLの活用を――ベリサイン

これは、BlackHat で公表された
に対するアンサーソングですね。
こりゃどんな攻撃だったかというとにある通り、
エンドユーザーの SSL や HTTPS に対する理解の浅さを利用したり
巧妙な? 見た目の偽装によって中間車攻撃に気付かせない工夫をする
という、良く考えると中々怖い攻撃だなと思うんですが
(自分がどれだけ SSL 通信に敏感になっているか分かりませんし、いわんや例えばうちの母親)
EV だったら見た目からして分かりやすいし大丈夫だよ!! ってこと言ってらっしゃいます。

「見た目からして分かりやすい」っていうのは
EV SSL サーバ証明書を使ってるサイトを見にいくと、対応ブラウザであれば
  • アドレスバーなど分かりやすい部分が緑いろっぽくなる
  • アドレスバーなどに証明書所有者や発行者の名前が表示される
ので、そのサイトが一体誰によって運営されてるか分かりやすくなる、というものです

そんなん EV SSL じゃなくたって審査してある証明書だったら表示したらいいじゃない
と思う方もいらっしゃいますでしょうが、上は技術的な話の一部でして
審査基準も統一ルールが定められてて中々厳しい内容になっていたりして
多分、だから、その審査基準の下で名前表示してもいいよね、ってことなんだと思います。
たぶん。

Moxie Marlinspike さんのプレゼンだと
login.yahoo.com や mail.google.com のアカウント情報が引っこ抜けたということなので
この辺りに EV SSL サーバ証明書を導入した方がいいよ!! って言ってるんだと思いますが
きっとクラウドがバリバリの Web サーバが後に沢山控えているだろうサービスで
EV SSL を実現するとなると何枚くらい証明書買ったら勘弁してもらえるんでしょうねぇ。
ラベル:EV MITM
posted by OJH at 22:17| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

IIS で SSL するなら certreq.exe が素敵

Windows Server には certreq なんてコマンドがあったんですね
IIS 使っていいて SSL サーバ証明書を導入しようとしたときに
CSR を作るウィザードとか出てくると思うんですが
その API をコマンドラインから叩けるものみたいです
別件で検索してたら
というページを拝見しまして
を見ながらいじってみました。

作ってみた inf ファイルはこんな感じ
[NewRequest]
Subject = "C=JP,ST=Tokyo,L=Chiyoda-ku,O=SSL-PKI,CN=ssl-pki.seesaa.net"
Exportable = TRUE
KeyLength = 2048
MachineKeySet = TRUE
SMIME = FALSE
比較的ミニマルな感じで作ってみました。
Subject の RDN の区切り文字が "," なんですよね。
これは IIS のウィザードでも "," が入力できないのと対応しています。

これを test.inf という名前で保存して
> certreq -new test.inf test.csr
とコマンドを打つと test.csr に CSR が書き出されます。
秘密鍵は Windows の奥底に保存されて眠っているはず。
RFC 5280 のことは考えず、とりあえず署名して証明書作ります。
ここは慣れてるので OpenSSL で
$ openssl req -x509 -new -out CA.crt -keyout CA.key
$ openssl x509 -req -in test.csr -CA CA.crt -CAkey CA.key -set_serial 37 -out test.crt
これで test.crt という証明書ができました。

最後にこれを Windows にインストールします
> certreq -accept test.crt
これで「保留中の要求を処理し、証明書をインストールする」と同じ状態になります。
「IIS マネージャ」の「サイトのプロパティ」の「ディレクトリセキュリティ」の「サーバ証明書」から
「既存の証明書を利用」とか「現在の証明書を置き換える」を選ぶと
test.crt も一覧の中に出てきます。
今回はここで止めてしまったんですがこれだとルート証明書が無くてちょっと良くないかも。
まぁ、実際はルート証明書とか中間認証局の証明書もインストールしましょう。

IIS で SSL するだけなら簡単なんですが
CSR とサイトが紐付いてしまっているうえに
「更新」で Subject の Distinguished Name や鍵長が変更できなかったり
不自由な部分があるんですけど certreq.exe を使えば分離できて happy な感じ。
もしかしたらウィザード自体が個別に呼べたりするなら何の問題も無いんですけど。
変に CSR 作って証明書入れるだけの為にサイト作るよりはこっちがスマートだなぁ。
ラベル:CSR IIS Windows ssl
posted by OJH at 00:41| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年03月11日

RFC 5280 の 4.2.1.9. Basic Constraints

「基本制限」拡張は
  • その証明書は認証局のものかどうか
  • その証明書を含む階層の深さを幾つまで認めるか
に関して記述されます。
何で「基本」かっていうと、階層をの検証の為に X.509 のバージョン 3 で
拡張を用意したからで、証明書が認証局のかどうかってのは基本ですよね。

id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

cA

認証局かどうかに関しては cA という真偽値を入れるところで表現します。
これが TRUE ならば証明書の公開鍵を使って署名を検証することを
認証局が認めていることになります。

4.2.1.3. で公開鍵の利用方法の制限に関して見ました。
署名の検証に使うには keyCertSign が指定されてなくてはいけませんでした。
keyCertSign が指定されていたら cA も指定されてなくてはいけませんし
cA が指定されていなかったら keyCertSign は指定されてはいけません (MUST NOT)。
「基本制限」が無かったり、あっても cA が指定されていなかったら
その証明書の公開鍵を署名の検証に使ってはいけません (MUST NOT)

pathLenConstraint

階層の深さに関しては pathLenConstraint というので指定します。
これは、cA が TRUE でないと意味がありません (keyCertSign も同時に指定されてます)。
cA が TRUE で keyCertSign が設定されてなかったら
pathLenConstraint は設定してはいけません (MUST NOT)。

認証局の証明書である場合 pathLenConstraint でもって
「階層に現れる自己署名証明書でない中間証明書の枚数」の最大値を指定します。
pathLenConstraint が 0 だと中間証明書を許さないということになります。
エンドエンティティなど階層の最後の証明書は数えないので注意しましょう。
pathLenConstraint は 0 以上の整数でなくてはいけません (MUST)。
pathLenConstraint が無い場合は階層の深さは無制限となります。

Critical

RFC 5280 に従う認証局は、
証明書の電子署名を検証する為の認証証明書を発行するときには
「基本制限」拡張を含めなくてはいけません (MUST)。
また、「基本制限」拡張はクリティカルでなくてはいけません (MUST)。
証明書の電子署名を検証する以外の目的の認証局証明書であれば
(CRL の署名検証とか鍵交換に使う場合)
クリチィカルであってもノンクリティカルであっても構いません (MAY)。
エンドエンティティーの場合もクリティカル/ノンクリティカルを問いません (MAY)
ラベル:階層 認証局 RFC5280
posted by OJH at 03:11| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年03月07日

RFC 5280 の 4.2.1.8. Subject Directory Attributes

「サブジェクトディレクトリ属性」はサブジェクトの属性の確認に使われます。
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }

SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Attribute               ::= SEQUENCE {
      type             AttributeType,
      values    SET OF AttributeValue }
            -- at least one value is required

AttributeType           ::= OBJECT IDENTIFIER

AttributeValue          ::= ANY -- DEFINED BY AttributeType
属性の SEQUENCE になるわけですが、これは RDN と何が違うんですかねぇ
RelativeDistinguishedName ::=
  SET SIZE (1..MAX) OF AttributeTypeAndValue

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

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY -- DEFINED BY AttributeType
「サブジェクト」とか「発行者」に書くのと何が違うんでしょう
重要度?
例として nationality が挙げられていたりしますが。

この拡張はノンクリティカルにしなくてはいけません (MUST)
posted by OJH at 12:32| Comment(1) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

RFC 5280 の 4.2.1.7. Issuer Alternative Name

4.2.1.6 で Subject に対する Subject Alternative Name を見ましたが
Issuer Alternative Name は Issuer に対する別名になります
サブジェクトの別名と同じ様に記載されなくてはいけません (MUST)

サブジェクトの別名は証明書階層の検証の際に利用されるのですが
発行者の別名は 6 節で説明される証明書階層の検証には利用されません
なので、この拡張はノンクリティカルとすべきです (SHOULD)

id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }

IssuerAltName ::= GeneralNames
ラベル:別名 発行者 RFC5280
posted by OJH at 12:09| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年03月02日

緑色アドレスバー、EV SSL証明書

NETCRAFT という会社が EV SSL サーバ証明書の普及率の調査結果を公表してくれてます

Extended Validation SSL Certificates 2 Years Old が元記事
One Million SSL Sites on the Web という記事によると
この会社が集めた有名な認証局による証明書の枚数が 100 万枚を越えて、
今回は 1,028,868 枚のうち 11,300 枚が EV SSL サーバ証明書だったそうです

1% かよっ! っていうとそういうわけでもないようで
更に人気サイト 1,000 と 10,000 と 100,000 などに絞って表を出してくれていて
例えば人気上位 100,000 サイトの SSL サーバ証明書の枚数が 7,012 枚で
その内 710 枚が EV SSL サーバ証明書だったそうです、10%!!

証明書の枚数の数え方が良く分からないんですが、負荷分散とか
でもまぁ、1 割っていうと中々普及している感じがしますね
日本でも銀行以外の利用も増えているようですし
効果的に利用されるといいなぁと思っております
適材適所で
ラベル:EV SSL
posted by OJH at 23:01| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする
×

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