🫙

RFC 8630: リソース公開キー基盤 (RPKI) トラストアンカー・ロケーター

2024/03/11に公開

要旨

本文書は、リソース公開鍵基盤(RPKI)のトラストアンカー・ロケーター(TAL)を定義する。TALにより、RPKI内のリライング・パーティーは、現在のトラストアンカー(TA)認証局(CA)証明書を1カ所以上の場所からダウンロードし、この自己署名証明書の鍵がTAL上の鍵と一致することを検証できる。このようにして、リライング・パーティーはTA鍵で構成されるが、これらのTAはCA証明書の内容を変更することができる。特に、TAは証明書の拡張(RFC 3779)に含まれる一連のIPアドレス委任および/または自律システム識別子委任を変更できる。

本文書は、HTTP over TLS (HTTPS)(RFC 7230)をスキームとして使用するユニフォーム・リソース識別子(URI)(RFC 3986)のサポートを追加することで、RFC 7730で提供された以前のTALの定義を廃止する。

本文書の位置付け

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

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8630 で入手できる。

著作権表示

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

1. はじめに

本文書は、リソース公開鍵基盤(RPKI)[RFC6480]のためのトラストアンカー・ロケーター(TAL)を定義する。このフォーマットは、帯域外およびオンライン手段を組み合わせてトラストアンカー(TA)ファイル(material)を配布するために使用できる。リライング・パーティー(RP)がRPKI署名オブジェクトを検証するために使用する手順は、TAの使用の作成者とRP間の相互運用性を促進するために、このフォーマットをサポートする必要がある(SHOULD)。本文書は、スキームとしてHTTP over TLS(HTTPS) [RFC7230]を使用するユニフォーム・リソース識別子(URI) [RFC3986]を追加することで、[RFC7730]を廃止する。

1.1. 用語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

1.2. RFC 7730 からの変更点

本文書で定義されるTALフォーマットは、以下の点で[RFC7730]の定義とは異なる。

URIにHTTPSスキーム[RFC7230]の使用を許可する。
オプションのコメント・セクションを含めることを許可する。

現RPが、この新しいフォーマットにまだ対応していない可能性があることに留意すること。したがって、TAオペレータは、RPツールが更新されたと確信するまでの間、[RFC7730]で定義されているTALファイルを維持することが推奨される(RECOMMENDED)。

2. トラストアンカー・ロケーター

2.1. トラストアンカー・ロケーターの動機

本文書は、TAファイルの新しいフォーマットを提案するものではない。RPKIのTAは、自己署名されたX.509認証局(CA)証明書で表される。これは、PKIで一般的に使用され、RPソフトウェアで広くサポートされているフォーマットである。本文書は、非常に簡単な方法でTAの取得および真正性を検証するために使用されるデータのフォーマットを規定する。このデータはTALと呼ばれる。

⚠️ インターネットのトラストアンカーについて

RPKIは、インターネット・リソース(IPv4、IPv6、ASN)の保有を証明するためのフレームワークである。X.509拡張版を使用し、リソース保有者情報を含む証明書の作成と検証を行う。RPKIは、IANAからRIRへ、RIRからLIRへ、LIRからエンドユーザへの割り当て階層に従う。

nir-structure

検証は、信頼のチェーンをたどり、トラストアンカー(TA)までのパスに沿って各証明書を検証することで機能する。TAはRPKIの最上位の証明書であり、自己署名され、すべてのインターネット・リソースを含むとされている。しかし、頂点機関が管理する単一のTAは存在せず、5つのRIRが独自のTAを管理している。したがって、各TAにはIANAから各RIRに割り当てられたリソースが含まれ、各RIRのRPKIシステムは互いに独立して運用されている。一般に、RIRはそれぞれのTAでリソースの重複がないように協力している。

x509-chain

ところが、RIR間のリソースの移転によって、状況が困難になる可能性がある。RIR間でリソースを移転する場合、例えばリソースXがARINからRIPE NCCに移転すると仮定する。ARINはTAからリソースXを削除する必要があり、RIPE NCCはTAにXを追加する必要がある。リソースの移転で発生する問題は、(1) 両側のTAを再生成する必要があるため、手続きに時間がかかる、(2) RIRがリソースを過剰に要求するリスクが常にあり、そうなればその下位ツリーが無効となる。

