7 <- index -> 9


8.  セキュリティに関する考慮事項 English

この仕様の大部分は、証明書および CRL の、フォーマットおよび制約に捧げられている。証明書および CRL は、ディジタル的に署名されているので、追加的な インテグリティサービスは、不可欠ではない。証明書も CRL も、守秘の必要はなく、証明書および CRL に対する無制限かつ匿名なアクセスは、セキュリティの意味合いをもたない。

しかし、この仕様の範囲外のセキュリティ要素は、証明書ユーザに与えられる保証に影響を与える。この章では、実装者、運用管理者およびユーザによって考慮されるべき critical 論点を照らす。

そのサブジェクトのアイデンティティと、彼らの公開鍵との結合を検証するために CA および RA によって行われる手順は、その証明書におかれてしかるべき保証に大いに影響を与える。Relying party は、その CA の CPS(Certification Practice Statement)をレビューすることを望む可能性がある。これは、証明書 を他の CA 宛に発行するとき、特に重要である。

署名目的と他の目的の両方のために単一の鍵ペアを利用することは、強く阻止される。署名用および鍵管理用に別の鍵ペアを利用することは、そのユーザに、いくつかの便益を提供する。署名鍵の喪失もしくは開示に関する ramifications は、鍵管理の鍵の喪失もしくは開示とは異なる。別の鍵ペアの利用は、バランスがとれた、かつ、柔軟な対応を許容する。同様に、各鍵ペアについて、異なる有効期間もしくは鍵長は、アプリケーション環境によっては適切である可能性がある。残念ながら、旧来の(legacy)アプリケーション(例: SSL(Secure Sockets Layer))には、単一の鍵ペアを署名用と鍵管理用に使うものがある。

有用な(afforded)プライベート鍵の防護は、重要(critical)なセキュリティ要素である。小規模においては、ユーザが彼らのプライベート鍵を防護することの失敗は、攻撃者が彼らに仮装すること、あるいは、彼らの個人情報を複合することを可能にする。より大きな規模においては、CA の署名用プライベート鍵の侵害は、壊滅的な影響をもつ可能性がある。ある攻撃者が、そのプライベート鍵を気づかれずに入手する場合、その攻撃者は、偽の証明書や CRL を発行する可能性がある。偽の証明書や CRL の存在は、そのシステムにおける confidence を傷つける。このような侵害が検知された場合、その侵害された CA 宛に発行されたすべての証明書は、失効されなければならない(MUST)。(これによって、そのユーザと、他の CA のユーザ間のサービスを防ぐ。)このような侵害後の再構築は、問題があるので、CA には、このようなインシデントを避けるために、強い技術的手段(例: 耐タンパ暗号モジュール)と、適切な管理手順(例: 職務の分掌)の組み合わせを実装することが助言される。

CA のプライベート署名鍵の喪失は、解決し難い可能性がある。その CA は、CRL を製作したり、あるいは、通常の鍵 rollover を行ったりできない。CA は、署名する鍵について、セキュアなバックアップを維持管理する必要がある(SHOULD)。その鍵のバックアップ手順のセキュリティは、鍵の侵害を避ける際に critical factor である。

失効情報の入手可能性および鮮度(freshness)は、証明書にもたされるべき保証の程度に影響を与える。証明書は、普通に期限切れとなるが、イベントは、その通常の有効期間(lifetime)において発生する可能性がある。これは、そのサブジェクトと公開鍵の間の結合を否定することになる。失効情報が untimely もしくは入手不能である場合、その結合に関する保証は、明確に低減されます。Relying parties は、CRL に現れる可能性があるすべての critical 拡張を処理できない可能性がある。CA は、critical 拡張を含む CRL のみを通じて失効情報を 入手可能にするとき、特に、それらの拡張についてのサポートが、このプロファイルによって強制されていない場合、特別な注意をはらう必要がある(SHOULD)。例えば、失効情報が、delta CRL と full CRL の組み合わせを使って提供され、その delta CRL が full CRL より頻繁に発行される場合、delta CRL 処理に関連する critical 拡張sを扱うことができない relying parties は、最新の失効情報を入手できない。代わりに、full CRL が、ある delta CRL が発行されるときは常に発行される場合、適時な 失効情報は、すべての relying parties 宛に入手可能である。同様に、6 章に記述されている失効 checking を省略する証明書パス検証メカニズムの実装は、それをサポートするものより劣る保証しか提供しない。

