2009年04月07日

RFC 5280 の 4.2.1.12. Extended Key Usage

「拡張鍵用途」は「鍵用途」を更に拡張、です。
基本的な用途は「鍵用途」で指定しましたが、それを拡張します。
認証局用の鍵の用途は既に「鍵用途」で列挙されているので?
「拡張鍵用途」はエンドエンティティー証明書に指定されます。

id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

鍵を使う組織は、その鍵の利用目的を定義することができます。
目的を指定する OID は IANA または ITU-T の X.660 に従わなくてはいけません (MUST)

この拡張はクリティカルでもノンクリティカルでもどちらでも構いません。

「拡張鍵用途」が記載されている場合には
その証明書は記載されている用途にしか使ってはいけません。
複数の用途が指定されている場合
利用したい用途が記載されていれば他に載ってる用途が分かる必要はありません。

証明書を利用するアプリケーションはその証明書を受け入れる為に
特定の内容の「拡張鍵用途」の記載を要求することができます (MAY)
(つまり、必要な「拡張鍵用途」が無ければ拒否していい、ってことかな)。
認証局がアプリケーションの為に「拡張鍵用途」を記載する場合、
でも鍵の用途を制限したいわけではない場合、
KeyPurposeId として anyExtendedKeyUsage を指定すれば OK です。
anyExtendedKeyUsage が指定される場合クリチィカルにすべきではありません (SHOULD NOT)
特定の用途を要求するアプリケーションは
その用途ではなくて anyExtendedKeyUsage が含まれてる証明書を拒否しても OK です(MAY)

「鍵用途」と「拡張鍵用途」の両方が記載されている場合
両方の拡張をそれぞれ処理しなくてはいけません (MUST)。
更にそれぞれの拡張に適った使い方しかしてはいけません (MUST)。
なので、「鍵用途」と「拡張鍵用途」が矛盾していたら
その証明書が使われることはありません (MUST NOT)。

以下の用途が定義されています:

anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement

id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement

id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature

id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
-- Email protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)

id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation

id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
-- Signing OCSP responses
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
ラベル:RFC5280 用途 公開鍵
posted by OJH at 00:01| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

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) | 日記 | このブログの読者になる | 更新情報をチェックする
×

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