subjectPublicKeyInfo に載っている公開鍵の持ち主の情報が載ってます
「サブジェクト」って訳されていることが多いです
サブジェクトの名前はこの Subject か
拡張部分の subjectAltName に載せることになります
後で見ることになりますが、4.2.1.9. Basic Constraints は
公開鍵ペアの利用方法の許可範囲を記述する拡張部分で?
例えばその公開鍵ペアで証明書を発行して良いかどうかが書けます
で、その証明書が認証局の証明書として使う場合には
証明書の Subject に空ではない DN を設定して (MUST)
認証局の証明書のサブジェクトと発行した証明書の発行者を一致させます (MUST)
やっぱり後で見ますが 4.2.1.3 Key Usage で発行者は
公開鍵ペアの利用方法の範囲を指定します
例えばここで CRL に署名できるかどうかが指定できるのですが
Subject で示されるエンティティが CRL に署名する場合には
証明書の Subject に空ではない DN を設定して (MUST)
サブジェクトの DN と同じものを CRL の発行者部分に記載します (MUST)
メールアドレスや URI にのみ証明書の有効範囲を制限したい場合など
拡張部分の subjectAltName にのみ名前情報を載せることになります
その場合は Subject は空でなくてはいけません (MUST)
また、subjectAltName には critical というマークが付いてないといけません
クリティカル (critical) というのはフィールドに持たせる属性の 1 つで
クリティカルという印が付いているかいないかのどちらかになります
「○○であるためには××はクリティカルでなくてはいけない」
「○○であるためには××はクリティカルであってはいけない」
といった感じで証明書のコントロールに使われます
サブジェクトが空でないならば
発行者のときと同じように X.500 の名前のルールに従わなくてはいけません (MUST)
サブジェクトと発行者の DN のペアは
発行対象のエンティティーに対してユニークにしなくてはいけません (MUST)
ここで、ユニークの意味ですが、多分、1 つの発行者の DN に対して
異なるサブジェクトエンティティーには異なる DN を振れということだと思います
多分、多分ですが同じ会社が同じ FQDN で OU など変えても証明書は取得できるかと
また、同じ DN で同じエンティティーに証明書を発行するのは OK です (MAY)
名前に関するルールが書いてあるんですが
4.1.2.4 の発行者の部分と基本的には同じです
・名前の記述方法は X.501 に書いてある
・国名や組織など発行者の部分で理解できた属性は理解できないと (MUST)
・市区町村など発行者の部分で理解できるべきだった属性も同様 (SHOULD)
・書き方とか OID は Appendix A に書いてある
・Section 7.1 にある比較方法を使った方が良い (MAY)
使うべきエンコーディングは PrintableString か UTF8String ですが
発行者のときと同様に互換性などを保つ為の例外は許されています
認証局はよっぽどな理由がない限り PrintableString か UTF8String を使い
利用者側はどんなエンコーディングが来ても大丈夫なようにすべきです
例えば
昔はメールアドレスはサブジェクトの DN に記述されていました
RFC 2985 にも色々な属性が定義されていてメールアドレスも記述されていました
メールアドレスは @ を含みますがこれは PrintableString には含まれず
IA5String が使われています
また、メールアドレスは大文字・小文字を区別しません
RFC 5280 に従って新たに証明書を発行する場合には
メールアドレスは SubjectAltName (Section 4.2.1.6) 拡張に
rfc822Name として記述しなくてはいけません (MUST)
古い環境との互換性と保つ為に、SubjectAltName と同時に
Subject にもメールアドレスを記載することは
避けるべきですが一応許されています
