提案を評価する前に状況報告日を読む
ドメイン関係ポリシー フレームワークは、ドメインが関係を記述し、相互に確認する方法を提案します。これにより、類似のロゴ、共有された Web サイトのデザイン、または推定された企業連合よりも明確な情報が信頼当事者に提供される可能性があります。このような情報が電子メールの決定に影響を与えるかどうかは、単にその情報が公開されたかどうかだけでなく、その情報の権威、検証ルール、および消費者の行動によって決まります。
プロジェクトの ステータスページ2026年11月9日に査察され、そのステータスは2024年7月1日であることが明示されています。この文書では、一般向けの検討のための提案されたフレームワークが説明されており、次のステップとして記述的なインターネット草案の提出がリストされています。これらの日付は別々にしておく必要があります。今日読み取れるページがそのステータス ステートメントを最新のものにするわけではありません。この評価では、その後の最終的なプロジェクトのステータス、標準の成果、受信者の採用は検証されていません。
の プロジェクトのホームページ アドホック開発について説明し、展開の詳細が欠落していることを認めます。あ 2024 年 2 月の開発者アカウント、J. Trent Adams 氏 同様に、この作品を初期提案と呼んでいます。標準化に関するその文言は、その文脈で読む必要があります。この記事では、その文書化されたモデルを評価します。実装されている標準を発表したり、本番のDNSレコードを規定したりするものではありません。
検出メカニズムをポリシーの意味から分離する
提案された 建築 小規模なDNS TXTアサーションと、必要に応じてより豊富なポリシー ドキュメントが含まれています。アサーションは基本的な関係を表現したり、詳細なポリシーを発見したりするのに役立ちます。この文書はメタデータをポリシーの内容から区別し、語彙でさまざまな種類の関係を説明できるようにします。解釈作業の多くは信頼当事者に属します。
その分離が重要です。文書を見つけても、2 人の消費者がその語彙を同じに解釈しているとは限りません。消費者は、サポートされている用語や未知の用語に対する動作など、評価対象の関係について合意されたプロファイルを必要とします。利用可能なページは、1 つの完全な相互運用可能な文法を確立するのではなく、可能性を示しています。最小限のアサーション内容の異なる記述を、黙って発明された必須形式に解決すべきではありません。
アーキテクチャの説明の 1 つは、 DNS資格も必要とします。 RFC 1035セクション 3.3 および 3.3.14 TXTデータを 1 オクテット長の 1 つ以上の文字列として定義します。 255 オクテットのコンテンツ境界は、 TXTリソース レコード全体の普遍的な最大 255 文字ではなく、個々の文字列に適用されます。この修正は、DRPF の欠落しているパブリケーションまたは解析プロファイルを提供するものではありません。
相互確認を具体的な主張として検討する
開発者アカウントは両方向の確認を記述します。別のドメインを指定するアサーションには、そのドメインからの対応するステートメントが必要です。これは一方的な関連性の主張に異議を唱えます。法的所有権、両方の管理者のアカウントの整合性、または電子メールで受信した支払い指示の安全性を独立して確立するものではありません。
評価者は、各発行者が実際にどのような権限を管理しているのか、またどのような証拠が検索を保護しているのかを特定する必要があります。侵害されたシステムからの 2 つの相互に一貫したステートメントは、1 つのドメインがサポートされていない主張を行うこととは別の問題のままです。したがって、セキュリティレビューには、脅威モデル、信頼性の仮定、および定義された障害処理が必要です。これらはここでの評価要件であり、この記事で提案またはテストされた実装によって実証される機能ではありません。
架空のブランド関係をエンドツーエンドでマッピングする
架空のドメインbrand.exampleとparent.exampleについて考えてみましょう。ブランド管理者は下位のアサーションを公開します。親管理者は対応する確認を公開します。仮想のセキュリティ アプリケーションは消費者です。提案されているタスクは、主張されるビジネス上の関連付けをメッセージ認証から切り離しながら、同じ関係について 2 つの有向ステートメントを比較することです。
プロジェクトの 関連ドメインの使用例 は、2 つの検出アプローチを示しています。コンシューマは、親のアサーションを通じて親のポリシーを発見したり、子によってより直接的に提供されたポリシーの場所に従うことができます。このページには、構造化された JSON-LD ドキュメントも示されています。これらは概念的な例であり、指定された企業が DRPF を導入していることや、サンプル ラベルが安定したワイヤ形式を形成していることを示す証拠ではありません。
この架空の地図について、消費者は、特定の時点での関係を裏付ける文書と解釈を記録します。親が承認を撤回した場合、その関係はもはや同じような相互サポートを持たなくなります。これらの架空のドメインのレコードは公開または取得されておらず、パーサー、署名検証、証明書利用者の動作はテストされていません。
引き出し能力を超えたライフサイクルが必要
このアーキテクチャでは、確認を変更することで関係を切断することが説明されています。これは概念的な取り消しメカニズムとしては便利ですが、どこでも即時取り消しを確立できるわけではありません。キャッシュされたアサーション、保持されたポリシー文書、および一時的に利用できないパブリッシャーは、コンシューマが信頼できる決定を下す前に明示的に処理する必要があります。
審査者は、証拠がどのくらいの期間使用可能であるか、一方の側だけが変更された場合に何が起こるか、利用できないポリシーと意図的な撤回はどのように異なるのかを尋ねる必要があります。パブリッシャーの侵害やポリシー チェーンの矛盾後の回復にも、定義された結果が必要です。これらの質問は、相互発行によって後続のすべての状態遷移が解決されるという楽観的な仮定ではなく、文書化されたライフサイクル ルールと承認されたテストを生成する必要があります。
電子メール認証とビジネス承認を分離する
2 つの異なるドメイン間で宣言された管理関係は変更されません DMARC アライメント それ自体で。 RFC 9989セクション 4.4 認証された識別子と作成者ドメイン間の調整を定義します。関係の主張は、無関係な受け渡し署名を整合されたものに変えることはなく、この評価は、DRPF を例外として扱う受信側ルールを確立しません。
同様に、受信箱配置の利点、継承された評判、またはサプライヤーへの支払いの許可は証明されていません。将来の消費者が関係情報を使用する場合は、それが影響する正確な決定を文書化し、メッセージ認証とビジネス承認のための独立した制御を保持します。将来起こり得るシグナルが、ひっそりとホワイトリストに登録されたり、既存のポリシーを弱体化させる理由になったりしてはなりません。
未確認事項を記録する
提案された関係マップは分析成果物として提供されますが、ステータス要件は未解決のままです。正確な要件は次のとおりです。提案された 1 つの関係、その発行者、消費者、検証および取り消しモデルをマップします。現在のプロジェクトのステータスを確認します。コミッショニングゲートは次のとおりです: 現在のプロジェクトと採用状況を確認します。採用されたIETF標準として提示せずに提案を説明します。
リンクされたソーシャル アカウントと Datatracker 検索にはアクセスできず、再試行もバイパスもされませんでした。検索がないからといって、その後の作品が存在しないことを証明することはできません。より強力な結論や出版の前に、現在のステータスの確認、専門家のレビュー、実装および相互運用性のテスト、ライブプレゼンテーションのレビュー、所有者の承認が依然として必要です。