الخلاصة

  • يرسل عميل TLS 1.3 وفق draft-ietf-dance-client-auth-14 اسم المالك الكامل لسجل TLSA؛ ويستعلم الخادم عن الاسم نفسه، ويتحقق من DNSSEC ثم يطابق السجل مع الشهادة أو المفتاح العام الخام.
  • يثبت النجاح علاقة محدودة بين بيانات DNS والمفتاح. أما استمرار التعيين وقائمة السماح وإذن الإجراء والنتيجة المرصودة فتحتاج إلى أدلة أخرى.

يعلن الخادم دعمه بوضع dane_clientid فارغًا في CertificateRequest. ويرده العميل في رسالة Certificate محملًا باسم سجل TLSA الكامل. لا يبني الخادم اسمًا من المنفذ أو النقل، بل يستخدم الاسم الذي قدمه العميل مباشرة.

إذا حصل الخادم على مجموعة TLSA موثقة عبر DNSSEC وطابق سجل واحد على الأقل المادة المشفرة المعروضة، فقد أثبت النظير امتلاك المفتاح الخاص الموافق. لكن DNSSEC يوثق بيانات DNS، ولا يثبت أن الملصق ما زال يعود إلى الشخص أو الجهاز أو المؤسسة المتوقعة. وتنص المسودة على بقاء قواعد قائمة السماح والتفويض لدى الخادم.

مسودة ما زالت قيد Last Call

النص الحالي هو المراجعة 14 المؤرخة في 11 سبتمبر 2026. يسجلها Datatracker كمسودة نشطة لمجموعة DANCE تستهدف Proposed Standard. بدأ Last Call الثاني في 15 سبتمبر وينتهي في 29 سبتمبر. ليست RFC ولا موافقة ولا إثبات نشر فعلي.

صنف Security Directorate النص Ready مع تعليقات طفيفة. أما DNS Directorate فصنفه Not ready: يرى أن صيغتي _service و_device لا تفيان بتسجيل أسماء العقد ذات الشرطة السفلية في RFC 8552، وأن شرح صيغة ClientName وحد 255 بايت مربك. يجب إبقاء الحكمين معًا.

طبقات مختلفة للإثبات

يقترح النص أسماء خاصة بالخدمة وأسماء للأجهزة وأسماء حرة. اختيار الدلالة يعود إلى التطبيق. يتحقق الخادم من TLSA حتى مرساة ثقة مضبوطة، أو يثق بمحلل متحقق متصل بأمان وبعلامة AD. الإجابة غير الموقعة، أو التفويض غير الآمن، أو فشل DNSSEC، أو NXDOMAIN أو NODATA لا تعطي مجموعة TLSA موثقة.

في DANE-EE usage 3 يمكن مطابقة الشهادة أو المفتاح مباشرة من دون اسم داخل الشهادة. وفي DANE-TA 2 وPKIX 0/1 يجب أن يطابق ClientName أيضًا dNSName في SAN وفق RFC 7671. وتتبع المفاتيح الخام RFC 7250. هذه مسارات مصادقة وليست قرارات عمل.

ينبغي أن يفصل السجل التشغيلي بين ClientName، واستعلام DNS وTTL، والمتحقق ومرساة الثقة، وحقول TLSA، وبصمة الشهادة أو SPKI، وقاعدة تسمية العميل، وحالة الجهاز أو الحساب، وقائمة السماح، وقرار التطبيق والنتيجة. قد يبقى السجل المخبأ صالحًا بعد إعادة تعيين الجهاز؛ وقد ينجح TLS ويرفض التطبيق الإجراء؛ وقد يسمح التطبيق ثم يفشل النظام اللاحق.

تحمي TLS 1.3 رسالة Certificate بالتشفير، لكن استعلام DNS اللاحق قد يكشف اسم العميل. تقلل آلية RFC 9156 ما تراه طبقات DNS العليا. كشف الاستعلام دليل تعرض للخصوصية، لا دليل اختراق.