2009年06月28日

RFC 5280 の 4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point)

「最新 CRL」って訳してありました。
デルタ CRL ってありますがデルタってのはΔですかね。
数式でΔっていうと差分を表わす記号ですが
CRL Distribution Points 定期配信されるCRL の間を埋めて
なるべく最新の情報を提供するものとして Delta CRL が用意される場合があるようです。
バックアップでいうところの差分バックアップのような感じで。
で、それが何処に置いてあるかを指し示す拡張です。

記述方法ですが、やはり CRL の配布の話なので
CRL Distribution Points に書かれている方法で記述します。
RFC 5280 に従うならばこの拡張はノンクリティカルでなくてはいけません (MUST)。

CRL に関する詳細は 5 節で、とのことなので 5 節待ちで。

id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }

FreshestCRL ::= CRLDistributionPoints
ラベル:CRL Delta CRL
posted by OJH at 19:00| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年04月19日

RFC 5280 の 4.2.1.14. Inhibit anyPolicy

「全ポリシー禁止」って訳されてます。
この拡張は認証局に対して発行される証明証に使われます。
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }

InhibitAnyPolicy ::= SkipCerts

SkipCerts ::= INTEGER (0..MAX)
4.2.1.4. Certificate Policies で anyPolicy ってありました。
OID は 2.5.29.32.0 で、全てのポリシーにマッチする、という意味でした。
ポリシーを制限しないときに使いました。
anyPolicy って何でもありってのは sub CA に何されるか制御できないので、
「全ポリシー禁止」は anyPolicy が他のポリシーにマッチすることを禁止します。
但し証明証が自己署名な中間証明証である場合を除きます。

具体的には整数が指定されます。
その証明証以降何枚目から anyPolicy が使えなくなるか指定します。
例えば 1 であれば、
「全ポリシー禁止」が記載されている証明証のサブジェクトが発行した
証明証に記載されている anyPolicy は有効としても良いけれども、
それ以降の証明証に記載される anyPolicy は無効となります。

「全ポリシー禁止」はクリティカルにしましょう。
posted by OJH at 23:58| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年04月12日

RFC 5280 の 4.2.1.13. CRL Distribution Points

「CRL 配布点」は CRL を配っている方法・場所を指定します。
この拡張はクリティカルではないべきです (SHOULD)。
しかし RFC 5280 は、認証局もアプリケーションのどちらも
「CRL 配布点」に対応していることを推奨します (RECOMMENDS)。
CRL に関しては 5 節にてより詳しく説明されるのでそちらを。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }

CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {
     distributionPoint       [0]     DistributionPointName OPTIONAL,
     reasons                 [1]     ReasonFlags OPTIONAL,
     cRLIssuer               [2]     GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {
     fullName                [0]     GeneralNames,
     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {
     unused                  (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6),
     privilegeWithdrawn      (7),
     aACompromise            (8) }
cRLDistributionPoints は DistributionPoint の列で
DistributionPoint は
  • 配布点 (distributionPoint)
  • 理由 (reasons)
  • 発行者 (cRLIssuer)
の 3 つで構成されています、が、どれもオプションで省略可能です。
でも reason だけでは変なのでそれだけってのは無し (MUST NOT)、
distributionPoint か cRLIssuer はなくちゃいけません (MUST)。
証明書の発行者が CRL の発行者ではない場合には
cRLIssuer は必須で (MUST) 発行者の名前を記載します。
証明書の発行者が CRL の発行者の場合には
cRLIssuer は載せてはいけません (MUST)。
なので distributionPoint を載せなくてはいけません (MUST)。
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
     otherName                 [0]  AnotherName,
     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 }

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

AttributeTypeAndValue ::= SEQUENCE {
        type     AttributeType,
        value    AttributeValue }
distributionPoint を載せる場合には、
GeneralName の列から成る GeneralNames か
1 つの値の nameRelativeToCRLIssuer を記載します。
DistributionPointName を複数載せる場合には
方法は色々でも同じ CRL を指し示すようにします。
例えば LDAP と HTTP で同じ CRL を配布してあってそれを指定するとか。

distributionPoint が directoryName を含む場合には、
  • そのエントリには reason に関連した CRL を含む
  • その CRL の発行者は cRLIssuer
CRL は certificateRevocationList または authorityRevocationList という
属性に格納されます。
ディレクトリサーバがローカルで動作しているとしても
CRL を入手することができるようにしないといけません。
プロトコルに何を使うかは local matter、好きにしろってこと?

DistributionPointName が URL で指定されてる場合、
次の意味であることが仮定されます:
  • URL は reason に関連した CRL を指す
  • その CRL の発行者は cRLIssuer
URI のスキームが HTTP/FTP の場合、RFC 2585 に従って
URI の先は 1 つの DER でエンコードされた CRL でなくてはいけない (MUST)。
HTTP サーバは Content-type に application/pkix-crl を返すべき (SHOULD)。
RFC 4516 の LDAP URI スキームを使う場合
  • URI は CRL を含む dn のフィールドを含まなくてはいけない (MUST)
  • 1 つの CRL を含む属性の適当な attrdesc を含まなくてはいけない (MUST) (RFC 4523)
  • ホスト部分を含むべき (SHOULD)
ホスト部分を省略しちゃうと
アプリケーションがどこ接続するか分かったもんじゃないですからね。
DistributionPointName を若し記載するなら、
LDAP か HTTP な URI を含むべき (SHOULD)。

DistributionPointName が 1 つの nameRelativeToCRLIssuer を含む場合、
その値は DN fragment を意味する。
fragment は配布点を記載する為に
X.500 番台の CRL 発行者の DN に追加されたものです。
DistributionPoint に cRLIssuer が記載されている場合、
fragment が DN に追加されます。
そうでなかったら、fragment は証明証の発行者の DN に追加されます。
RFC 5280 に従う認証局は、CRL 配布点を指定するのに
nameRelativeToCRLIssuer を使うべきではありません (SHOULD NOT)。
cRLIssuer が複数の DN を含む場合には、
DistributionPointName の nameRelativeToCRLIssuer を使ってはいけません (MUST NOT)。

DistributionPoint の reasons を省略する場合、
指されてる CRL は全ての理由に関する CRL を含んでなくてはいけません (MUST)。
RFC 5280 は reason によって CRL を分けることを推奨しません (RECOMMENDS)。
cRLDistributionPoints を証明証に記載する場合、
最低 1 つは全ての理由に関する CRL を記載しなくてはいけない (MUST)。

cRLIssuer は CRL に署名して発行したのが誰かを同定するのに使います。
cRLIssuer を記載するなら、中身は CRL の発行者の DN と合わせないといけません (MUST)。
DN エンコーディングも合わせなくてはいけません (MUST)。
cRLIssuer が記載されていて、その DN が CRL の配置されてる場所と対応しない場合、
認証局は distributionPoint も記載しなくてはいけません。
ラベル:RFC5280 CRL
posted by OJH at 15:12| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

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日

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

2009年01月27日

RFC 5280 の 4.2.1.3. Key Usage

Key Usage は「キー使用法」
証明書に署名した認証局が
その証明書の公開鍵の使用方法として認めてる用途のリストになります
用途を制限したいときにはこの拡張を使います (無制限なら書かない?)
ASN.1 モジュールはこんなかんじ
id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

KeyUsage ::= BIT STRING {
     digitalSignature        (0),
     nonRepudiation          (1), -- recent editions of X.509 have
                          -- renamed this bit to contentCommitment
     keyEncipherment         (2),
     dataEncipherment        (3),
     keyAgreement            (4),
     keyCertSign             (5),
     cRLSign                 (6),
     encipherOnly            (7),
     decipherOnly            (8) }
で、想定されてる用途がリストされています
例えば ssl.seesaa.jp の証明書だと keyUsage 部分の dump は
30 0e
   06 03
      55 1d 0f
   01 01
      ff
   04 04
      03 02
         05 a0
これを読み下すと
SEQUENCE で長さは 13 bytes
   OID で長さは 3 bytes
      2.5.29.15 = Key Usage
   BOOLEAN で長さ 1
      True (Critical)
   OCTET STRING で長さは 4 bytes
      BIT STRING で長さは 2 bytes
         未使用 bit 数は 5 bit の 10100000 = 101 (0 と 2)
なので Key Usage はクリティカルで用途は digitalSignature と keyEncipherment
ってことが分かります

RFC 5280 に従うならば
「他の証明書や CRL の署名を検証する為に使う公開鍵を含む証明書」
(ってことは認証局の証明書?)
にはこの拡張を含めなくてはいけません (MUST)
で、含めるんだったらクリティカルにすべきです (SHOULD)

では、上に挙げた用途の詳細を簡単に列記
  • digitalSignature は証明書と CRL 以外の署名を確認する為、認証・整合性用
  • nonRepudiation は証明書と CRL 以外の署名を確認する為、否認防止用
  • keyEncipherment は秘密にしたい鍵の暗号化用
  • dataEncipherment は共通鍵無しに (ハイブリッドでなしに?) 直接暗号化する用
  • keyAgreement は、Diffie-Hellman 鍵交換とか鍵を共有する用
  • keyCertSign は証明書の署名検証用、これは basic constraints の cA がセット (MUST)
  • cRLSign は CRL の署名検証用
  • encipherOnly は keyAgreement を更に暗号するだけに制限する
  • decipherOnly は keyAgreement を更に複号するだけに制限する

注をいくつか

keyUsage が設定されてるのに keyCertSign や cRLSign のビットは立ってないときは
その証明書に入ってる公開鍵を使って証明書や CRL の署名を検証してはいけません
(MUST NOT)

証明書の公開鍵を証明書や CRL の署名の検証だけに使わせたいなら
digitalSignature と nonRepudiation は立てるべきではありません (SHOULD NOT)
もちろん、他の署名の検証に使っても良いなら色々立ってても OK (MAY)

RFC 5280 は用途の組合せを特に制限しませんが
公開鍵によって適切な値ってのはあるので守りましょう
例えば DSA は署名アルゴリズムだから暗号化できませんし
詳しくは RFC の 3279, 4055, 4491 を見ましょう

keyUsage を設定しといて用途の bit を全て 0 にすると無駄なので
最低 1 つは 1 でなくちゃいけません (MUST)

で、
nonRepudiation と他の用途との組合せに関して何か書いてあるんだけど
Combining the nonRepudiation bit in the keyUsage certificate
extension with other keyUsage bits may have security implications
depending on the context in which the certificate is to be used.
Further distinctions between the digitalSignature and nonRepudiation
bits may be provided in specific certificate policies.
意味が分かりません
そもそも nonRepudiation と digitalSignature を分ける理由が分からない
でも分けてるからには何か意味があるんでしょう、policy の話なの?
読み進めていったら分かるかなぁ
ラベル:拡張 公開鍵 RFC5280
posted by OJH at 02:49| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月22日

RFC 5280 の 4.2.1.2. Subject Key Identifier

「サブジェクト鍵識別子」ですね、直訳
証明書に含まれる公開鍵の持ち主を一意に指し示す為の項目です

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier

これも証明書の信頼の階層構築の為に使います
階層の確認のときに誰が署名したか直ぐ分かると楽ですから
認証局は発行した証明書に Authority Key Identifier を書いて
認証局の証明書には Subject Key Identifier を書いとかないといけません (MUST)

じゃぁ認証局の証明書て何だよ、ということになるわけですが
basic constraists っていう拡張で cA が True になってる証明書が
認証局の証明書だということになるそうです、がまぁそれは後ほど

で、この認証局の証明書の Subject Key Identifier と
その認証局が発行した証明書の Authority Key Identifier が
一致しなくてはいけません (MUST)
一致してたら誰の署名した証明書かとか探すのも簡単ですね

でも、基本は Distinguished Name に書かれてる情報ですし
証明書のパスを検証するソフトはここを見なくてもかまいません

エンドエンティティーの証明書の場合でも
例えば複数の証明書を複数の認証局から取得してる場合に
アプリケーションでどの証明書を用いるか直ぐ分かるように、など
証明書がどの公開鍵を含んでるかってことを指し示すのに使います

認証局の証明書の場合は Subject Key Identifier は書かないといけませんでしたが
エンドエンティティーの場合は「すべき」に抑えられています (SHOULD)

Subject Key Identifier は、公開鍵からかもしくは他の方法を用いて作った
一意に定まるような値を入れとくべきです (SHOULD)
で、一般的なのは
  1. subjectPublicKey を SHA-1 にかける (ただしタグとか長さの部分を除いたものを)
  2. 4 bit 0010 の後に、上の値の下位 60 bits を続けたもの
まぁ、これらは飽くまで一例で、他の方法でも OK です

あらかじめ identifier が作ってなければ、上の方法がお薦めですし (RECOMMENDS)
あらかじめ identifier が作ってあればそれを使うべきです (SHOULD)

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

2009年01月16日

RFC 5280 の 4.2.1.1. Authority Key Identifier

Authority Key Identifier はマイクロソフト社では「機関キー識別子」となってます
発行者が署名に使っている公開鍵を識別する為の識別子です
1 つの発行者が同時に複数の鍵を利用していたり鍵を変更した場合があるので
機関キー識別子によって証明書の階層の確認を簡単にすることができます
具体的に何が入っているかというと
  • 発行者の証明書の subject key identifier と同じもの
  • 発行者の名前とその証明書のシリアル番号
のどちらかが基本となる情報です

ASN.1 モジュールはこちら
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {
   keyIdentifier             [0] KeyIdentifier           OPTIONAL,
   authorityCertIssuer       [1] GeneralNames            OPTIONAL,
   authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
RFC 5280 に従う場合
認証局は発行する証明書には必ず keyIdentifier を指定しなくてはいけません (MUST)
但し証明書の階層の確認を簡単にする為なので
自己署名証明書の場合には指定しなくても構いません (MAY)
その変わり次節の Subject Key Identifier は記載する必要があります

keyIdentifier はその公開鍵から作られるか
または何かしらの方法で一意に定まった値であるべきです
具体的な作成方法に関しては次節で述べられます
事前の keyIdentifier がある場合にはそれを使うべきだし (SHOULD)
事前には無かった場合には RFC 5280 で書かれている方法か
若しくはそこからハッシュ関数を変更などを使うのがお薦めです (RECOMMENDS)

最後に 2 つ RFC 5280 に従う場合
  • 証明書を解釈するアプリなどは機関キー識別子をサポートすべきです (SHOULD)
  • 認証局はこの拡張をクリティカルにしてはいけません
posted by OJH at 04:21| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月13日

RFC 5280 の 4.2.1. Standard Extensions

この節以下で
X.509 バージョン 3 で定義されている標準的な拡張に関して
その OID も含めてその詳細が説明されていきます
具体的に目次を見てみると
  • 4.2.1.1. Authority Key Identifier (OID = 2.5.29.35)
  • 4.2.1.2. Subject Key Identifier (OID = 2.5.29.14)
  • 4.2.1.3. Key Usage (OID = 2.5.29.15)
  • 4.2.1.4. Certificate Policies (OID = 2.5.29.32)
  • 4.2.1.5. Policy Mappings (OID = 2.5.29.33)
  • 4.2.1.6. Subject Alternative Name (OID = 2.5.29.17)
  • 4.2.1.7. Issuer Alternative Name (OID = 2.5.29.18)
  • 4.2.1.8. Subject Directory Attributes (OID = 2.5.29.9)
  • 4.2.1.9. Basic Constraints (OID = 2.5.29.19)
  • 4.2.1.10. Name Constraints (OID = 2.5.29.30)
  • 4.2.1.11. Policy Constraints (OID = 2.5.29.36)
  • 4.2.1.12. Extended Key Usage (OID = 2.5.29.37)
  • 4.2.1.13. CRL Distribution Points (OID = 2.5.29.31)
  • 4.2.1.14. Inhibit anyPolicy (OID = 2.5.29.54)
  • 4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point) (OID = 2.5.29.46)
になります

ASN.1 モジュールで見るとこんな感じ
id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
ce は certificates の ce?
ラベル:RFC5280 拡張 OID
posted by OJH at 02:33| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月12日

RFC 5280 の 4.2. Certificate Extensions

RFC 5280 の 4.2. Certificate Extensions

X.509 バージョン 3 で定義された拡張部分は
  • 利用者の詳しい情報
  • 公開鍵の詳しい情報
  • 認証局の間の関係
を記載する為に用意されました
「署名前証明書」の最後の部分に羅列されます
X.509 バージョン 3 では独自の拡張を追加することも想定しています

拡張部分の ASN.1 モジュールは以下の通りです:
   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }
