S/MIME 証明書のプロファイル

この記事では、S/MIME でメールの署名と暗号化を行う場合に使用する X.509 チェーンの各証明書が信頼を得るために必要な要件について説明します。

こうした要件を満たすことに加え、S/MIME でメールの署名と暗号化を行うことを Google によって明示的に認定された認証局(CA)証明書を、チェーンに組み込む必要があります。管理者が認定する CA のルート証明書の使用を許可することもできます。詳しくは、ルート証明書のガイドラインに関する記事をご覧ください。

:

  • Google は、Gmail for S/MIME による信頼を得ている CA 証明書の一覧を提供、管理しています。この一覧にある CA は Google 独自の裁量で信頼できると判断したものであり、Google はいつでも予告なくルート CA を削除する権利を保持しています。
  • 証明書に組み込まれた拡張情報が、同じ証明書内の他の拡張情報と矛盾していないことを確認してください。たとえば nsCertType が定義されている場合、そうした定義は鍵の用途の拡張情報、鍵の拡張的用途の拡張情報、および基本制約の拡張情報とまったく同じ使用目的を規定している必要があります。

証明書チェーンのルール

ルート CA

フィールド

発行者識別名

CA を識別できる値にする必要があります。

たとえば、「認証局」のような一般的な値を使用することはできません。

サブジェクト DN

エンコード形式は、発行者識別名とバイト単位で同じでなければなりません。

Subject Public Key Info

RSA モジュラス(2048、3072、または 4096)による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey

発行元の中間 CA 以外の中間 CA の証明書

ルートとエンド エンティティの間に直接的または間接的に複数の中間 CA が存在する場合、この情報を使用します。

発行元の中間 CA は、エンド エンティティ証明書を発行する中間 CA です。以下の情報は、チェーン内の発行元の中間 CA 以外の中間 CA に該当します。

フィールド
バージョン バージョン 3
シリアル番号 0 より大きい値にする必要があります。(INTEGER 型を使用した DER エンコードの場合は)20 バイト以下でなければなりません。
署名アルゴリズム SHA‐256SHA‐384SHA‐512 のいずれかを使った RSA。または、SHA‐256SHA‐384SHA‐512 のいずれかを使った ECDSA。
発行者識別名

発行元 CA の主体者識別名とバイト単位で同じでなければなりません。

有効期間 規定はありません。
サブジェクト DN 規定はありません。
Subject Public Key Info

RSA モジュラス(2048、3072、または 4096)による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey

拡張機能 要否 重大
鍵の用途 必須 はい

keyCertSign のビット位置を設定する必要があります。
他のビット位置を設定する可能性があります。

基本制約 必須 はい cA フィールドを TRUE に設定する必要があります。
pathLenConstraint フィールドを含めます。
CRL 配布ポイント 必須 いいえ

一般公開されている 1 つ以上の HTTP
uniformResourceIdentifier が存在する必要があります

(注) 失効サーバーは、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、次のセクションに沿って運用する必要があります。
  • 4.9.7. CRL 発行間隔
  • 4.9.9. オンライン失効、ステータス チェックの可用性
  • 4.9.10. オンライン失効チェックの要件
    4.10.2 サービスの可用性

その他の拡張機能 存在する可能性があります

エンド エンティティ証明書を発行する中間 CA 証明書

重要: 少なくとも 1 つの中間 CA 証明書がチェーン内に存在する必要がありますつまり、ルート CA がエンド エンティティ証明書を直接発行することは許可されていません

フィールド
バージョン バージョン 3
シリアル番号 ゼロ(0)より大きく、(INTEGER 型を使用した DER エンコードの場合は)20 バイト以下でなければなりません。
署名アルゴリズム

SHA‐256SHA‐384SHA‐512 のいずれかを使った RSA。または、SHA‐256SHA‐384SHA‐512 のいずれかを使った ECDSA。

発行者識別名

発行元 CA の主体者識別名とバイト単位で同じでなければなりません。

有効期間

notBefore と notAfter の間隔

10 年以内であることが望ましく、20 年以内でなければなりません。

サブジェクト DN

CA の使用を示します。

Subject Public Key Info

RSA モジュラス(2048、3072、または 4096)による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey

拡張機能 要否 重大
鍵の用途 必須 はい

次のビット位置を設定する必要があります。
keyCertSign
次のビット位置を設定する可能性があります。
cRLSign
digitalSignature
OCSP レスポンスの署名に直接使用する場合は、次の情報が存在している必要があります。
digitalSignature

他のビット位置を設定してはなりません。

鍵の拡張的用途 必須 どちらでもよい 次の情報が存在しなければなりません。
emailProtection
次の情報が存在してはなりません。
serverAuth
codeSigning
timeStamping
anyExtendedKeyUsage

基本制約

必須 はい

cA フィールドを TRUE に設定する必要があります。
pathLenConstraint フィールドを 0 にします。