定義上、TAは固定されたエンティティで、通常は10～20年間有効で、鍵ロールオーバーがある場合にのみ変更される。RIRがリソースを移転するたびに、TA内のリソースを追加・削除して、TAを再生成するという複雑なプロセスを実行しなければならないことを意味する。さらに、リソースに変更が生じるたびに、証明書の再署名のためにTAの秘密鍵にアクセスする必要があり、これは悪い慣行である。

RPKIは、常に100%の精度でダウンタイムが0%のシステムを想定しているため、RIRはメイク・ビフォア・ブレークの原則を採用することが重要である。リソースがRIR XからRIR Yに移転され、RIR Xが移転されたリソースを含む証明書を発行していた場合、この証明書の下にあるツリー全体は、親に委任されたリソースがなくなるため無効になる。ルーティングは下のツリー内のオブジェクトの有効性に依存するため、これは実際の運用上の問題となる。そこで、すべてのリソースをカバーしたTA(例えば、0/0)を持つことで、リスクが軽減し、RIRがリソースを過剰に要求する脅威を軽減する。

この「すべてのリソース」TAの展開は、2017年に行われた。2017年7月11日に、5つのRIR(AfriNIC、APNIC、ARIN、LACNIC、RIPE NCC)を取りまとめる非営利団体NRO(Number Resource Organization)から以下の発表がアナウンスされた。

2017年9月30日までに、各RIRは、現在の保有リソースを反映したRPKIトラストアンカーから、すべての保有リソース(0/0)を反映したRPKIトラストアンカーに移行する。これについては、2017年1月21日付の「All Resources Applicability Statement」で詳述されている。

https://www.ietf.org/archive/id/draft-rir-rpki-allres-ta-app-statement-01.txt

「本文書は、地域インターネット・レジストリ・コミュニティがトラストアンカー (TA) として運用する、複数の過剰要求の「すべてのリソース」(0/0) RPKI認証局(CA)証明書の使用について、一過性のレジストリの不一致が発生した場合、ダウンストリームが大規模に無効化されるリスクを軽減するための適用可能性(applicability)を提供する。」

このリスクを軽減し、脅威を軽減するために、RIRは、現在の保有リソースのみを反映するトラストアンカーから、すべての保有リソースを反映するトラストアンカーに移行することに合意した。この改善により、RPKIの対象となるリソースをあるRIRから別のRIRに移転するための、より堅固な方法が提供される。この変更に先立ち、各RIRはRPKIユーザ・コミュニティと協力して移行の準備を進める。

NROは、インターネット・コミュニティのメンバーがRPKIを通じてリソースを認証することを推奨している。今日のインターネット・ルーティングはハイジャックに対して脆弱であり、証明書のプロビジョニング/使用はルーティングをより安全にするために必要な最初のステップの1つである。RPKIの広範な採用により、世界中でIPアドレス保有の検証とルーティングの意思決定が簡素化される。

RIPEのRPKIトラストアンカー構造は、「すべてのリソース」トラストアンカーを公開し、その下で独自の地域リソース(IPアドレスとASN)が認証されている。

ripe-trust-anchor

この構造において、RIPE NCCオフライン・トラストアンカーとRIPE NCCオンライン運用証明書は、それぞれ「すべてのリソース」を保持する。これらの証明書の「すべてのリソース」を使用することは、他のRIRによる運用と一致している。これにより、RIPE NCCは、より制約の多い「RIPE NCC管理リソース」証明書を動的に発行でき、RIPE NCCによって登録された実際のリソース・セットを反映できる。その結果、RIPE NCCのサービス領域に移転したリソースは、すぐに認証される。逆に、RIPE NCCサービス領域外に移転したリソースはすぐに削除できる。この証明書を使用して、RIPE NCCは、RIPE NCCによって登録されたすべてのリソースを反映した単一のリソース証明書を各メンバーに発行できる。

RIPE NCCのトラストアンカー・ロケータ(TAL)は、RIPE NCC RPKIリポジトリの場所と、RIPE NCCリポジトリ内のアーティファクトにRIPEが署名したことを暗号的に検証するために使用されるRIPE NCC公開鍵の両方を含むファイルである。TALは RPKIバリデータとともに使用され、RIPE NCC RPKIリポジトリ内の証明書とROAを検証する。この検証された情報は、ネットワーク内のルーティングの決定に使用できる。

以下、RIPEのTAの中身を確認すると、すべてのリソースが対象になっていることがわかる。