具体的にはこんな感じ
拡張

拡張には「OID・クリティカル・ASN.1 なビット列」の 3 つが記載されます
特定の拡張を 1 つの証明書に複数記載してはいけません (MUST NOT)
OID で拡張の種類が記載され、その内容がビット列で表現されます

クリティカルにはその拡張の重要度が True/False の BOOLEAN で記載されています
デフォルトは False です
  • 知らない・処理できないクリティカルな拡張があったらその証明書を拒否しないといけない (MUST)
  • 知らないクリティカルではない拡張があったら無視して良い (MAY)
  • 知っている拡張はクリティカルでなくても処理しなくてはいけない (MUST)

拡張を追加するのは構わないのですが、
クリティカルな拡張の扱いは気をつけて一般的な利用の妨げとならないようにしましょう。

以下の節では
インターネット PKI で使われる証明書に載せるお薦めの拡張と
どんな情報をどの拡張に載せるべきかということが述べられます。
クリティカルをどうすべきかも記載されます。

RFC 5280 で認証局がサポートすることが必須 (MUST) となっている拡張は
(認証局の証明書に記載されているべき拡張は?)
  • authority key identifiers (Sections 4.2.1.1)
  • subject key identifiers (Sections 4.2.1.2)
  • basic constraints (Section 4.2.1.9)
  • key usage (Section 4.2.1.3)
  • certificate policies (Section 4.2.1.4)
