RFC 5280 の 3.3. Revocation
証明書の失効に関してです 証明書を失効する必要性と 失効した証明書を利用者に伝える方法について述べられます 今まで証明書失効リストと書いていましたが面倒なのと OCSP (Online Certificate Status Protocol) の和訳がアホくさいので CRL (Certificate Revocation List) と記述してしまうことにします 証明書には有効期限が設定されているわけですが 必ずしも有効期限まで証明した内容が保持されるとは限りません 例えば社名が変更になると証明書に記載の組織名が変わってしまいます また、秘密鍵が漏洩した危険性があると判断された場合にも 悪意のある人が漏洩した秘密鍵を用いて「なりすまし」する可能性があるので 認証局は証明書を無効として利用者に知らせるべきです このような場合には X.509 では認証局が CRL を定期的に発行して 証明書が
RFC5280 の 4.1.2.4. Issuer
署名アルゴリズムの次に記載されるのが認証局の名前です Issuer は「発行者」と訳しましょう つまり、その証明書に署名して発行しているのは誰か? ということが書かれます ここは空ではいけません (MUST) 名前の記述方法は X.501 に書いてあります X.500 番台ってのはディレクトリシステムっていう住所録の仕様を決めてました もちろん何処の誰かを指し示す方法も決めてなくてはいけないわけですが その指定の仕方を distinguished name (DN) と言います 区別できる名前ということですかね 具体的には国・住所・組織名・名前などを階層として並べて書きます うだうだ書くより見た方が分かり易いですね 下から type -> value という形で階層下って見ていくと、 countryName (国名) -> USorganizationName (組織) -> VeriSi
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
RFC 5280 の 3.1. X.509 Version 3 Certificate
X.509 のバージョン 3 で定義されている電子証明書に関して概説されています 内容は 電子証明書に関して概説X.509 のバージョン 3 までの歴史1. 電子証明書に関して概説 公開鍵暗号方式というのがありまして 「公開鍵」ってデータで暗号化、対になる「秘密鍵」ってデータで復号化します 公開鍵を世間に公開しちゃって皆から暗号化したデータを送ってもらえるじゃん 暗号化だけでなく電子署名も使える = PKI って素敵!! っていう話でした 暗号化したデータを誰かに送るのに、送る相手が公開した公開鍵を使うわけですが 果たしてその公開鍵は本当に私が送りたい相手の公開鍵か? というのは大問題です もし偽の公開鍵を掴まされてしまったら盗聴の末に秘密のデータが漏れちゃうし 全然知らない人が署名した文章を知ってる人の署名した文章だと信じちゃうかも そこで、その公開鍵と対になる秘密鍵を持っているのが何処
NPO日本ネットワークセキュリティ協会|PKI Day 2009－＜様々な分野に展開されるPKIの最新動向＞
東京ウイメンズプラザホール（246席） JR山手線・東急東横線・京王井の頭線：渋谷駅下車徒歩12分 地下鉄銀座線・半蔵門線・千代田線：表参道駅下車徒歩7分 都バス(渋88系統)：渋谷駅からバス4分青山学院前バス停下車徒歩2分
repository
新型コロナウイルス感染症対策として、政府から企業に対しテレワークの積極導入が要請され、リモート作業が一般化する中で、社内手続きや取引書類の電子化、さらにはテレワークで活用するツールの安全性等の課題が改めて浮き彫りとなりました。 電子化は、単に時間・場所の制限をなくすだけでなく、各種データそのものの活用により効率的・効果的な働き方を可能とします。その一方で、電子データとなった情報は、その真正性・正当性を担保することがこれまで以上に重要となります。 JIPDECは、企業における契約手続きに加えて、建築設計図書、不動産鑑定評価書、取締役会議事録等の電子化を支援しています。 JIPDECは、電子契約をはじめとした電子文書等の普及を図るため、インターネット上における人・組織・データ等の改ざんや送信元のなりすまし等を防止する仕組み（トラストサービス）の実現に取り組んできました。すなわち、電子署名をはじ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.nic.ad.jp/ja/newsletter/No44/NL44_all.pdf
