الخلاصة

  • تتيح المراجعة 02 لسلطة التصديق مطابقة السجل الدائم مع بصمة JWK بخوارزمية SHA-256 لأي مفتاح عام استخدمه حساب ACME طوال عمره، لا المفتاح الحالي وحده.
  • يمنع تدوير المفتاح المفتاح الخاص القديم من توثيق طلبات جديدة، لكنه لا يلغي تلقائياً تفويض DNS المرتبط ببصمته. حذف TXT وانتهاء الذاكرة المؤقتة وpersistUntil وانتهاء التفويض أحداث مستقلة.
  • تعطيل الحساب هو الإيقاف الفوري على مستوى الحساب في المسودة. وحتى ذلك الحين يلزم إيصال يسجل جيل المفتاح ومشاهدة DNS وCAA وحالة الحساب وآخر موعد لإعادة الاستخدام.

قد تعرض لوحة المفاتيح أن التدوير اكتمل، وتعرض أداة DNS أن السجل اختفى. لا يعني ذلك بالضرورة أن إصدار الشهادة لم يعد ممكناً. فقد تكون سلطة التصديق قد تحققت من السجل قبل التغييرين واحتفظت ببيانات صالحة لإعادة الاستخدام.

هذه الفجوة الزمنية هي جوهر المراجعة 02 من ACME DNS Persistent Challenge، المنشورة في 20 سبتمبر 2026. يضعها سجل Datatracker عند I-D Exists بوصفها Internet-Draft نشطة لمجموعة العمل. ورغم عبارة Standards Track في النص، لا توجد حالة مقصودة أو shepherd أو مدير منطقة أو مرحلة IESG مسجلة. ليست RFC ولا Last Call ولا دليلاً على نشرها لدى أي سلطة.

يقترح النص قيمة TXT تحت _validation-persist. تتضمن dns-persist-01 وبصمة JWK SHA-256 من 43 محرفاً بصيغة base64url بلا حشو، ثم تجزئة تربط اسم النطاق والبصمة وعنوان URL لحساب ACME. تعرّف RFC 7638 البصمة، وتقدم RFC 6920 تمثيل الاسم القائم على التجزئة.

تحسب السلطة القيمة أولاً بالمفتاح الحالي. إن لم تتطابق، تعود عبر المفاتيح العامة التاريخية من الأحدث إلى الأقدم. ويظهر الفرق بين 01 و02 الشرط الحاسم: يحتفظ الخادم الداعم ببصمة كل مفتاح عام استعمله الحساب طوال حياة الحساب. يكشف مستودع مجموعة ACME تطور النص، لا تبنيه تشغيلياً.

الهدف منطقي ضمن ACME. ينبغي أن يستطيع الحساب تبديل مفتاحه من دون إجبار مشغل DNS على إعادة إنشاء تفويض صُمم ليبقى. ولا يحتفظ الخادم بمفتاح خاص قديم؛ البصمة العامة تعرف أصل التفويض لكنها لا تستطيع توقيع طلب جديد.

غير أن الاستمرارية تترك سلطة متبقية. إذا تم التحقق عندما كان K1 هو المفتاح الحالي ثم انتقل الحساب إلى K2، يفقد K1 قدرة المصادقة، لكن التفويض يظل مرتبطاً بالحساب الساري. وحتى في تحقق جديد قد يطابق TXT المبني على K1 لأن البصمة بقيت في التاريخ. تغير الموقّع الحالي لا يسحب منحة DNS السابقة.

حذف TXT ليس لحظياً أيضاً. قد تعيد المحللات التكرارية الإجابة حتى انتهاء TTL. وتفصل المسودة بوضوح بين TTL ومدة إعادة استخدام بيانات التحقق: الأول يحكم ذاكرة DNS، والثانية تحكم قرار السلطة المخزن. يستطيع persistUntil وضع سقف، لكن حذفه أو تقصيره لاحقاً لا يقلل بأثر رجعي مدة تحقق حصلت عليه السلطة بالفعل.

