アカウント名:
パスワード:
何らかのセキュリティ上の理由であろうことは見当がつくけど具体的に知りたい
組織名は，登記などで第3者が法的に存在を確認できる ※1．しかし，organizationalUnitName は組織内の「自己申告」であり，第3者が存在を検証できないから止めるべきって考えみたいですね．https://github.com/cabforum/servercert/pull/225 [github.com] あたりを読んでいると．
もともとは巨大な組織で管理する部門を特定するために使用すると想定されていたみたいだけど，第3者の検証可能性を重視して，方針転換したみたいです．
※1 幽霊法人の問題はあるとは認めている
直接的にセキュリティリスクがあった訳じゃ無く、厳密な運用が非現実的で結果的にザル運用を助長するだけだったからきっぱり廃止した、的に理解しておけば良いのかな。
それ以外にもほぼ機能しないフィールドを許容していると、良からぬ用途に使われるリスクが増えてしまいそうだしなぁ……そのフィールドのパース処理にセキュリティホールが生じていたり、改竄した証明書のハッシュを衝突させるためのフィールドに流用されたり。
証明書のフォーマット周りは大きく変わる印象が薄かったのだが、案外そうでも無いのかな。# でも証明書が一年保たないのはやりすぎ感がある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
廃止の理由は? (スコア:0)
何らかのセキュリティ上の理由であろうことは見当がつくけど具体的に知りたい
Re: (スコア:5, 参考になる)
組織名は，登記などで第3者が法的に存在を確認できる ※1．
しかし，organizationalUnitName は組織内の「自己申告」であり，第3者が存在を検証できないから止めるべきって考えみたいですね．
https://github.com/cabforum/servercert/pull/225 [github.com] あたりを読んでいると．
もともとは巨大な組織で管理する部門を特定するために使用すると想定されていたみたいだけど，第3者の検証可能性を重視して，方針転換したみたいです．
※1 幽霊法人の問題はあるとは認めている
Re:廃止の理由は? (スコア:0)
直接的にセキュリティリスクがあった訳じゃ無く、
厳密な運用が非現実的で結果的にザル運用を助長するだけだったからきっぱり廃止した、
的に理解しておけば良いのかな。
それ以外にもほぼ機能しないフィールドを許容していると、
良からぬ用途に使われるリスクが増えてしまいそうだしなぁ……
そのフィールドのパース処理にセキュリティホールが生じていたり、
改竄した証明書のハッシュを衝突させるためのフィールドに流用されたり。
証明書のフォーマット周りは大きく変わる印象が薄かったのだが、
案外そうでも無いのかな。
# でも証明書が一年保たないのはやりすぎ感がある。