🙆

RFC 6488: リソース公開鍵基盤 (RPKI)の署名済みオブジェクトのテンプレート

2024/03/01に公開

Security

RFC

bgp

tech

要旨

本文書は、リソース公開鍵基盤(RPKI)で使用される署名済みオブジェクトの汎用プロファイルを定義する。これらのRPKI署名済みオブジェクトは、標準カプセル化形式として暗号メッセージ構文(CMS)を利用する。

本文書の位置付け

本文書はインターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 5741のセクション2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc6488 で入手できる。

著作権表示

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

リソース公開鍵基盤(RPKI)の目的は、認証局(CA)としての役割を果たす組織の記録に基づき、IP(v4およびv6)アドレス空間およびAS番号の現在のリソース保有者によるアサーションをサポートすることにある。IPアドレスおよびAS番号のリソース情報は、RFC 3779拡張[RFC6487]を介して、X.509証明書で運ばれる。リソースに関するその他の情報アサーションは、デジタル署名されたX.509以外のデータ構造で表現され、RPKIの文脈では「署名済みオブジェクト」と呼ばれる[RFC6480]。本文書は、RPKIを使用して検証可能な署名済みオブジェクトを指定するためのテンプレートを標準化するものである。

RPKI署名済みオブジェクトは、標準カプセル化形式として暗号メッセージ構文(CMS) [RFC5652]を使用する。CMSは、この形式のメッセージを処理するために使用できる既存のオープンソース・ソフトウェアを活用するために選ばれた。RPKI署名済みオブジェクトは、CMS署名済みデータ・オブジェクトのプロファイル(セクション2で規定) に準拠する。

本文書で定義するRPKI署名オブジェクトのテンプレートは、特定のタイプの署名済みオブジェクトに対する完全な仕様ではなく、すべてのRPKI署名済みオブジェクトに共通する項目のみを含む。つまり、特定のタイプの署名済みオブジェクトを完全に規定するには、特定のタイプの署名済みオブジェクトに固有の詳細を規定する追加の文書が必要になる。このような詳細には、オブジェクトのペイロードのための抽象構文表記1(ASN.1)[X.208-88]や、特定のタイプの署名済みオブジェクトを検証するために必要な追加の手順が含まれる。セクション4では、このテンプレートを使用する新しいタイプのRPKI署名済みオブジェクトを定義するために規定しなければならない追加の部分について詳しく説明する。なお、このテンプレートを使用して特定のタイプの署名済みオブジェクトであるRoute Origination Authorization (ROA)を規定する文書の例については、[RFC6482]を参照のこと。

1.1. 用語

読者は、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」(インターネットX.509公開鍵基盤証明書および証明書失効リスト(CRL)プロファイル)[RFC5280]、「X.509 Extensions for IP Addresses and AS Identifiers」(IPアドレスおよびAS識別子のX.509拡張) [RFC3779]、および「Cryptographic Message Syntax (CMS)」(暗号メッセージ構文) [RFC5652]に記載されている用語と概念に精通しているものとする。

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]の記述にしたがって解釈される。

1.2. アルゴリズムに関する注意事項

CMSは、さまざまな署名およびダイジェスト・アルゴリズムに対応できる汎用形式である。RPKIで使用するアルゴリズム(および関連する鍵サイズ)は [RFC6485]で規定されている。

2. 署名済みオブジェクトの構文

RPKI署名済みオブジェクトはCMS[RFC5652]署名済みデータ・オブジェクトのプロファイルである。ただし、RPKI署名済みオブジェクトはASN.1 Distinguished Encoding Rules (DER)[X.509-88]を使用して符号化しなければならない(MUST)という制限がある。

CMSオブジェクトの一般的な形式は次のとおりである。

