العَلَم الحرج لا يُلزم جهة التصديق بفهم كل قيد

الخلاصة

• يقيّد accounturi المعترف به الخاصية بالحساب الطالب، ويقيّد validationmethods طرق التحقق؛ ويبقى تطابق نطاق تعريف جهة التصديق شرطاً مستقلاً.
• التعرف إلى المعاملات اختياري وخاص بكل جهة، لكن جميع أنظمة الإصدار التي تستخدم نطاق تعريف CA واحداً يجب أن تطبق الدعم نفسه باتساق.
• يعالج العَلَم الحرج وسم خاصية مجهولاً أو غير مدعوم، ولا يجبر جهة تعرف issue على فهم كل معامل داخلها.

يبدأ الخطأ من اختصار معقول ظاهرياً. يرى المراجع القيمة الحرجة على issue، فيستنتج أن أي جهة لا تفهم قيد الحساب أو الطريقة سترفض الطلب. إلا أن طبقة القرار التي يصفها العلم ليست طبقة المعامل. يمكن للنظام أن يعرف وسم issue بينما لا يعلن دعمه لـ accounturi أو validationmethods.

يضع RFC 8659 وظيفة CAA في نطاق إصدار الشهادة. تبحث الجهة عن مجموعة السجلات ذات الصلة لكل اسم مطلوب، وتتبع الأسماء البديلة أثناء استعلام CAA، وتصعد حتى أول RRset غير فارغ. القرار لا يغيّر قواعد اعتماد شهادة موجودة لدى الطرف المستند، وتعديل DNS لاحقاً ليس إبطالاً تلقائياً.

يضيف RFC 8657 دقة على مستوى الخاصية. إذا تعرفت الجهة إلى accounturi، فلا تسمح الخاصية التي تحتويه إلا للحساب الذي تعرّفه URI، مع استمرار ضرورة تطابق نطاق تعريف CA. غياب المعامل يترك أي حساب مؤهلاً ضمن تلك الخاصية. تكراره أو فساد URI أو عدم تعرف الجهة إليها يجعل الخاصية غير قادرة على منح الإذن.

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

أما validationmethods فيحصر الإذن في طريقة من قائمة مفصولة بفواصل. القائمة الفارغة لا تسمح بأي طريقة مدرجة. لطرق ACME تسميات مسجلة؛ وقد تحتاج طريقة غير ACME إلى تسمية تعرفها الجهة نفسها. الكتابة الصحيحة في DNS لا تكفي ما لم تصرح الجهة بأنها تتعرف إلى المعامل والقيمة.

هذا الدعم اختياري وخاص بجهة التصديق. لذلك ينصح RFC ببيان دعم واضح. توثق Let's Encrypt مثلاً نطاقها التعريفي letsencrypt.org، وشكل URI الحساب، وتسميات http-01 وdns-01 وtls-alpn-01. الوثيقة دليل محدود على إعلان خدمة بعينها، وليست تدقيقاً مستقلاً لكل نظام خلفها ولا برهاناً على دعم عام.

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

يجب أيضاً ألا تلتبس URI الحسابات عبر جميع نطاقات التعريف التي تعترف بها الجهة، بما فيها مساحات الأسماء المدمجة. وجود مكوّن سلطة في URI يساعد على تمييز حسابين قد يحملان الرقم المحلي نفسه. لا يعني ذلك أن جهات تصديق غير مرتبطة مطالبة بقاعدة حسابات مشتركة.

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

هنا يتضح حد العَلَم الحرج. وفق RFC 8659، يتعلق السلوك بوسم خاصية مجهول أو غير مدعوم. لا يعلن أن كل معامل تحت وسم معروف صار إلزامياً. ولا يمكن للمالك أن يستبدل بيان دعم الجهة ببت واحد.

يتباعد التفويض والإصدار زمنياً أيضاً. يقترح RFC 8657 تقصير عمر التفويض أو إعادة فحص CAA قرب الإصدار لتقليل الفاصل، لكن مثال الساعة تقريباً ليس مهلة عالمية. قد تبقى شهادة صدرت أثناء استثناء مؤقت صالحة بعد إعادة السجل إلى حالته الضيقة.

الدليل الصحيح يجمع: الاسم المطلوب، RRset الفعلي، مسار الأسماء البديلة والتفويض، نتيجة DNSSEC، الخاصية المنطبقة، نطاق CA، قرار تعرف المعامل، URI الحساب، الطريقة، نظام الإصدار، وقت القرار وهوية الشهادة. العلم الحرج وحده لا يثبت هذه السلسلة.

المصادر

1. RFC 8657 — امتدادات CAA لربط URI الحساب وطريقة ACME
2. RFC 8659 — سجل DNS لتفويض جهة التصديق
3. Let's Encrypt — توثيق CAA
4. Heng Lu — مشكلة الوكالة في قلب حوكمة الإنترنت
5. Heng Lu — لماذا توجد BTW Media ولماذا الواقع هو المنتج