です
更に、サブジェクトが空の証明書には
  • subject alternative name extension (Section 4.2.1.6)
が記載されていなくてはいけません (MUST)

その他の拡張は OPTIONAL となります
RFC 5280 に従う認証局は RFC 5280 に載ってない拡張も処理できた方が良いです
証明書を発行者するとき RFC 5280 に載ってない拡張を載せることもできますが
クリティカルにしてしまうと相互運用を妨げてしまうので注意しましょう

証明書を利用するアプリケーション側で最低限知らないといけない拡張は (MUST)
key usage (Section 4.2.1.3)
  • certificate policies (Section 4.2.1.4)
  • subject alternative name (Section 4.2.1.6)
  • basic constraints (Section 4.2.1.9)
  • name constraints (Section 4.2.1.10)
  • policy constraints (Section 4.2.1.11)
  • extended key usage (Section 4.2.1.12)
  • inhibit anyPolicy (Section 4.2.1.14)
更に、以下の拡張を知っているべきです (SHOULD)
  • authority key identifiers (Sections 4.2.1.1)
  • subject key identifiers (Sections 4.2.1.2)
  • policy mappings (Section 4.2.1.5)
posted by OJH at 20:47| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月08日

RFC 5280 の 4.1.2.9. Extensions

tbsCertificate の最後が拡張部分です
最後といっても実際にインターネットに転がってる証明書を見ると
この拡張部分がずっと続いて今までの部分より長かったりしますが
Extensions は「拡張」と訳されていることが多いのかな?