ContentInfo ::= SEQUENCE {
  contentType ContentType,
  content [0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

コンテンツ・タイプは、id-dataの署名済みデータ型、つまりid-signedData OID [RFC5652]、1.2.840.113549.1.7.2 である。

2.1. 署名済みデータのコンテンツ・タイプ

CMS標準によれば、署名済みデータのコンテンツ・タイプはASN.1タイプの SignedDataである。

SignedData ::= SEQUENCE {
  version CMSVersion,
  digestAlgorithms DigestAlgorithmIdentifiers,
  encapContentInfo EncapsulatedContentInfo,
  certificates [0] IMPLICIT CertificateSet OPTIONAL,
  crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
  signerInfos SignerInfos }

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

さらに、SignerInfosセットには、1つのSignerInfoオブジェクトのみを含めなければならない(MUST)。

2.1.1. version(バージョン)

versionは構文のバージョン番号である。バージョン番号3のSignerInfo構造体に対応するため、3でなければならない(MUST)。

2.1.2. digestAlgorithms

DigestAlgorithmsセットには、カプセル化されたコンテンツの署名に使用されるダイジェスト・アルゴリズムのOIDが含まれている。このセットは正確に1つのダイジェスト・アルゴリズムのOIDが含まれていなければならず(MUST)、そのOIDは[RFC6485]で規定されているものから選択しなければならない(MUST)。

2.1.3. encapContentInfo

encapContentInfoは署名されたコンテンツであり、コンテンツ・タイプ識別子とコンテンツ自体で構成される。encapContentInfoは、RPKI署名済みオブジェクトのペイロードを表す。

EncapsulatedContentInfo ::= SEQUENCE {
  eContentType ContentType,
  eContent [0] EXPLICIT OCTET STRING OPTIONAL }

ContentType ::= OBJECT IDENTIFIER

2.1.3.1. eContentType

このフィールドは、このプロファイルでは未定義のままとする。eContentTypeは、この署名済みオブジェクトのペイロード・タイプを指定するOIDであり、オブジェクトを定義するインターネット標準化過程の文書によって規定しなければならない(MUST)。

2.1.3.2. eContent

このフィールドは、このプロファイルでは未定義のままとする。eContentは、署名済みオブジェクトのペイロードであり、RPKIオブジェクトを定義するインターネット標準化過程の文書によって規定しなければならない(MUST)。

署名済みオブジェクト・プロファイルは、署名済みオブジェクトのバージョン番号を提供しないことに留意すること。したがって、時間の経過に伴う署名済みオブジェクトの新しいバージョンへの移行を容易にするために、このプロファイルを使用して定義された各タイプの署名済みオブジェクトは、eContent内にバージョン番号を含めることが推奨される(RECOMMENDED)。

2.1.4. certificates(証明書)

証明書フィールドを含めなければならず(MUST)、この署名済みオブジェクトを検証するために必要なRPKIエンド・エンティティ(EE)証明書を1つのみ含めなければならない(MUST)。

2.1.5. crls

crlsフィールドは省略しなければならない(MUST)。

2.1.6. signerInfos(署名者情報)

SignerInfoはCMSで以下のように定義する。

SignerInfo ::= SEQUENCE {
  version CMSVersion,
  sid SignerIdentifier,
  digestAlgorithm DigestAlgorithmIdentifier,
  signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
  signatureAlgorithm SignatureAlgorithmIdentifier,
  signature SignatureValue,
  unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

2.1.6.1. version(バージョン)

バージョン番号は、SIDのSubjectKeyIdentifierの選択に対応する3でなければならない(MUST)。

2.1.6.2. sid

sidは以下のように定義する。

SignerIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier }

RPKI署名済みオブジェクトの場合、sidは、CMS証明書フィールドに格納されているEE証明書に記載されているSubjectKeyIdentifierでなければならない(MUST)。

2.1.6.3. digestAlgorithm

digestAlgorithmは、RPKIアルゴリズムと鍵サイズ・プロファイル仕様[RFC6485]に準拠するダイジェスト・アルゴリズムのOIDで構成されなければならない(MUST)。

2.1.6.4. signedAttrs

signedAttrsは次のように定義する。

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
  attrType OBJECT IDENTIFIER,
  attrValues SET OF AttributeValue }

AttributeValue ::= ANY

signedAttrs要素は存在しなければならず(MUST)、content-type属性とmessage-digest属性を含めなければならない[RFC5652]。署名者はまた、signing-time属性 [RFC5652]、binary-signing-time属性[RFC6019]、またはその両方の属性を含めてもよい(MAY)。他の署名済み属性を含めてはならない(MUST NOT)。

signedAttrs要素には、特定の属性のインスタンスを1つだけ含めなければならない(MUST)。さらに、構文ではSET OF AttributeValueを許容されるが、RPKI署名済みオブジェクトでは、attrValuesは1つのAttributeValueのみで構成しなければならない(MUST)。

2.1.6.4.1. Content-Type属性

content-type属性が存在しなければならない(MUST)。content-type属性のattrType OIDは1.2.840.113549.1.9.3である。

content-type属性のattrValuesは、EncapsulatedContentInfoのeContentTypeと一致しなければならない(MUST)。したがって、attrValuesには、CMS署名済みデータ構造で運ばれる特定のRPKI署名オブジェクトのペイロード・タイプを指定するOIDが含めなければならない(MUST)。

2.1.6.4.2. Message-Digest属性

message-digest属性は存在しなければならない(MUST)。message-digest属性の attrType OIDは1.2.840.113549.1.9.4である。

message-digest属性のattrValuesは、[RFC5652]のセクション5.4で規定されているように、署名されるコンテンツに適用されるダイジェスト・アルゴリズムの出力が含む。

2.1.6.4.3. Signing-Time属性

signing-time属性があってもよい(MAY)。signing-time属性の有無は、(セクション3で規定されているように)署名済みオブジェクトの有効性に影響を与えてはならない(MUST NOT)ことに留意すること。signing-time属性のattrType OIDは 1.2.840.113549.1.9.5である。

id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

signed-time属性のattrValuesは次のように定義する。

SigningTime ::= Time

Time ::= CHOICE {
  utcTime UTCTime,
  generalizedTime GeneralizedTime }

Time要素は、デジタル署名がコンテンツに適用された時刻をローカルのシステム・クロックに基づいて指定する。

Timeの定義は1997年バージョンのX.509で規定されたものと一致する。UTCTimeとGeneralizedTimeの使用に関する追加情報は[RFC5652]にある。

2.1.6.4.4. Binary-Signing-Time属性

binary-signing-time属性は存在してもよい(MAY)。binary-signing-time属性の有無は、(セクション 3で規定されているように)署名済みオブジェクトの有効性に影響を与えてはならない(MUST NOT)ことに留意する。binary-signing-time属性のattrType OIDは1.2.840.113549.1.9.16.2.46である。

id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) aa(2) 46 }

