الخلاصة

  • اسم نطاق التفويض، Authorization Domain Name أو ADN، هو الاسم الذي تتحقق سلطة التصديق من السيطرة عليه فعلياً؛ وقد يُشتق من FQDN المطلوب بدلاً من أن يطابقه.
  • تصف SC101 قراءة خطرة للتعريف السابق: حذف مقاطع من اليسار أولاً ثم اتباع CNAME كان يمكن أن يجعل سيطرة مشغل وجهة الاسم المستعار تبدو كأنها تشمل نطاقات فرعية يملكها العميل.
  • تختار القاعدة الجديدة طريقة التحقق أولاً، ومنها يتحدد جواز اتباع CNAME أو الحذف أو كليهما؛ وإذا جاز الإجراءان، يأتي CNAME قبل حذف المقاطع.
  • تسمح v2.2.9 حتى 15 نوفمبر 2026 باتباع قسمها الحالي أو قسم 3.2.2.4 من v2.2.7. لذلك يجب أن يحفظ سجل الإصدار نسخة القاعدة وكل التحولات التي انتهت إلى ADN.

وثيقة جارية تتضمن مسارين نظاميين

تحمل TLS Baseline Requirements v2.2.9 تاريخ 6 أغسطس 2026. ويسجل جدول المراجعات SC101 بوصفها توضيحاً لأسماء نطاق التفويض، بينما يجعل جدول مواعيد الامتثال 15 نوفمبر تاريخاً لمتطلب الاشتقاق الجديد.

لكن الفترة الفاصلة ليست سماحاً غير مكتوب. ينص قسم 3.2.2.4 على أن لسلطة التصديق، قبل 15 نوفمبر، أن تمتثل للقسم الجاري أو للقسم المقابل في v2.2.7. ومن ذلك اليوم يصبح القسم الجاري إلزامياً. فالمسار القديم خيار انتقالي أقره النص الجديد، لا مخالفة تغاضى عنها المنفذون.

لهذا لا تكفي عبارة «وفق المتطلبات الجارية». قد تصف خدمة نُقلت فعلاً إلى خوارزمية SC101، وقد تصف خدمة استخدمت على نحو صحيح إحالة v2.2.9 إلى النص الأقدم. رقم الوثيقة المستشهد بها لا يعرّف فرع الشفرة الذي عالج الطلب.

يسجل اقتراع SC0101v2 إجماع المشاركين: وافق 27 مصدراً للشهادات، ووافقت Apple وGoogle وMicrosoft وMozilla من فئة مستهلكي الشهادات، بلا رفض أو امتناع. ويذكر السجل استيفاء العتبات ونصاباً مقداره 17. جرت المناقشة من 12 إلى 19 يونيو، والتصويت من 23 إلى 30 يونيو، وانتهت مراجعة حقوق الملكية الفكرية في 6 أغسطس.

يثبت ذلك اعتماد النص. ولا يثبت أن جميع محركات التحقق وإعداداتها ووثائق CP/CPS واختباراتها وعقد الإنتاج والنسخ الاحتياطية تحولت في لحظة واحدة. الإجماع النظامي والنشر الفعلي سجلان منفصلان.

الوجهة التقنية لا تملك فضاء أسماء العميل

يطلب المشترك إدراج FQDN واحد أو أكثر في الشهادة. تختار CA طريقة مسموحاً بها لتثبت السيطرة. ويمثل ADN الاسم الذي تعمل عليه تلك الطريقة. وقد تتيح السياسة، وفق الطريقة، اتباع اسم DNS مستعار أو حذف مقاطع من يسار الاسم المطلوب.

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

تشرح SC101 أن التعريف القديم جمع الوصف والتعليمات المعيارية، فلم يكن واضحاً هل تُستخدم الخطوات منفردة أو متسلسلة أو متكررة. وبحسب إحدى القراءات الشديدة، كان يمكن للـ CA أن تحذف أولاً مقاطع اليسار من FQDN ثم تتبع CNAME واحداً أو أكثر.

إذا أشار example.com عبر CNAME إلى example.org، يستطيع مشغل example.org إثبات سيطرته على الوجهة. لكنه لا يصبح صاحب blog.example.com. فإذا حُذف blog قبل السير على الاسم المستعار، فقد تبدو سيطرة المشغل على الوجهة كأنها تكفي للنطاق الفرعي لدى العميل. ويورد نص الاقتراع مشغل CDN مثالاً للطرف القادر على إثبات السيطرة على الوجهة.