$ rpki-client -f ripe-ncc-ta.cer 
File:                     ripe-ncc-ta.cer
Hash identifier:          5HyFXoSAhF53+3pNj0pn1pGoQMBZjVj4aIq+siYZWWs=
TAL:                      ripe
Subject key identifier:   E8:55:2B:1F:D6:D1:A4:F7:E4:04:C6:D8:E5:68:0D:1E:BC:16:3F:C3
Certificate issuer:       /CN=ripe-ncc-ta
Certificate serial:       C9
Manifest:                 rsync://rpki.ripe.net/repository/ripe-ncc-ta.mft
caRepository:             rsync://rpki.ripe.net/repository/
Notify URL:               https://rrdp.ripe.net/notification.xml
Certificate not before:   Tue 28 Nov 2017 14:39:55 +0000
Certificate not after:    Sun 28 Nov 2117 14:39:55 +0000
Subordinate resources:    AS: 0 -- 4294967295
                          IP: 0.0.0.0/0
                          IP: ::/0
Validation:               OK
$ openssl x509 -noout -text -in ripe-ncc-ta.cer 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 201 (0xc9)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = ripe-ncc-ta
        Validity
            Not Before: Nov 28 14:39:55 2017 GMT
            Not After : Nov 28 14:39:55 2117 GMT
        Subject: CN = ripe-ncc-ta
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d1:44:58:48:6a:94:cf:69:b2:06:c3:b3:79:6d:
                    63:43:a3:6c:c4:db:e5:2c:cc:a1:5a:49:ef:9e:5f:
                    0d:88:10:ac:fd:3f:d2:d9:7b:8d:29:03:59:fb:00:
                    59:c4:88:0f:3d:5d:a9:14:11:5e:40:0b:e8:1f:f5:
                    8a:f3:71:f0:03:6e:95:da:c8:b0:9b:f3:18:da:72:
                    99:f8:e9:70:fb:09:69:ce:56:75:a7:72:29:8f:67:
                    8d:70:aa:e6:8a:df:01:c0:10:bc:c4:89:b3:b8:21:
                    9a:57:48:e4:44:1d:06:67:48:68:1f:a3:25:d3:7b:
                    a6:2e:9a:d1:b2:7e:af:d3:13:8f:d3:e9:7a:41:cd:
                    59:1c:c1:55:15:bd:fc:e4:84:3b:15:04:13:71:52:
                    31:ad:d7:8c:b2:8c:89:ab:d7:8c:90:4e:83:a1:c9:
                    47:84:5f:cd:95:29:65:5e:e6:c0:49:0f:4a:51:6a:
                    89:d3:e3:ad:dd:00:97:af:82:d7:10:23:1f:92:99:
                    15:47:64:d9:4f:eb:f9:bf:ae:7c:6c:75:6c:e9:9c:
                    51:0f:56:fa:52:4d:6e:40:a0:32:1d:46:e7:fe:d5:
                    ef:3f:c9:6b:8c:08:9b:1b:35:6c:5c:34:f6:2f:4c:
                    78:11:dc:7e:41:d8:b1:3e:03:a3:8b:78:01:33:22:
                    f6:57
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                E8:55:2B:1F:D6:D1:A4:F7:E4:04:C6:D8:E5:68:0D:1E:BC:16:3F:C3
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            Subject Information Access: 
                RPKI Manifest - URI:rsync://rpki.ripe.net/repository/ripe-ncc-ta.mft
                RPKI Notify - URI:https://rrdp.ripe.net/notification.xml
                CA Repository - URI:rsync://rpki.ripe.net/repository/
            X509v3 Certificate Policies: critical
                Policy: ipAddr-asNumber
            sbgp-ipAddrBlock: critical
                IPv4:
                  0.0.0.0/0
                IPv6:
                  ::/0

            sbgp-autonomousSysNum: critical
                Autonomous System Numbers:
                  0-4294967295

    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        15:80:98:eb:67:7c:05:a6:90:bc:62:4f:03:db:18:33:c1:27:
        96:55:3d:af:b5:8a:bd:e8:24:10:b2:36:8a:6f:c9:db:79:5c:
        f7:0f:07:12:dd:ae:d1:22:c7:af:ac:d5:46:a3:8d:e4:dc:01:
        b2:9a:0d:64:8b:e0:16:26:3b:c7:bc:9f:ad:4b:30:9b:9f:9f:
        97:e9:9e:c0:7d:84:df:da:0d:fb:c4:83:55:0c:7a:ee:d0:f4:
        d0:51:aa:e0:48:c0:40:cf:f3:01:36:91:46:f0:a4:e1:b5:3e:
        d6:6c:9a:ca:e3:e7:ff:96:fc:74:9b:c4:0e:95:89:b6:6b:5e:
        e2:5d:2d:c0:19:02:7a:44:77:2a:f4:00:ec:72:a1:9d:ba:6c:
        66:30:c0:e3:c0:40:f6:e9:b1:9a:61:d9:ab:bb:58:4d:22:9c:
        05:ff:f8:d5:33:f7:91:8c:11:68:3c:72:85:97:1d:24:2d:df:
        f2:a0:24:0d:9b:1d:64:5b:ec:40:37:1e:2e:c9:6c:62:fc:36:
        20:49:5e:ce:ca:7a:be:0b:ad:0e:b9:c5:be:77:cb:48:86:46:
        e5:87:cf:98:7e:b9:ae:90:97:6c:57:eb:e8:d8:be:f6:c9:ea:
        dd:6e:c3:fd:c6:3a:af:85:9a:cb:29:fb:0b:66:36:0a:e1:27:
        58:62:d8:62