signed-time属性のattrValuesは以下のように定義する。

BinarySigningTime ::= BinaryTime

BinaryTime ::= INTEGER (0..MAX)

BinaryTime要素は、デジタル署名がコンテンツに適用された時刻を、ローカルのシステム・クロックに基づいて指定する。BinaryTime要素の正確な定義は[RFC6019]にある。

2.1.6.5. signatureAlgorithm

SignatureAlgorithmは、RPKIアルゴリズムと鍵サイズのプロファイル仕様 [RFC6485]に準拠しなければならない(MUST)。

2.1.6.6. signature

signature値は以下のように定義する。

SignatureValue ::= OCTET STRING

signatureの特性は、ダイジェスト・アルゴリズムと署名アルゴリズムによって定義する。

2.1.6.7. unsignedAttrs

unsignedAttrsは省略しなければならない(MUST)。

3. 署名済みオブジェクトの検証

リライング・パーティーは、署名済みオブジェクトを使用する前に、以下の条件がすべて満たされていることを確認することで、署名済みオブジェクトを検証しなければならない(MUST)。リライング・パーティーは、これらのチェックをどのような順序で行っても良い。これらのチェックは必要だが、十分ではないことに留意すること。一般に、署名済みオブジェクトの特定のタイプに基づいて、さらなる検証を行わなければならない(MUST)。

署名済みオブジェクトの構文はこの仕様に準拠している。特に、次の各々は真である。
1. CMSオブジェクトのcontent-typeはSignedData(OID 1.2.840.113549.1.7.2) である。
2. SignedDataオブジェクトのバージョンは3である。
3. SignedDataオブジェクトのcertificatesフィールドが存在し、EE証明書が1つ含まれている。この証明書のSubjectKeyIdentifierフィールドは、SignerInfoオブジェクトのsidフィールドと一致する。
4. SignedDataオブジェクトのcrlsフィールドは省略されている。
5. SignerInfoのバージョンは3である。
6. SignerInfoオブジェクトのsignedAttrsフィールドが存在し、content-type属性(OID 1.2.840.113549.1.9.3)とmessage-digest属性(OID 1.2.840.113549.1.9.4)の両方を含む。
7. SignerInfoオブジェクトのsignedAttrsフィールドには、content-type属性(OID 1.2.840.113549.1.9.3)、message-digest属性(OID 1.2.840.113549.1.9.4)、signing-time属性(OID 1.2.840.113549.1.9.5)とbinary-signing-time属性(OID 1.2.840.113549.1.9.16.2.46)である。signed-time属性とbinary-signing-time属性はあってもよい(MAY)が、必須ではないことに留意する。
8. EncapsulatedContentInfoのeContentTypeは、content-type属性のattrValues と一致するOIDである。
9. SignerInfoオブジェクトのunsignedAttrsフィールドは省略されている。
10. SignedData オブジェクトとSignerInfoオブジェクトのdigestAlgorithmは、RPKI アルゴリズムと鍵サイズのプロファイル仕様[RFC6485]に準拠している。
11. SignerInfoオブジェクトのsignatureAlgorithmは、RPKI アルゴリズムおよび鍵サイズのプロファイル仕様[RFC6485]に準拠している。
12. 署名されたオブジェクトはDERで符号化されている。
EE証明書(CMS署名済みデータ・オブジェクトに含まれる)の公開鍵は、署名済みオブジェクトの署名を正常に検証するために使用できる。
EE 証明書(CMS署名データ・オブジェクトに含まれる)は、[RFC6487]で規定されているRPKIにおいて有効なEE証明書である。特に、トラストアンカーからこのEE証明書への有効な証明書パスが存在する。