証明書パス検証アルゴリズムは、ひとつ、もしくは複数の trusted CA についての公開鍵(および他の情報)についての一定の知識に依存する。ある CA を信頼する意思決定は、究極的には証明書を都合した(afforded)信頼を判断することになるので、重要な意思決定である。Trusted CA 公開鍵の認証された(authenticated)配布(通常、「自己署名」証明書の形態による)は、セキュリティ critical out-of-band 手続きであり、これは、この仕様の範囲外である。

さらに、鍵の侵害もしくは CA の failure が trusted CA について起きる場合、そのユーザは、そのパス検証ルーチン宛に提供された情報を加工する必要がある。あまりに多くの trusted CA の選択は、その trusted CA 情報を維持管理困難にする。他方、唯一の trusted CA の選択は、ユーザを閉ざされたコミュニティに制限する可能性がある。

証明書を処理する実装の品質も、提供される保証の程度に影響を与える。6 章中に記述されたパス検証アルゴリズムは、その trusted CA 情報のインテグリティ、そして、特に、trusted CA と関連する公開鍵のインテグリティに依存する。攻撃者がプライベート鍵をもっている substituting 公開鍵によって、攻撃者は、そのユーザを偽の証明書を受容するように騙す可能性があります。

鍵と証明書サブジェクト 間の結合は、その署名を生成するために使われる暗号モジュール実装およびアルゴリズムより強くはありえない。短い鍵長もしくは、弱いハッシュアルゴリズムは、証明書の用途を制限する。それゆえ、CA は、強い暗号技術的テクニックを採用できる暗号技術における進展に注目することが推奨される。さらに、CA は、弱い署名を生成する CA もしくはエンドエンティティ宛に証明書を発行することを断る必要がある(SHOULD)

名前比較ルールに準拠していない アプリケーションは、不正な X.509 証明書パスの受容、もしくは、有効なパスの棄却をもたらす可能性がある。X.500 シリーズの仕様は、DN の比較についてのルールを規定しており、これは、case、character set、multi-character 空白 substring あるいは leading and trailing 空白とは無関係に、文字列を比較することを要求している。この仕様は、最低限、binary 比較についてのサポートを要求しているこれらの要件を緩和する。

CA は、CA 証明書の サブジェクトフィールド中の DN を、その CA によって発行された証明書中の発行者 field 中の DN と同一の符号化をしなければならない(MUST)。CA が異なる符号化法を使う場合、実装は、この証明書を含むパスについて、名前 chains を認識するのに失敗する可能性がある。結果として、妥当なパスが、棄却される可能性がある。

さらに、DN についての名前制約は、サブジェクトフィールドもしくは subjectAltName 拡張において使われた符号化と同じ記述がなされなければならない(MUST)。そうでない場合、excludedSubtrees として記述された名前制約は、一致せず、不正なパスが受容され、permittedSubtrees として表明される名前制約は、一致せず、有効なパスは、棄却される。不正な paths の受容を避けるために、CA は、DN について、可能である限り、permittedSubtrees として名前制約を記述する必要がある(SHOULD)

一般に、ある名前形態(例: DNS 名)を制約するための nameConstraints 拡張の利用は、他の名前形態(例: 電子メールアドレス)の利用に対する防護を提供しない。

X.509 は、名前が明確であることを必須とするが、その 2 つの関連していない機関(authorities)は、同一の発行者名の元で証明書、かつ/または、CRL を発行するリスクがある。発行者名の collisions に関する問題およびセキュリティ論点を低減する手段として、CA および CRL の発行者名は、名前の collisions の確率を低減する方法で形成される必要がある(SHOULD)。実装者は、同一の名前をもつ複数の無関係の CA および CRL 発行者が存在する可能性を考慮する必要がある。少なくとも、CRL を検証する実装は、「ある証明書の証明書パスと、その証明書を検証するために使われた CRL 発行者の証明書パスは、同一の trust anchor で終端となること」を確認しなければならない(MUST)