TALを定義する動機は、TA自体を再配布することなく、TA内にある選ばれたデータを変更できるようにすることである。

RPKIでは、証明書には、1つ以上の拡張[RFC3779]が含まれ、一連のIPアドレス委任や自律システム識別子委任を含めることができる。本文書では、これらの委任を、RPKI証明書に含まれるインターネット番号リソース(INR)と呼ぶ。

TAとして機能するエンティティに関連付けられたINRセットは、時間の経過とともに変更になる可能性がある。したがって、TAを安全な方法でRPに配布する一般的なPKI規約を使用する場合、TAとして機能するエンティティのINRセットが変更されるたびに、この手順を繰り返す必要がある。TAを配布する代わりにTALを(安全な方法で)配布することで、この問題は回避できる。つまり、TAの公開鍵とその場所が変わらない限り、TALは一定である。

TALは、標準化過程にある[RFC5914]で規定されているTrustAnchorInfoデータ構造に類似している。このデータ構造のrsyncまたはHTTPS URI拡張を定義した場合、その仕様を使用してTALを表すことができる。ただし、TALフォーマットはPKIX TA作業よりも前にRPKI実装者によって採用され、RPKI実装者コミュニティは必要な拡張を定義するよりも、TALフォーマットを利用することを選択した。また、コミュニティは、TrustAnchorInfoのバイナリ(ASN.1)符号化ではなく、TALのASCII符号化の単純さを好んでいる。

2.2. トラストアンカー・ロケータ・ファイルのフォーマット

本文書では、現在のTA証明書を取得するために使用できるURIとしてTA URIを定義する。この URIは、rsync URI[RFC5781]またはHTTPS URI[RFC7230]のいずれかでなければならない(MUST)。

TALは、以下の順序で並んでいる:

オプションのコメント・セクションは、「#」文字で始まる1行または複数行で構成され、[RFC5198]のセクション2で定義されている制限に準拠した人間が判読できる情報、UTF-8テキストが続き、改行で終わる、
URI セクションは、1つ以上の順序付けされた行で構成され、それぞれがTA URIを含み、改行で終わる、
改行、そして
DER形式[X.509]のsubjectPublicKeyInfo[RFC5280]をbase64で符号化したもの([RFC4648]のセクション4参照)。長い行を避けるために、base64符号化された文字列に改行を挿入してもよい(MAY)。

このファイル内の改行には「CRLF>」または「<LF>」のどちらかを使うことに留意する。

2.3. TALおよびTA証明書に関する考慮事項

TAL内の各TA URIは、1つのオブジェクトを参照しなければならない(MUST)。それは、ディレクトリや他のいかなる形式のオブジェクトのコレクションを参照してはならない(MUST NOT)。参照されるオブジェクトは、RPKI証明書プロファイル [RFC6487]に準拠する自己署名CA証明書でなければならない(MUST)。この証明書は、証明書パス発見[RFC4158]および検証[RFC5280] [RFC3779]におけるTAである。

このTAの有効期間は、(1) 「notBefore」時間がこの証明書が発行される時点より前であり、(2) 「notAfter」時間がこの証明書の再発行予定時刻より後になるように選択される。