上記の手順が署名済みオブジェクトが無効であることが示された場合、署名済みオブジェクトは破棄され、署名済みオブジェクトが存在しないものとして扱われなければならない(MUST)。上記の条件がすべて真である場合、その署名済みオブジェクトは有効かもしれない。その場合、リライング・パーティーは、特定の種類の署名済みオブジェクトに必要な追加の検証手順を実行しなければならない(MUST)。

以前に有効だった署名済みオブジェクトは、関連するEE証明書が有効でなくなると(例えば、証明書の有効期間が終了したときや、証明書を発行した機関によって証明書が失効されたとき)、有効でなくなることに留意する。リソース証明書の有効性に関する完全な仕様については、[RFC6487]を参照のこと。

4. 特定の署名済みオブジェクトの定義

各RPKI署名済みオブジェクトは、このプロファイルに基づくインターネット標準化過程文書で、以下のデータ要素と検証手順を規定して定義しなければならない(MUST)。

eContentType: eContentTypeフィールドとcontent-type属性の両方に使われる1つのOID。このOIDは、署名済みオブジェクトのタイプを一意に識別する。
eContent: encapContentInfoのeContentフィールドの構文を定義する。これは、特定のタイプの署名済みオブジェクトに固有のデータを含むペイロードである。
追加の検証: 特定の署名済みオブジェクトに対する一連の追加検証手順を定義する。この特定の署名済みオブジェクトを使用する前に、リライング・パーティーは、上記のセクション3の一般的な検証手順と、これらの追加手順の両方を実行しなければならない(MUST)。

5. セキュリティに関する考慮事項

RPKI署名済みオブジェクトのデータには、機密性の前提はない。各署名済みオブジェクトの完全性(integrity)と真正性(authenticity)は、オブジェクトのデジタル署名の検証と、その検証に使用される EE証明書の検証に基づいている。署名済みオブジェクトは、一般にアクセス可能なリポジトリに格納されることが予想される。

RPKI署名済みオブジェクトは、カプセル化形式としてCMSを利用するため、CMSのセキュリティに関する考慮事項が適用される[RFC5652]。

6. IANA に関する考慮事項

IANAは、本文書で定義されているテンプレートを利用する「RPKI署名済みオブジェクト」タイプのレジストリを作成した。このレジストリには、署名済みオブジェクトの非公式な名前、署名済みオブジェクトのeContentTypeのOID、および署名済みオブジェクトが規定されているRFCを参照する仕様ポインタの3つのフィールドが含まれる。このレジストリ内のエントリは、IETF Standards Actionが管理する。

このレジストリには当初、以下の2つのエントリが登録されている。

名前	OID	仕様
ROA	1.2.840.113549.1.9.16.1.24	RFC 6482
マニフェスト	1.2.840.113549.1.9.16.1.26	RFC 6486

⚠️ RPKI著名済みオブジェクト (2023-12-15)

名前	OID	仕様
ROA	1.2.840.113549.1.9.16.1.24	[RFC-ietf-sidrops-rfc6482bis-09]
マニフェスト	1.2.840.113549.1.9.16.1.26	[RFC9286]
ゴーストバスターズ	1.2.840.113549.1.9.16.1.35	[RFC6493]
Autonomous System Provider Authorization (TEMPORARY - expires 2024-11-08)	1.2.840.113549.1.9.16.1.49	[draft-ietf-sidrops-aspa-profile-16]
トラストアンカー鍵 (TEMPORARY - expires 2024-08-04)	1.2.840.113549.1.9.16.1.50	draft-ietf-sidrops-signed-tal-11, Section 3.1]
署名済みチェックリスト	1.2.840.113549.1.9.16.1.48	[RFC9323]

7. 謝辞

著者らは、チャールズ・ガーディナー、ラス・ハウズリー、デレク・コングの協力と貢献に感謝する。さらに、著者らは、ロブ・アウスタイン、ロケ・ガリアーノ、ダニー・マクファーソン、ショーン・ターナー、サム・ワイラーの丁寧なレビューと有益なコメントに感謝する。

8. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.

[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February
2012.

[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.

[X.509-88] CCITT. Recommendation X.509: The Directory Authentication Framework, 1988.

9. 参考規格

[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, September 2010.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

著者のアドレス

マット・レピンスキー
BBN Technologies
10 Moulton Street
Cambridge MA 02138
メール: mlepinski@bbn.com

アンドリュー・チー
BBN Technologies
10 Moulton Street
Cambridge MA 02138
メール: achi@bbn.com

スティーブン・ケント
BBN Technologies
10 Moulton Street
Cambridge MA 02138
メール: kent@bbn.com

変更履歴

2024.3.1
2024.6.7: Errataを追加

GitHubで編集を提案