アカウント名:
パスワード:
CA/Browserフォーラムの資料は初見なのだけど、一般向けのcommonNameフィールドがDeprecatedなのに驚いた。CN無し証明書(もちろんsubjectAltName有り)はどこの発行サービスで作れるのだろうか。
CA/Browserフォーラム自体、GoogleとAppleの影響力が極めて強く、それらが切り捨てようと考えた規格と既に切り捨てられた規格は Deprecated となります。実装レベルでは、日進月歩のWeb業界では大昔と言える Chrome 58 以降でもうすでに、Google Chrome では commonName は一切見ておらず、subjectAlternativeName のみをFQDNの照合に使ってます。1つのドメイン名にしか対応していない証明書は不便だしワイルドカードは影響範囲が広すぎてサブドメ列挙より危険ですので、どうせ subjectAlternativeName を使うことになるのだから、複数個所参照するような面倒な仕様には
おっしゃることは正しいです。その上で少し。
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
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
一般向け証明書の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 を使うことになるのだから、複数個所参照するような面倒な仕様には
Re: (スコア: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