Loading article…
| 略語 | カナダ |
|---|---|
| 状態 | 提案された標準 |
| 初版 | 2010年10月18日 |
| 最新バージョン | RFC 8659 2019年11月 |
| 組織 | 国際電気通信連合 |
| 著者 |
|
DNS 証明機関承認( CAA ) は、ドメイン名の所有者が証明機関に対して、特定のドメイン名のデジタル証明書を発行する権限があるかどうかを示すことができるインターネット セキュリティポリシー メカニズムです。これは、「CAA」ドメイン ネーム システム(DNS)リソース レコードによって行われます。
これは、公的に信頼されている証明機関のセキュリティに関する懸念の高まりに応えて、コンピュータ科学者のPhillip Hallam-Baker 氏と Rob Stradling氏によって起草されました。これは、インターネット技術タスクフォース(IETF)が提案した標準です。
背景
2001年以降に発生した一連の証明書の誤発行[1] [2]により、公的に信頼されている証明機関への信頼が損なわれ[3]、誤発行を追跡する証明書の透明性、クライアント側で誤発行された証明書をブロックするHTTP公開鍵ピンニングとDANE、証明機関側で誤発行をブロックするCAAなど、さまざまなセキュリティメカニズムの開発が加速しました[4] 。
CAAの最初の草案は、フィリップ・ハラム・ベイカーとロブ・ストラドリングによって書かれ、2010年10月にIETFインターネットドラフトとして提出されました。 [5]これはPKIXワーキンググループによって徐々に改良され、[6] 2013年1月にIESGによって提案標準のRFC 6844として承認されました。 [7] CA /ブラウザフォーラムの議論はその直後に始まり、[4] 2017年3月に、彼らは2017年9月までにすべての証明機関にCAAの実装を義務付けることに賛成票を投じました。[8] [9]少なくとも1つの証明機関、Comodoは、期限までにCAAを実装できませんでした。[10]ミュンヘン工科大学による2017年の調査では、証明機関が標準の一部を正しく実装できなかった例が多数見つかりました。[4]
2017年9月、ジェイコブ・ホフマン・アンドリュースはCAA標準を簡素化することを目的としたインターネットドラフトを提出した。これはLAMPSワーキンググループによって改良され、 2019年11月に提案標準であるRFC 8659として承認された。[11]
Qualysは、 2024年6月時点で[アップデート]、最も人気のある15万のTLS対応ウェブサイトのうち、CAAレコードを使用しているのはわずか15.4％であると報告しています。[12]
記録
CAAを実装する認証局は、CAAリソースレコードのDNSルックアップを実行し、見つかった場合は、デジタル証明書を発行する前に、それが承認された当事者としてリストされていることを確認します。各CAAリソースレコードは、次のコンポーネントで構成されています。[11]
- フラグ
- 将来の使用のために拡張可能なシグナリングシステムを実装するフラグバイト。2018年現在、発行者クリティカルフラグのみが定義されており、これは証明書を発行する前に、対応するプロパティタグを理解する必要があることを証明機関に指示します。[11]このフラグにより、 X.509証明書のクリティカル拡張と同様に、将来的に必須の拡張機能を使用してプロトコルを拡張できます。[4][アップデート]
- タグ
- IANA証明機関制限プロパティ レジストリからの次のプロパティのいずれか:
- 問題
- このプロパティは、関連付けられたプロパティ値で指定されたドメインの所有者に、プロパティが公開されているドメインの証明書を発行する権限を与えます。
- 問題ワイルド
- このプロパティは、issueと同様に機能しますが、ワイルドカード証明書の発行のみを承認し、ワイルドカード証明書要求のissueプロパティよりも優先されます。
- 発行メール
- このプロパティは、関連付けられたプロパティ値で指定されたドメインの所有者に、プロパティが公開されているドメインのS/MIME証明書を発行する権限を与えます。 [13]プロパティが存在しない場合でも、S/MIME証明書の発行は妨げられません。
- 問題vmc
- このプロパティは、関連付けられたプロパティ値で指定されたドメインの所有者に、プロパティが公開されているドメインのBIMI証明書を発行する権限を与えます。 [14]プロパティが存在しない場合でも、BIMI証明書の発行は妨げられません。
- iodef
- このプロパティは、証明機関がIncident Object Description Exchange Format を使用してドメイン名所有者に無効な証明書要求を報告する方法を指定します。2018 年現在[アップデート]、すべての証明機関がこのタグをサポートしているわけではないため、すべての証明書発行が報告される保証はありません。
- 連絡先メールアドレス
- GDPR違反の懸念から、WHOISで連絡先情報が利用できなくなるケースが増えています。この特性により、ドメイン所有者はDNSで連絡先情報を公開することができます。[15] [16]
- 連絡先電話番号
- 電話番号については上記と同様です。[17]
- 価値
- 選択したプロパティ タグに関連付けられた値。
CAA記録がない場合は通常の無制限の発行が許可され、1つの空白の発行タグが存在する場合はすべての発行が禁止されます。[11] [9] [18]
認証局の行動を監視する第三者は、新しく発行された証明書をドメインの CAA レコードと照合する場合があります。RFC 8659では 、CAA レコードは、セキュリティ ポリシー違反の可能性のある指標として証明書評価者によって使用される可能性があると規定されています。このような使用では、証明書が発行された時点と証明書評価者が証明書を観察した時点の間に公開された CAA レコードが変更された可能性を考慮する必要があります。[11]
拡張機能
RFC 8657 は、ACME プロトコルで定義されているドメイン制御検証の希望する方法をユーザーが指定できるようにするパラメータを指定します"accounturi"。たとえば、Web サイト管理者は、自分が管理するドメインを、希望する認証局に登録されている特定のアカウントにバインドできます。
"validationmethods"
歴史
CAA 標準の最初の拡張の草案は 2016 年 10 月 26 日に公開され、発行プロパティの末尾に新しいaccount-uriトークンを追加することが提案されました。このトークンは、ドメインを特定の自動証明書管理環境アカウントに結び付けます。 [19]これは 2017 年 8 月 30 日に修正され、ドメインを特定の検証方法に結び付ける新しいvalidation-methodsトークンも含まれるようになりました。 [20]その後、2018 年 6 月 21 日にはさらに修正され、account-uriとvalidation-methodsのハイフンが削除され、代わりにaccounturiとvalidationmethodsになりました。[21]
例
ca.example.netで識別される認証局のみがexample.comとすべてのサブドメインの証明書を発行する権限を持っていることを示すには、次のCAAレコードを使用します: [11]
example.com。IN CAA 0発行"ca.example.net "
証明書の発行を一切禁止するには、空の発行者リストに対してのみ発行を許可します。
example.com. IN CAA 0問題";"
証明機関が無効な証明書要求を電子メール アドレスとリアルタイム インターネットワーク防御エンドポイントに報告する必要があることを示すには、次の手順を実行します。
example.com. IN CAA 0 iodef "mailto:security@example.com" example.com. IN CAA 0 iodef "http://iodef.example.com/"
プロトコルの将来の拡張、たとえば、安全に処理を進める前に認証局が理解する必要がある新しい将来のプロパティを定義する拡張を使用する場合は、発行者クリティカルフラグを設定します。
example.com. IN CAA 0問題"ca.example.net" example.com. IN CAA 128将来"値"
事件
2017年、CamerfirmaがCAAレコードを不適切に検証していたことが判明しました。Camerfirmaは、 CAA検証について規定しているCA/ブラウザフォーラムのベースライン要件を誤解していたと主張しました。[22] [4]
2020年初頭、Let's Encryptは、自社のソフトウェアがCAAレコードを不適切に照会および検証し、300万件以上の証明書に影響を与える可能性があることを明らかにしました。[23] Let's Encryptは顧客やサイト運営者と協力して170万件以上の証明書を交換しましたが、クライアントのダウンタイムを回避するため、また影響を受ける証明書がすべて90日以内に期限切れになるため、残りの証明書を失効させないことに決めました。[24]
参照
参考文献
- ^ Ristić, Ivan. 「SSL/TLS と PKI の歴史」。Feisty Duck。2018年6 月 8 日閲覧。
- ^ Bright, Peter (2011年8月30日)。「新たな不正な証明書が、証明機関に関する同じ古い疑問を提起」。Ars Technica 。 2018年2月10日閲覧。
- ^ Ruohonen, Jukka (2019). 「DNS 認証局認可の早期導入に関する実証的調査」.サイバーセキュリティ技術ジャーナル. 3 (4): 205–218. arXiv : 1804.07604 . doi :10.1080/23742917.2019.1632249. S2CID 5027899.
- ^ abcde Scheitle, Quirin; Chung, Taejoong; et al. (2018 年 4 月). 「認証局認可 (CAA) の初見」(PDF) . ACM SIGCOMM コンピュータ通信レビュー. 48 (2): 10–23. doi :10.1145/3213232.3213235. ISSN 0146-4833. S2CID 13988123.
- ^ Hallam-Baker, Phillip ; Stradling, Rob (2010 年 10 月 18 日)。DNS 認証局認可 (CAA) リソース レコード。IETF。ID draft -hallambaker-donotissue-00。
- ^ Hallam-Baker, Phillip ; Stradling, Rob; Ben, Laurie (2011 年 6 月 2 日)。DNS 認証局認可 (CAA) リソース レコード。IETF。ID draft -ietf-pkix-caa-00。
- ^ Hallam-Baker, Phillip ; Stradling, Rob (2013 年 1 月). DNS 認証局認可 (CAA) リソース レコード. IETF . doi : 10.17487/RFC6844 . ISSN 2070-1721. RFC 6844.
- ^ Hall, Kirk (2017年3月8日)。「投票187の結果 - CAAチェックを義務化」CA/Browserフォーラム。 2018年1月7日閲覧。
- ^ ab Beattie, Doug (2017 年 8 月 22 日)。「CAA (Certificate Authority Authorization) とは?」。GlobalSign。2018年2 月 2 日閲覧。
- ^ Cimpanu、Catalin (2017 年 9 月 11 日)。「Comodo が CAA の新基準発効の翌日に違反しているのが発覚」Bleeping Computer。2018年1 月 8 日閲覧。
- ^ abcdef DNS 認証局認可( CAA) リソースレコード。IETF。2019年11 月。doi : 10.17487/ RFC8659。ISSN 2070-1721。RFC 8659。
- ^ 「SSL Pulse」。SSL Labs。Qualys。2020年1月3日。 2020年1月31日閲覧。
- ^ 電子メールアドレスの証明機関承認（CAA）処理。IETF 。 2023年10月。doi ：10.17487 / RFC9495。ISSN 2070-1721。RFC 9495。
- ^ 「マーク証明書の発行に関する最低限のセキュリティ要件」(PDF)。AuthIndicatorsワーキング グループ。2024 年 3 月 7 日。
- ^ 「X.509 (PKIX) パラメータを使用した公開鍵インフラストラクチャ」www.iana.org 。 2020 年8 月 22 日閲覧。
- ^ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf 2023年5月29日アーカイブ、Wayback Machine [ URLのみのPDF ]
- ^ Beattie, Doug (2019年1月7日). 「投票SC14: CAA連絡先プロパティおよび関連する電話検証方法」. CA/Browserフォーラム(メーリングリスト) . 2020年10月19日閲覧。
- ^ 「Certificate Authority Authorization (CAA) とは何ですか?」Symantec。2018年1月8日時点のオリジナルよりアーカイブ。2018年1月8日閲覧。
- ^ Landau, Hugo (2016 年 10 月 26 日)。アカウント URI および ACME メソッド バインディングの CAA レコード拡張。IETF。ID draft -ietf-acme-caa-00。
- ^ Landau, Hugo (2017 年 8 月 30 日)。アカウント URI および ACME メソッド バインディングの CAA レコード拡張。IETF。ID draft -ietf-acme-caa-04。
- ^ Landau, Hugo (2018 年 6 月 21 日)。アカウント URI および ACME メソッド バインディングの CAA レコード拡張。IETF。ID draft -ietf-acme-caa-05。
- ^ 「CA:Camerfirma Issues - MozillaWiki」. wiki.mozilla.org . 2021年4月27日閲覧。
- ^ Claburn, Thomas (2020年3月3日). 「Let's Encrypt? Let's revoke 3 million HTTPS certificates on Wednesday, more like: Check code loop blunder strikes」www.theregister.com . 2020年5月31日時点のオリジナルよりアーカイブ。 2021年4月27日閲覧。
- ^ バレット、ブライアン（2020年3月3日）。「先週、インターネットは小さな災害を回避した」。Wired。ISSN 1059-1028。2021年4 月27日閲覧。