拡張は X.509 のバージョン 2 までの問題点を解決する為に設定されたので
記載するには証明書のバージョンを 3 に設定しなくてはいけません (MUST)

ASN.1 モージュールを確認すると、
   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }
とあるように Extension の列であり
中身は
  • OID
  • クリティカルかどうか
  • 内容を表わすビット列

で、具体的にどんな Extension があるか?
というのが次節 4.2 以降で説明されます
ラベル:RFC5280 拡張
posted by OJH at 00:05| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月05日

RFC 5280 の 4.1.2.8. Unique Identifiers

サブジェクトと発行者を一意的に指し示す情報を記載する部分です
サブジェクトや発行者の名前を再利用する為のものだそうです
ただ、RFC 5280 では利用は推奨されてません (not RECOMMENDS)
また、インターネットで利用される証明書では使わないそうです
他の利用方法ではサブジェクトや発行者を省略してここを使うのかな?

RFC 5280 に従う認証局は Unique Identifiers を記述してはいけません (MUST NOT)
インターネットでは使わないというのだから当然ですね
RFC 5280 に従うソフトはこの項目の含まれた証明書を読み込んでも
エラーで止まったりせずに他の項目を正しく処理し切れるべきです
どんな証明書が来ても対応できる柔軟さは求められます
しかし、その中身まで理解したりできなくてもかまいません
無視しましょう、華麗にスルーです

若しインターネットでない用途などで記載するなら、
X.509 的には証明書の Version が 2 か 3 でなくてはいけません (MUST)
posted by OJH at 23:00| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年01月03日

RFC 5280 の 4.1.2.7. Subject Public Key Info

証明書は公開鍵証明書なわけで、遂に公開鍵がやってきました
subjectPublicKeyInfo には
   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }
が入っています

証明書の三大要素の 2 つ目が signatureAlgorithm でしたが
ここで AlgorithmIdentifier を見ました
アルゴリズムやエンコードの仕方を指す OID は
RFC 3279, RFC 4055, RFC 4491 なんかを見れば良いのでした

例えばアルゴリズムと OID は
rsaEncryption -> 1.2.840.113549.1.1.1
dsa -> 1.2.840.10040.4.1
dhpublicnumber -> 1.2.840.10046.2.1
なんてのがあります
posted by OJH at 03:50| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする
×

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