このTAのINR拡張は、空でない番号リソース・セットが含まれなければならない(MUST)。INR拡張の「inherit」形式を使用してはならない(MUST NOT)。この証明書に記載されているINRセットは、RPKI[RFC6480]において発行エンティティが自らの仮のTAとして提示する番号リソース・セットである。

TAの検証に使用される公開鍵は、CA証明書およびTAL内のsubjectPublicKeyInfoと同一でなければならない(MUST)。

TAには、INR拡張の変更に起因する証明書の再発行時、および証明書が期限切れになる前に更新された場合にも、変更されない安定した鍵が含まれていなければならない(MUST)。

TALおよびTAの公開鍵は安定したものでなければならない(MUST)ため、オフライン・モードでCAを運用する動機付けとなる。この場合、同じINRを含む下位CA証明書、または理論上はINRの任意のサブセットを、オンライン運用のために発行することができる。これにより、TAを発行するエンティティは、この証明書の対応する秘密鍵をオフラインに維持する一方で、直属の下位CAの下で関連するすべての子証明書を発行することができる。また、この措置により、当該エンティティが発行する証明書失効リスト(CRL)を使用することで、オンライン運用の鍵ペアの危殆化が疑われる場合、下位CAの証明書を失効させることもできる。

TAは安定したURIで公開されなければならない(MUST)。何らかの理由でTAが再発行された場合、代替のCA証明書は同じURIを使用してアクセスできなければならない(MUST)。

TAは自己署名証明書であるため、TAを失効させるために使用できる対応するCRLは存在せず、この証明書をリストするマニフェスト[RFC6486]も存在しない。

鍵のロールオーバーを含む何らかの理由で、エンティティが推定(putative)TAとして自己署名CA証明書を取り消したい場合、エンティティはTALで参照されている場所からオブジェクトを削除しなければならない(MUST)。

TALは2件以上のTA URIを含む場合、同じ自己署名CA証明書が、参照される各場所になければならない(MUST)。運用上のレジリエンスを高めるために、(1) これらの各URIのドメイン名部分は、さまざまなリポジトリ公開ポイントが使用する個別のIPアドレスに解決され、(2) これらのIPアドレスは、異なるCAによって署名された経路オリジン認可(ROA)オブジェクトに含まれることが推奨される(RECOMMENDED)。

2.4. 例

# This TAL is intended for documentation purposes only.
# Do not attempt to use this in a production setting.
rsync://rpki.example.org/rpki/hedgehog/root.cer
https://rpki.example.org/rpki/hedgehog/root.cer

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx
GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6
Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9
nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa
BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG
ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9
aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB

3. リライング・パーティーの利用

TALを使用して(推定)TAを取得し、検証するには、RPは以下のことを行う必要がある(SHOULD):

TALに含まれるTA URI(の1つ)によって参照されるオブジェクトを取得する。
取得したオブジェクトが、[RFC6487]に規定されるプロファイルに準拠する、現行の自己署名RPKI CA証明書であることを確認する。
TAL内の公開鍵が、取得したオブジェクト内の公開鍵と一致することを確認する。
RPがこの自己署名CA証明書を発行するエンティティをTAとして受け入れる意思があることを確認するため、適切と思われる他のチェックを(ローカルで)実施する。これらのテストは、この証明書のINR拡張に記述されるすべてのリソースに関連するRPKIの文脈で行われる証明書の有効性に適用される。

RPは、ローカル・リポジトリ・キャッシュ全体で再同期を実行するたびに、この目的のために保持しているTALの各インスタンスに対してこれらの機能(functions)を実行する必要がある(SHOULD)。どのような場合でも、RPはまた、TALが参照する取得されたTAのローカルにキャッシュされたコピーの有効期限が切れる前に、これらの機能を実行する必要がある(SHOULD)。

TALに複数のTA URIが含まれる場合、RPはローカルに定義された優先ルールを使用して、TAとして使用する自己署名RPKI CA証明書を取得するURIを選択してもよい(MAY)。いくつかの例を挙げると:

TALで提供される順序を使用する
利用可能なリストからランダムにTA URIを選択する
接続確立遅延などのRP固有のパラメータに基づいてURIの優先順位リストを作成する

