CA/Browser Forum、OU 属性の使用停止日を 2022 年 9 月 1 日とする決議を可決 15
ストーリー by headless
停止 部門より
停止 部門より
iida 曰く、
X.509 証明書の識別名の OU 属性 (organizationalUnitName: OID 2.5.4.11) の使用停止が CA/Browser Forum で決議された (Ballot SC47v2: Sunset subject:organizationalUnitName、 Baseline Requirement 1.7.9版: PDF、 EV SSL 1.7.7版: PDF)。
2022-09-01 以降に OU 属性のある識別名の証明書を発行してしまうと、証明機関が BR や EV に不適合になってしまい、対応するルート認証局がブラウザや OS などから信頼されなくなる危険性が高まる。ルート証明機関は下位の証明機関に BR や EV へ準拠するようはたらきかけるだろうから、現在 OU の有無や値を使って鍵や証明書を管理している TLS サーバー側の管理者や、それらで認証認可している (たいていは TLS クライアント側の) システムは、対応を迫られることになろう。
またもし 1 年モノの証明書を新規に発行してもらうばあいは、最初から OU なしで発行してもらうほうが更新が楽になろうから、ご検討いただきたい。
廃止の理由は? (スコア:0)
何らかのセキュリティ上の理由であろうことは見当がつくけど具体的に知りたい
Re:廃止の理由は? (スコア:5, 参考になる)
組織名は，登記などで第3者が法的に存在を確認できる ※1．
しかし，organizationalUnitName は組織内の「自己申告」であり，第3者が存在を検証できないから止めるべきって考えみたいですね．
https://github.com/cabforum/servercert/pull/225 [github.com] あたりを読んでいると．
もともとは巨大な組織で管理する部門を特定するために使用すると想定されていたみたいだけど，第3者の検証可能性を重視して，方針転換したみたいです．
※1 幽霊法人の問題はあるとは認めている
Re: (スコア:0)
直接的にセキュリティリスクがあった訳じゃ無く、
厳密な運用が非現実的で結果的にザル運用を助長するだけだったからきっぱり廃止した、
的に理解しておけば良いのかな。
それ以外にもほぼ機能しないフィールドを許容していると、
良からぬ用途に使われるリスクが増えてしまいそうだしなぁ……
そのフィールドのパース処理にセキュリティホールが生じていたり、
改竄した証明書のハッシュを衝突させるためのフィールドに流用されたり。
証明書のフォーマット周りは大きく変わる印象が薄かったのだが、
案外そうでも無いのかな。
# でも証明書が一年保たないのはやりすぎ感がある。
Re: (スコア:0)
現状、OUに値が入っていると認証局はそれが妥当かどうか(他社の名前や登録商標が入っていないかなど)審査する必要があり、もし間違えてOUの文字列にOKを出してしまい後から問題があるとの指摘が出た場合に、その証明書を失効させる必要があります。そのリスクを排除するためでしょう。
Re: (スコア:0)
OUに入れるかどうかは別として、他社の名前が入ってる営業部署、おつきあいあるところでもちょいちょい見かけますけどね。
大手製造系専属の○○事業部とか
Re: (スコア:0)
EV推しで金儲けの臭いがプンプンするぜ
一般向け証明書のcommonName (スコア:0)
CA/Browserフォーラムの資料は初見なのだけど、一般向けのcommonNameフィールドがDeprecatedなのに驚いた。
CN無し証明書(もちろんsubjectAltName有り)はどこの発行サービスで作れるのだろうか。
commonName は飾りです (スコア:2, 参考になる)
CA/Browserフォーラム自体、GoogleとAppleの影響力が極めて強く、それらが切り捨てようと考えた規格と既に切り捨てられた規格は Deprecated となります。
実装レベルでは、日進月歩のWeb業界では大昔と言える Chrome 58 以降でもうすでに、Google Chrome では commonName は一切見ておらず、subjectAlternativeName のみをFQDNの照合に使ってます。
1つのドメイン名にしか対応していない証明書は不便だしワイルドカードは影響範囲が広すぎてサブドメ列挙より危険ですので、どうせ subjectAlternativeName を使うことになるのだから、複数個所参照するような面倒な仕様にはせずに SANs に統一した方が良いという考えなのでしょう。
> CN無し証明書(もちろんsubjectAltName有り)はどこの発行サービスで作れるのだろうか。
現状では大手CAではないですね。
まぁ別に organizationalUnitName は認証局が認証もしてもいない項目なので、それを認証したかのように証明書に含めるのはおかしいから削除が妥当ですけど、
CN は実際に認証しているドメイン名なんだから別に非推奨でも消さなくてもいいんじゃないですかね。ブラウザが見なくなって意味がないとみんなが思えば削除されるだけのこと。
Re:commonName は飾りです (スコア:1)
おっしゃることは正しいです。その上で少し。
1つのドメイン名にしか対応していない証明書は不便だし
X.509的には、CNを複数持つサブジェクト名を定義することはできる気がしますね。
X.509のサブジェクト名は、CN=srad.jpみたいな型と値の組合せ(AttributeTypeAndValue)の列(RelativeDistinguishedName)の列(RDNSequence)だと定義されています。
直感的には、「の列」が一つ多い気がしますが。
なので、同じ階層に複数のCNを持つことができそうな気がします。
そもそも、複数の階層にCNを持つことが禁止されているわけでもなさそうです。
もっとも、実際にそんな証明書を見たことも無いですし、そんな証明書を発行するCAも無いとは思いますが。
Re: (スコア:0)
とはいえ https://datatracker.ietf.org/doc/html/rfc6125#page-10 [ietf.org] では、commonNameは1つ限定っぽい感じがある。
現行のHTTPS (RFC 2818 HTTP Over TLS)ではRFC 6125を参照していないけど、次期改定ではRFC 6125を参照する( https://datatracker.ietf.org/doc/html/draft [ietf.org]
Re:commonName は飾りです (スコア:1)
その「contains one and only one」は、Baseline Requirement 1.7.9のCN非推奨とは矛盾してるわけで、なんでやねん、と。
Re: (スコア:0)
RFC 6125もcommonNameの利用を積極的に認めているわけではない。22～23ページの6.2.1. Rules内、CN-IDの利用をMAYと記述しており、commonNameを見ない実装もOKなはずだ。
あと、draft-ietf-httpbis-semantics-18では、クライアント側に対して、CN-IDの利用をMUST NOTで禁止している。
commonName 1つまでの話に戻す。ちゃんと読んだら、RFC 6125の19ページ目にもっと明確に書いてあった。4.1 Rulesの6.でCN-IDは1つまで。ついでに、5.は特定条件でCN-IDを含めるべきではない(SHOULD NOT)場合についても書いてある。最初にこれらを取り上げるべきだった。すまない。
あと、Baseline
Re: (スコア:0)
もっと言えば2000年RFC 2818の時点で、ホスト名の検証にcommonNameを見るのはdeprecatedだった。
Re: (スコア:0)
2000年時点ならCA/Browserフォーラム(2005年設立)は関係ないしGoogleはベンチャー時代だしAppleに至っては死にかけでMSに助け舟を出されてた頃じゃん。
Re: (スコア:0)
> 1つのドメイン名にしか対応していない証明書は不便だしワイルドカードは影響範囲が広すぎてサブドメ列挙より危険ですので、どうせ subjectAlternativeName を使うことになるのだから、複数個所参照するような面倒な仕様にはせずに SANs に統一した方が良いという考えなのでしょう。
commonName には IP アドレスもドメインもそれ以外も書くことができてしまうので、
型の概念がある subjectAlternativeName に移行したいという考えもあるのでは