الخلاصة

  • تستطيع شجرة السياسات في RFC 5280 تكرار الحالة المنطقية ذاتها عندما تصل إليها عدة خرائط؛ ثم تتكرر الفروع اللاحقة، فينمو أسوأ سيناريو نمواً أسياً.
  • تستخدم RFC 9618 رسماً بيانياً لا دورياً موجهاً بعقد مشتركة. تبقى صلاحية المسار ومجموعة السياسات النهائية كما هي، بينما يرتبط الحجم خطياً بعدد السياسات والخرائط في الإدخال.
  • يحتاج الاعتماد إلى إيصالين مترابطين: تكافؤ دلالي للحالات الصعبة، وحدود مقاسة للذاكرة والمعالج والطوابير عند استقبال شهادات عدائية.

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

لم ينجح المرسل في إثبات هوية. لقد نجح في فرض عمل. هذه هي الحدود التي تعالجها RFC 9618: لا ينبغي لمن يقدّم مدخلاً قبل المصادقة أن يمتلك سلطة غير محدودة على الحساب المطلوب للحكم عليه.

ما الذي تحسبه سياسة الشهادة؟

قد تحتوي شهادة X.509 على امتداد لسياسات الشهادة يضم معرفات OID ومحددات اختيارية. تستطيع سلطة التصديق تضييق السياسات المقبولة، وربط سياسة في نطاق الجهة المصدرة بسياسة أخرى في نطاق الجهة التابعة. ويحدد التطبيق مجموعة السياسات التي يقبلها مبدئياً.

تعالج RFC 5280 هذه العناصر أثناء التحقق من مسار شهادة موجود. وهذا يختلف عن البحث عن المسار. تشرح RFC 4158 كيفية بناء سلسلة مرشحة بين الشهادة الهدف ومرساة الثقة؛ أما RFC 9618 فتبدأ بعد ذلك، عند تحديد السياسات التي تبقى عبر الشهادات والقيود والخرائط.

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

يعرض RFC 9618 مثالاً يتضمن معرفين في كل شهادة وسيطة، مع كل الخرائط الممكنة من المعرفين إلى المعرفين التاليين. يتضاعف عدد المسارات عند كل عمق. يزداد حجم السلسلة ببطء، لكن البنية الداخلية تكبر أسياً.

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

ترتبط المسألة بحوادث فعلية. يسجل تغيير OpenSSL الاستهلاك الأسي للموارد في CVE-2023-0464 ومعالجة تحد عدد عقد الشجرة. ويذكر تنبيه Apple أن معالجة شهادة خبيثة في CVE-2023-23524 قد تقود إلى حجب الخدمة. كما يحفظ سجل إصدارات OpenSSL هذا الحد.

مشاركة العقدة بدلاً من نسخ كل طريق

يحتوي valid_policy_graph في RFC 9618 على عقدة واحدة على الأكثر لكل OID عند عمق معين. إن وصلت عدة سياسات سابقة إلى العقدة، صار لها عدة آباء. وتُحفظ ذريتها مرة واحدة.

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

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

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

عقد الإخراج القديم يعيد الخطر

وصفت RFC 5280 شجرة valid_policy_tree الكاملة باعتبارها مخرجاً. قد يطلب مستهلك قديم هذه الشجرة حتى لو عمل المدقّق داخلياً بالرسم البياني الآمن. عند فك العقد المشتركة إلى طرق منفصلة، تعود البنية الأسية.

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

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

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

الحدود المؤقتة ترسم حدود رفض جديدة

قبل اكتمال الانتقال، يمكن تحديد عمق السلسلة أو عدد عقد الشجرة. لكن عمقاً منخفضاً يرفض مسارات مشروعة، وعمقاً مرتفعاً يبقي مساحة للتفرع. توضح RFC 9618 أن زيادة السياسات في كل شهادة قد تبقي نمواً يقارب O(N^(العمق/2)) حتى مع حد للعمق.

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

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

وصل الدلالة بالموارد

تغطي حزمة التكافؤ السياسات البسيطة، والخرائط المتعددة، وanyPolicy، واشتراط السياسة الصريحة، ومنع الخرائط، ومنع anyPolicy، والتقليم، والنتيجة الفارغة. وتقارن القبول أو الرفض ومجموعة السياسات النهائية. التنفيذ السريع لأنه يرفض كل حالة معقدة ليس مكافئاً.

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

يجب أن يلتقي الدليلان: لكل اختبار دلالي أثر موارد، ولكل اختبار عدائي قرار دقيق. وإلا أمكن الاحتفال بسرعة غيّرت المعنى، أو بتوافق أبقى منفذ حجب الخدمة.

ثم يأتي دليل التشغيل: المكتبة المحملة، وخيارات البناء، وإعداد السياسة الفعلي، واستخدام واجهة الشجرة القديمة، وهوية العملية. نشر RFC يجعل الآلية متاحة؛ لا يثبت أنها هي التي حكمت طلب الإنتاج.

لا تحل RFC 9618 كل تكاليف X.509. بناء المسار والتوقيعات والإبطال والتحليل وترخيص التطبيق لها حدود أخرى. هي تزيل تضخيماً محدداً مع إبقاء النتيجة. وهذا التحديد يجعل المساءلة قابلة للقياس.

المصادر