لا يبلغ المصدر عن استغلال وقع، ولا يسمي CA أو CDN ارتكب مخالفة، ولا يقدم شهادة سيئة محددة. موضوع التحليل هو حدود تفويض مختلفة أتاحتها قراءة النص، لا حادثة مفترضة.

اختيار طريقة التحقق يسبق تغيير الاسم

تبدأ SC101 باختيار طريقة التحقق. وتحدد الطريقة المختارة إن كان اتباع CNAME مسموحاً، وإن كان حذف المقاطع مسموحاً، أو كلاهما، أو لا هذا ولا ذاك. فالطرق التي تتحقق عند اسم تقني يبدأ بشرطة سفلية لا ترث تلقائياً آثار الطرق التي تعمل عند الاسم نفسه.

وإذا جاز التحويلان واستُخدما، تتبع CA سلسلة CNAME أولاً ثم تحذف المقاطع اليسرى. يمنع هذا الترتيب الحذف المبكر من توسيع ما يبدو أن وجهة الاسم المستعار تفوضه. ويصبح الاسم الناتج ADN الذي تثبت الطريقة المختارة السيطرة عليه.

يجب على المهندس تنفيذ النص النظامي الكامل وجدول الطرق، لا هذا الشرح المختصر. لكن الشرح يكشف الحالات التي ينبغي أن يراها الدليل: FQDN الداخل، الطريقة، التحولات المسموحة، سلسلة CNAME المرصودة، الحذف المرتب، ADN النهائي، والإثبات المستخدم.

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

إيصال الانتقال يجب أن يحفظ المسار لا النتيجة

السجل الذي يقول «نجح التحقق» يفقد المعلومة التي جعلها الانتقال أساسية. يلزم إيصال يربط، في الحد الأدنى:

وقت الإصدار + FQDN المطلوب + طريقة التحقق المختارة + نسخة/قسم BR + أرصاد CNAME وسلسلته + عمليات الحذف بالترتيب + ADN المختار + هوية دليل التحقق ووقته + نسخة CP/CPS + إصدار التنفيذ/الإعداد + مرجع اختبار أو تدقيق + الاستثناءات

يحدد الوقت الخيارات التي كانت جائزة. ويبين FQDN مع ADN انتقال حدود السيطرة. وتحدد الطريقة التحولات المتاحة. وتفصل النسخة بين v2.2.7 وv2.2.9. وتحفظ أرصاد DNS حالة قابلة للتغير. وتصف CP/CPS الممارسة المعلنة، فيما يصف إصدار البرنامج وإعداده ما كان يمكن تنفيذه.

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

هذه الحزمة اقتراح تحليلي من Daniel Kade، وليست التزاماً خفياً منسوباً إلى CA/Browser Forum. تحتوي المتطلبات أصلاً على واجبات للسجلات والسياسات والتدقيق. والحجة هي أن خياراً صريحاً بين خوارزميتين لا يصبح قابلاً للمراجعة إلا إذا حمل الإثبات هوية الخيار.

CP/CPS تصريح مؤسسي لا أثر تنفيذ فردي

تعلن CA ممارستها عبر Certificate Policy وCertification Practice Statement، ويوفر RFC 3647 إطاراً معروفاً لذلك. ويمكن للمراجعة أن تسمي تاريخ الانتقال والطرق المتأثرة وسياسة التراجع.

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

النص المشترك وبرامج الجذور طبقتان مختلفتان

تصف Baseline Requirements نفسها بأنها ضرورية وغير كافية، وتربط إلزام CA بتبني موردي تطبيقات الأطراف المعتمدة وإنفاذهم. يضع Forum الحد المشترك، وتحتفظ برامج الجذور بقرار الثقة في منتجاتها.

تدمج Mozilla Root Store Policy المتطلبات المشتركة مع قواعد Mozilla التي قد تكون أسبق أو أشد. وتعرض Apple Root Program Policy طبقة برنامج مستقلة أخرى. يُستشهد بهما لضبط حدود السلطة، لا للحكم على تنفيذ SC101 لديهما.

اقتراع Forum، وCP/CPS لدى CA، وتشغيل محرك التحقق، وقرار برنامج جذور أربعة سجلات. المسودة الموجودة عن Entrust وسلطة Google تخص الرابع. أما هذه المقالة فتلتزم بالسؤال السابق: أي اشتقاق من الاشتقاقين الجائزين قبل الاسم؟

حدود المعرفة العامة

النص والموعد معلنان، أما حالة كل CA فلا. غياب بيان تنفيذ لا يثبت التأخر، والإشارة العامة إلى v2.2.9 لا تثبت الانتقال المبكر. من دون سجل الإصدار تكون العبارة المنضبطة: «نسخة القاعدة غير مثبتة».

المصادر