証明書ポリシー 省略可 いいえ

CA の運用基盤であるポリシーを識別する policyIdentifier を指定します。anyPolicy は望ましくありません。
cps(存在する場合)には、有効な HTTP または HTTPS のリンクを含める必要があります。

CRL 配布ポイント 必須 いいえ

一般公開されている 1 つ以上の HTTP
uniformResourceIdentifier が存在する必要があります。

(注)

失効サーバーは、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、次のセクションに沿って運用する必要があります。

  • 4.9.7. CRL 発行間隔
  • 4.9.9. オンライン失効、ステータス チェックの可用性
  • 4.9.10. オンライン失効チェックの要件
  • 4.10.2. サービスの可用性
その他の拡張機能 省略可 いいえ

存在する可能性があります。

エンド エンティティ証明書

フィールド
バージョン バージョン 3
シリアル番号

ゼロ(0)より大きく、予測不可能な 64 ビット以上を指定する必要があります。

注: CA/Browser Forum の「証明書ポリシーに関する基本要件」エンド エンティティ シリアル番号エントロピー要件を反映するように更新されます。

署名アルゴリズム SHA‐256SHA‐384SHA‐512 のいずれかを使った RSA。または、SHA‐256SHA‐384SHA‐512 のいずれかを使った ECDSA。
発行者識別名

発行元 CA の主体者識別名とバイト単位で同じでなければなりません。

有効期間

notBefore と notAfter の間隔は 27 か月以内でなくてはなりません。

notBefore の時刻は署名時刻の前後 48 時間以内でなければなりません。

サブジェクト DN

メールアドレス以外の主体者関連識別名は、一般公開され監査済みの手順に沿って、発行前に厳格な検証を受ける必要があります。使用できる手順については、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、セクション 3.2.3「個人の認証」をご覧ください。

また、任意のメールアドレス(commonName フィールド内や emailAddress フィールド内など)が、主体者代替名拡張情報に rfc822Name 形式で存在する必要があります。

Subject Public Key Info

RSA モジュラス(2048、3072、または 4096)による rsaEncryption。あるいは、secp256r1 または secp384r1 を使った ecPublicKey

拡張機能 要否 重大
鍵の用途(RSA) 必須 はい

次のいずれかまたは両方のビット位置を設定する必要があります。
digitalSignature
および
nonRepudiation/contentCommitment
次のビット位置を設定する可能性があります。
dataEncipherment
keyEncipherment

他のビット位置を設定してはなりません。

鍵の用途(ECDH) 必須

次のビット位置を設定する必要があります。
digitalSignature
次のビット位置を設定する可能性があります。
nonRepudiation/contentCommitment
keyAgreement
encipherOnly(keyAgreement が設定されている場合)
decipherOnly(keyAgreement が設定されている場合)

他のビット位置を設定してはなりません。

鍵の拡張的用途 必須 どちらでもよい

次の情報が存在しなければなりません。
emailProtection
次の情報が存在してはなりません。
serverAuth
codeSigning
timeStamping
anyExtendedKeyUsage

基本制約

省略可 どちらでもよい

存在する場合、cA フィールドを TRUE に設定してはなりません。
pathLenConstraint フィールドが存在してはなりません。

証明書ポリシー 必須 いいえ

policyIdentifier が存在しなければなりません。これは、証明書発行の基盤であるポリシーを識別するものです。また、anyPolicy を指定してはなりません。

cps が存在する可能性があります。存在する場合には、証明書発行の基盤である CPS への有効な HTTP または HTTPS リンクを含める必要があります。

認証局情報アクセス

省略可 いいえ

caIssuersocsp(存在する場合)には、一般公開されている 1 つ以上の HTTP uniformResourceIdentifier を含める必要があります。

AccessDescription には、個人の証明書に固有のラベルやパラメータを含めてはなりません。

CRL 配布ポイント 必須 いいえ

一般公開されている 1 つ以上の
HTTPuniformResourceIdentifier が存在する必要があります

(注)

失効サーバーは、CA/Browser Forum の「パブリック証明書の発行および管理に関する基本要件」バージョン 1.3.2 以降の、次のセクションに沿って運用する必要があります。

  • 4.9.7. CRL 発行間隔
  • 4.9.9. オンライン失効、ステータス チェックの可用性
  • 4.9.10. オンライン失効チェックの要件
  • 4.10.2. サービスの可用性

サブジェクト代替名

必須 いいえ

rfc822Name 形式の項目を 1 つ以上含める必要があります。
次のタイプの項目を含んではなりません。
dNSName
iPAddress
uniformResourceIdentifier
各 rfc822Name は、リクエストを送信するエンティティがメールアドレスに関連付けられたメール アカウントを管理しているか、メール アカウントの所有者からアカウント所有者の代理として行動する権限を与えられていることを確認するために、公開されている監査済みの措置で検証する必要があります。

その他の拡張機能

省略可 いいえ 存在する可能性があります。