電子メールアドレスの local-part は、case sensitive [RFC2821] であるが、emailAddress 属性値は、case sensitive ではない [RFC2985]。結果として、 「2 つの異なる電子メールアドレスは、emailAddress 属性について、その matching ルールが使われているとき、その電子メールサーバが mailbox local-parts の case sensitivity を攻略する場合、同一のアドレスとして転送される」というリスクがある。実装者は、その電子メールアドレスをホストするメールサーバが電子メールアドレスの local-part を case sensitive として扱う場合、電子メールアドレスをその emailAddress 属性中に含めてはいけない。

実装者は、壊れた証明書もしくは CRL の、CRL 配布点もしくは AIA(Authority Information Access)拡張が悪意あるコード宛のリンクを含む場合、巻き込まれるリスクを認識しておく必要がある。実装者は、常に、「そのデータは、正しく形成されたこと」を確保するため、取得されたデータを検証するステップを踏む必要がある。

証明書が https URI もしくは同様のスキームをもつ cRLDistributionPoints 拡張を含むとき、循環的依存性がもちこまれる可能性がある。その relying party は、最初のパス検証を完結させるために要求される CRL を取得するために、追加的なパス検証を行うことを強いられる!循環的な条件は、authorityInfoAccess もしくは subjectInfoAccess 拡張中の https URI (もしくは同様のスキーム)で作成される可能性もある。最悪の場合、この状況は、解決不能な依存関係を作り出す可能性がある。

CA は、拡張中に https, ldaps もしくは同様のスキームを規定する URI を含んではいけない(SHOULD NOT)。これらの拡張のひとつの中に https URI を含む CA は、「そのサーバの証明書は、その URI によって指されている情報を使わずに検証される可能性があること」を確認しなければならない(MUST)。そのサーバの証明書を検証することを選択する Relying parties は、cRLDistributionPoints 拡張、authorityInfoAccess 拡張もしくは subjectInfoAccess 拡張の中の https URI によって指された情報を取得するとき、「これは、unbounded 制約をもたらす」という可能性に備えなければならない(MUST)

自発行の証明書は、CA に、その CA の運用 における変更を示すための、ひとつの自動化されたメカニズムを提供する。特に、自発行の証明書は、ある非-compromised CA 鍵 ペアから、その次への寛容な change-over を実装するために使われる可能性がある。「CA 鍵更新」についての詳細な手順は、[RFC4210] に規定されている。ここでは、その CA は、その新しい公開鍵を、その以前のプライベート鍵を使って防護し、逆もまた 2 つの自発行の証明書を使って、同様である。準拠するクライアント実装は、その自発行の証明書を処理し、「新しい鍵 のもとで発行された証明書は、トラストされる可能性があるか否か?」を判定する。自発行の証明書は、その CA のポリシー set への追加のような、よりシンプルな手順を使って、CA 運用における他の変更をサポートするために使われる可能性あがる(MAY)

legacy 実装には、ISO 8859-1 character set (Latin1String) [ISO8859] で符号化しながら、それらを TeletexString としてタグづけした名前をサポートするものがある。TeletexString は、ISO 8859-1 より多くな character set を符号化するが、これは、ある種の文字(character)を異なるように符号化する。7.1 節に規定された名前比較ルールは、「TeletexStrings は、ASN.1 標準に記述されているようの符号化される」と想定する。Latin1String character set を使って符号化された名前を比較するとき、false positives や false negatives の可能性がある。

文字列が内部的表現から可視表現に対応づけられるとき、しばしば、2 つの異なる文字列は、同一の、もしくは、類似の視覚表現をもつ。これは、同様の 文字(glyph)の利用や、composed 文字 (例: e + ' equaling U+00E9、ハングルの composed 文字、および、特定の言語の子音結合の上の母音)の利用を含めて、多くの異なる理由によって起こる可能性がある。この状況の結果として、2 つの異なる名前の間で visual 比較を行う人々は、実際には、それらが同一でないとき、「それらは、同一である」と考える可能性がある。また、人々は、ある文字列を別のものと間違える可能性がある。証明書の発行者と relying party の両方は、この状況を認識しておく必要がある。


7 <- index -> 9