アカウント名:
パスワード:
CA/Browserフォーラムの資料は初見なのだけど、一般向けのcommonNameフィールドがDeprecatedなのに驚いた。CN無し証明書(もちろんsubjectAltName有り)はどこの発行サービスで作れるのだろうか。
CA/Browserフォーラム自体、GoogleとAppleの影響力が極めて強く、それらが切り捨てようと考えた規格と既に切り捨てられた規格は Deprecated となります。実装レベルでは、日進月歩のWeb業界では大昔と言える Chrome 58 以降でもうすでに、Google Chrome では commonName は一切見ておらず、subjectAlternativeName のみをFQDNの照合に使ってます。1つのドメイン名にしか対応していない証明書は不便だしワイルドカードは影響範囲が広すぎてサブドメ列挙より危険ですので、どうせ subjectAlternativeName を使うことになるのだから、複数個所参照するような面倒な仕様にはせずに SANs に統一した方が良いという考えなのでしょう。
> CN無し証明書(もちろんsubjectAltName有り)はどこの発行サービスで作れるのだろうか。現状では大手CAではないですね。
まぁ別に organizationalUnitName は認証局が認証もしてもいない項目なので、それを認証したかのように証明書に含めるのはおかしいから削除が妥当ですけど、CN は実際に認証しているドメイン名なんだから別に非推奨でも消さなくてもいいんじゃないですかね。ブラウザが見なくなって意味がないとみんなが思えば削除されるだけのこと。
おっしゃることは正しいです。その上で少し。
1つのドメイン名にしか対応していない証明書は不便だし
X.509的には、CNを複数持つサブジェクト名を定義することはできる気がしますね。X.509のサブジェクト名は、CN=srad.jpみたいな型と値の組合せ(AttributeTypeAndValue)の列(RelativeDistinguishedName)の列(RDNSequence)だと定義されています。直感的には、「の列」が一つ多い気がしますが。なので、同じ階層に複数のCNを持つことができそうな気がします。そもそも、複数の階層にCNを持つことが禁止されているわけでもなさそうです。
もっとも、実際にそんな証明書を見たことも無いですし、そんな証明書を発行するCAも無いとは思いますが。
とはいえ https://datatracker.ietf.org/doc/html/rfc6125#page-10 [ietf.org] では、commonNameは1つ限定っぽい感じがある。
CN-ID = a Relative Distinguished Name (RDN) in the certificate subject field that contains one and only one attribute-type-and-value pair of type Common Name (CN), 以下略
現行のHTTPS (RFC 2818 HTTP Over TLS)ではRFC 6125を参照していないけど、次期改定ではRFC 6125を参照する( https://datatracker.ietf.org/doc/html/draft [ietf.org]
その「contains one and only one」は、Baseline Requirement 1.7.9のCN非推奨とは矛盾してるわけで、なんでやねん、と。
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
もっと言えば2000年RFC 2818の時点で、ホスト名の検証にcommonNameを見るのはdeprecatedだった。
2000年時点ならCA/Browserフォーラム(2005年設立)は関係ないしGoogleはベンチャー時代だしAppleに至っては死にかけでMSに助け舟を出されてた頃じゃん。
> 1つのドメイン名にしか対応していない証明書は不便だしワイルドカードは影響範囲が広すぎてサブドメ列挙より危険ですので、どうせ subjectAlternativeName を使うことになるのだから、複数個所参照するような面倒な仕様にはせずに SANs に統一した方が良いという考えなのでしょう。
commonName には IP アドレスもドメインもそれ以外も書くことができてしまうので、型の概念がある subjectAlternativeName に移行したいという考えもあるのでは
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
一般向け証明書の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 に移行したいという考えもあるのでは