2009年04月29日

杜撰な研究者の日記: MD5: 高速の解読法発見

ほんとに! って思ったんですが具体的に何が成されたのか良く分かりません
論文? は
これみたいですけど、イントロだけ読んでもなぁ
preimage が分かっちゃうの?
前提条件は??
ラベル:MD5 preimage
posted by OJH at 19:13| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2009年04月20日

「IT ホワイトボックス」でインターネットの暗号化に関して学んだ

この 4 月から IT ホワイトボックスって番組が NHK 教育でやってまして
初回は村井純さんが RFC って何かとか説明するっていうマニアな番組なんですが
3 回目のタイトルが「メールは盗み見られないのか?」でした
杜撰な研究者の日記: ITホワイトボックス第3回「メールは盗み見られないのか?」を見ました
で内容は見てたんですけど昼間に再放送がチェックできたんで見ました
夜には初回の再放送もやってたんで 3 回目もまた再放送あるのかも

例えば暗号の説明としてシーザー暗号から入るんですけど
つながり‐コンピュータとネットワークのしくみ‐ | 日本科学未来館』の映像とか出て
0 と 1 を白黒の玉で表現して実際に手を動かしてもらっていました
こういう説明がどのくらい効果的なんのかは良く分からないんですが
身体感覚から入るってのは良いんだろうなぁ、きっと
日本科学未来館は楽しそうだなと思いました
台場の RiSuPia には行ったことがあったんですが、こっちも見てみたいな、楽しそう
XOR とか出てきたらどうしようかとドキドキしてたんですが出てきませんでした

公開鍵暗号の話は「錠と鍵」で説明で
デジタルだから錠がいくらでもコピーできるんだ、ってことは言ってなかった
「公開鍵はいま世界で最も良く使われてる暗号」みたいなこと言ってた気がしたんだけど
「RSA は公開鍵で最も良く使われているアルゴリズム」ってこと言いたかったのかなぁ
公開鍵暗号っていうと RSA なんですかね、まぁ、言葉としては流通してると思うんですが
Diffie-Hellman ってそんな大切じゃないのかな? こっちの名前をどっちかっていうと出して欲しい

で、「暗号化なんて普段してないし、メールの内容も見られても困らないし」って発言に対し
「クレジットカードの番号とかネットバンキングとかしてませんか?」って返すわけですが
それもぉメールじゃなくって HTTP の話じゃん!! って思うんですが
まぁ、メールを軸に色々紹介するっていう番組みたいなんで仕方ないのかな...
何でウェブじゃなくてメール中心で話組んだんだろうなぁ

面白いなと思ってるんで機会があれば続きも見たいです
posted by OJH at 00:38| 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) | 注疏 | このブログの読者になる | 更新情報をチェックする
×

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