優先URIへの接続が失敗した場合、または取得したCA証明書の公開鍵がTAL公開鍵と一致しない場合、RPは、URIのローカル優先順位に従って、次のURIからCA証明書を取得する必要がある(SHOULD)。

4. URIスキームの考慮事項

RSYNCプロトコルは、トランスポート・セキュリティも、RPが適切なホストに接続していることを検証する手段も提供していないことに留意する。したがって、HTTPS を優先スキームとして使用することを推奨する。

中間者(MITM)は、セクション3に記載するプロセスに従って有効とみなされるCA証明書を作成することはできないが、このタイプの攻撃により、RPが更新されたCA証明書を知ることができなくなることに留意する。

RPは、TAL上のHTTPS URIを使用してCA証明書を取得する場合、TLS証明書とホスト名の検証を行わなければならない(MUST)。RPは、TLS 証明書またはホスト名の検証で問題が発見された場合、オペレータがその原因を調査できるよう、ログに記録する必要がある(SHOULD)。

RPとリポジトリ・サーバは、HTTPS[RFC7230]の使用に関して、[RFC7525]で概説されているベスト・カレント・プラクティスに従うことが推奨される(RECOMMENDED)。RPは、[RFC6125]に記載されているように、subjectAltName dNSNameアイデンティティを使用してTLS証明書とホスト名の検証を行う必要がある(SHOULD)。[RFC6125]で定義されているルールとガイドラインが適用される、次の考慮事項がある:

RPとリポジトリ・サーバは、DNS-ID識別子のタイプをサポートする必要がある(SHOULD)。DNS-ID識別子タイプは、リポジトリ・サーバ証明書に存在する必要がある(SHOULD)。
リポジトリ・サーバ証明書のDNS名は、ワイルドカード文字「*」を含める必要はない(SHOULD NOT)。
このプロトコルはSRV-IDを使用する必要はない。
このプロトコルはURI-IDを使用する必要はない。

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

TAの秘密鍵の危殆化により、権限のない当事者がTAになりすますことが可能となり、深刻な結果を招く可能性がある。不適切または不正確なTAに依存すると、同様の深刻な結果を招く可能性がある。

このTALは、参照する自己署名CA証明書がカバーするリソースのリストを直接提供しない。その代わり、RPはTA自体とこの証明書内のINR拡張を参照する。これは、運用上必要な柔軟性を提供するものだが、同時に証明書の発行者があらゆるリソースに対して権限があると主張できるようになる。RPは、(1) TAとして設定する証明書の発行者に対して絶大な信頼を寄せるか、(2) 独自の自己署名証明書をTAとして発行し、その際に下位の証明書に制約を課す必要がある。

6. IANA に関する考慮事項

この文書にはIANAのアクションはない。

7. 参考文献

7.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.

[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <https://www.rfc-editor.org/info/rfc5781>.

[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, <https://www.rfc-editor.org/info/rfc7730>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[X.509] ITU-T, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, October 2016, <https://www.itu.int/rec/T-REC-X.509>.

7.2. 参考規格

[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, DOI 10.17487/RFC4158, September 2005, <https://www.rfc-editor.org/info/rfc4158>.

[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, <https://www.rfc-editor.org/info/rfc5914>.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.

謝辞

TAファイルに対するこのアプローチは、もともとロバート・キステレキが考えたものである。

著者らは、本文書の草稿作成に協力し、有益なレビューコメントを寄せてくれたロブ・オースティンとランディ・ブッシュの貢献に感謝する。

著者らは、TALに複数のURIを含める背後にあるアイデアの開発におけるロケ・ガリアーノ、テリー・マンダーソン、カルロス・マルティネス＝カニャッツォの功績を謝意を表する。

著者らは、TALの冒頭にコメントを含めることを提案してくれたジョブ・スナイデルスに感謝する。

著者のアドレス

ジェフ・ヒューストン
APNIC
メール: gih@apnic.net
URI: https://www.apnic.net

サミュエル・ワイラー
W3C/MIT
メール: weiler@csail.mit.edu

ジョージ・マイケルソン
APNIC
メール: ggm@apnic.net
URI: https://www.apnic.net

スティーブン・ケント
Unaffiliated
メール: kent@alum.mit.edu

ティム・ブルインジールス
NLnet Labs
メール: tim@nlnetlabs.nl
URI: https://www.nlnetlabs.nl

更新履歴

2024.3.11
2024.3.15: インターネットのトラストアンカーについて

GitHubで編集を提案