هناك إذاً أربع ساعات: مفتاح الحساب القادر على التوثيق الآن؛ النشر الموثوق وذاكرات DNS؛ انتهاء تفويض ACME؛ وسقف persistUntil المثبت وقت المشاهدة. جمعها في حالة واحدة باسم «ملغى» يخفي الموعد الحقيقي لانتهاء القدرة.

تقدم المسودة أداة واحدة فورية واسعة: تعطيل حساب ACME. يجب على السلطة التأكد من أن الحساب ما زال valid، ويعلو التعطيل على فائدة تاريخ المفاتيح. لكنه يوقف الحساب كله، بينما يستهدف حذف TXT نطاقاً بعينه. تحتاج خطة الحادث إلى الأداتين مع تحديد أثر كل منهما.

تدخل هوية النطاق في التجزئة افتراضياً. يسمح domain_name=* بإعادة استخدام القيمة عبر نطاقات عدة للحساب والمفتاح نفسيهما. يخفف ذلك التشغيل لكنه يزيد الارتباط المرئي ونطاق الضرر. وينبغي أن يسجل قرار الإصدار بدقة هوية النطاق ومدى wildcard المقبولين.

يبقى CAA فحصاً مستقلاً. يستخدم accounturi في RFC 8657 عنوان الحساب الفعلي، بينما يدخل العنوان في تجزئة TXT الدائم. لا تحل المطابقة محل CAA، ولا يثبت CAA وجود التفويض الدائم.

يستطيع DNSSEC توثيق الإجابة المرصودة، لا النية الحالية للمؤسسة. توصي المسودة بالتحقق عند توفره وبإفشال التحدي إذا فشل التحقق. تحدد RFC 4033 سلامة المصدر، لكنها لا تقرر إن كانت إجابة مخزنة ما زالت مطلوبة أو إن كان الحساب ينبغي أن يبقى نشطاً.

يمكن تفويض التهيئة المسبقة. بعد POST-as-GET موثق يؤكد أن الحساب valid، يحصل طرف آخر على URL العام والبصمة العامة لبناء TXT من دون المفتاح الخاص. يفصل ذلك مشغل DNS عن صاحب حساب ACME، ولذلك يجب تسجيل من طلب ومن وافق ومن ثبّت التفويض.

لا تسجل قوائم IANA لـACME الرمز dns-persist-01 عند القطع التحريري. ويقدم تصويت SC-088v3 في CA/Browser Forum سياقاً صناعياً لطريقة TXT دائمة مرتبطة بحساب. لا يثبت التصويت نشر هذه المسودة ولا تطابق النظامين.

الحل التشغيلي إيصال يغطي عمر التفويض: FQDN والنطاق؛ التجزئة ووقت المشاهدة؛ دليل الخادم الموثوق والمحلل التكراري؛ TTL وأفق الذاكرة؛ الجهة المصدرة؛ استخدام domain_name=*؛ هوية الحساب المحمية؛ جيل المفتاح الحالي أو التاريخي المطابق؛ حالة الحساب؛ CAA وDNSSEC؛ persistUntil؛ انتهاء التفويض؛ والطلب والإصدار اللذان استهلكا النتيجة.

بهذا يمكن للتدقيق التمييز بين تدوير مع مطابقة تاريخية، وحذف بقي في الذاكرة، وإعادة استخدام بلا تحقق جديد، وتعطيل سبق الإصدار. من دونه نحاول تفسير قرار الأمس بسؤال DNS اليوم.

قد تتغير المسودة قبل النشر. لكن حد الحوكمة واضح: التفويض الدائم ينقل السلطة من إثبات حي إلى تاريخ مُدار. تدوير المفتاح صيانة؛ أما السحب فيجب أن يصيب التفويض الذي ما زال يعمل.

المصادر