الخلاصة

  • كان ملف الشهادة في RFC 5280 يفرض keyUsage وcRLSign على مفتاح توقيع CRL، لكن خوارزمية التحقق أمرت بفحص البت فقط إذا كان الامتداد موجوداً.
  • تجعل RFC 10007 وجود الامتداد وقيمة البت فحصين إلزاميين لشهادة v3. لا يعوض تطابق الاسم والمسار والتوقيع عن تفويض الغرض.
  • يفصل الإيصال القابل للتدقيق بين إصدار الشهادة والمفتاح والامتداد ونطاق CRL وحداثتها والمسار والتوقيع ونتيجة الشهادة المستهدفة وأي استثناء قديم.

لا تبدأ المشكلة بمفتاح مجهول. بل قد تبدأ بمفتاحين مصدقين للجهة نفسها.

تمنح سلطة تصديق subject X شهادة للمفتاح A، وتضع فيها امتداد keyUsage مع cRLSign. هكذا تفوض X لإصدار CRL غير مباشرة، وتشير شهادات أخرى إلى اسم X في cRLIssuer ضمن distribution point.

ثم تمنح السلطة X شهادة ثانية للمفتاح B. الغرض من B عادي، ولذلك لا تحتوي شهادته على keyUsage. الاسم لا يزال X، ومسار B قد يكون صحيحاً وينتهي إلى جذر الثقة نفسه.

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

وثّق Corey Bonnell وTadahiko Ito وTomofumi Okubo معالجة هذا الخلل في RFC 10007، الصادرة في يونيو 2026 على مسار معايير IETF والمحدّثة لـRFC 5280. يرد Bonnell أول المؤلفين الثلاثة. هذا إسناد لمساهمة موثقة في عمل جماعي، لا ادعاء باختراع فردي أو سلطة على المنتجات والبنى المنشورة.

إثبات الهوية غير تفويض الفعل

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

تنص الفقرة 4.2.1.3 من RFC 5280 على وجوب إدراج keyUsage ووسمه critical عندما تستخدم الشهادة للتحقق من توقيعات الشهادات أو CRL. ويعني cRLSign أن المفتاح العام للجهة صالح للتحقق من توقيعات قوائم الإبطال.

لكن خطوة التحقق القديمة قالت: إذا كان امتداد key usage موجوداً، فتحقق من cRLSign. بذلك تفشل الشهادة التي تحتوي الامتداد من دون البت، بينما يمكن لخوارزمية حرفية تجاوز الاختبار إذا غاب الامتداد كله. صار الغياب أيسر من الرفض الصريح.

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

تعدل RFC 10007 الخطوة لشهادات v3: يجب التأكد من وجود keyUsage، ثم التأكد من تفعيل cRLSign. وعلى السجل حفظ النتيجتين. غياب الامتداد يشير إلى profile معيب أو شهادة مصدر اختيرت خطأ؛ وجود الامتداد من دون البت يعلن غرضاً غير مناسب.

للاستثناء القديم إصدار وسياسة

لا تحتوي شهادات X.509 من الإصدارين v1 وv2 على حقل extensions. لذلك لا تطبق RFC 10007 عليها فحص وجود الامتداد. الاستثناء قيد في صيغة الشهادة، وليس إذناً عاماً بحذف الامتداد من v3.

قد يكشف التحديث ديناً قديماً. ربما أصدرت CA شهادة v3 لتوقيع CRL لكنها أغفلت keyUsage. تقبلها التطبيقات القديمة، وترفض التطبيقات المحدّثة القوائم نفسها. لم يتغير التوقيع؛ الذي تغير أن الغرض أصبح جزءاً من الفحص الفعلي.

توصي RFC 10007 بأن تدرج السلطات الامتداد في شهادات التحقق من CRL. وإذا تعذر تغيير profile، ينبغي لسلطة إدارة سياسة PKI فرض DNs مختلفة للشهادات ذات الأغراض المختلفة. تفصل الأسماء بين المفاتيح، لكنها لا تعيد إصدار الشهادة ولا تصلح distribution point ولا تحدد موعد إنهاء الاستثناء.

لا يعني الرفض الجديد أن التطبيق المحدّث سبب الخلل بالضرورة؛ فقد أظهر إعداداً ناقصاً. ولا يعني أن هجوماً أو سرقة مفتاح حدثت. الدليل الأضيق هو أن شهادة v3 المختارة لا تمثل التفويض المطلوب.

بوابة الصلاحية ليست نتيجة الإبطال كلها

بعد cRLSign تبقى اختبارات اختيار المصدر الصحيح، وبناء المسار، والخوارزمية والتوقيع، وdistribution point وissuing distribution point، وحالة CRL غير المباشرة، والامتدادات الحرجة، وthisUpdate وnextUpdate. ويجب ربط CRL الكاملة وdelta بصورة صحيحة.

بعدها يُبحث عن serial الشهادة المستهدفة. قد تكون القائمة موقعة بمفتاح مخول لكنها قديمة أو خارج النطاق. وقد تكون صحيحة وحديثة وتعلن أن الهدف revoked. لذلك لا يجوز تحويل «الموقع مخول» إلى «الشهادة آمنة».

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

توضح عدسة agency لدى Heng Lu توزيع المسؤولية. يحدد مؤلفو المعيار grammar مشتركاً، وتختار CA profile، ويكتب المورد running code، وتجيز جهة السياسة الاستثناء، وتتحمل الخدمة أثر التوقف. تنسق minimum specification معنى الفحص، بينما يبقى توقيت النشر قراراً محلياً. لا يستعير طرف سلطة غيره من دون سجل.

إيصال يعيد بناء القرار

يبدأ الإيصال بالشهادة المستهدفة وجذر الثقة وURI وhash الخاصين بـCRL ووقت الجلب وthisUpdate وnextUpdate والخوارزمية وإصدار validator. ويحدد شهادة المصدر المختارة بالserial وSubject Key Identifier وAuthority Key Identifier المناسب وDN والإصدار.

ثم يسجل المسار والتوقيع وكون الشهادة v3 ووجود keyUsage وcriticality وcRLSign كل واحد على حدة. وإذا طبق استثناء v1/v2، يسمي السياسة والمالك والنطاق وموعد المراجعة.

ويحفظ قسماً مستقلاً للنطاق: distribution point وcRLIssuer وCRL غير المباشرة وissuing distribution point والأسباب وعلاقة complete/delta. وأخيراً يحفظ serial الهدف ووجوده وتاريخ وسبب الإبطال والدليل القديم أو المفقود وقرار التطبيق.

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

يمكن أن تبقى الخلاصة محدودة: عالج validator معلوم CRL محددة بشهادة v3 محددة؛ وجد keyUsage وcRLSign؛ وأنتج نتائج مستقلة للمسار والتوقيع والنطاق والحداثة وserial. قوة RFC 10007 ليست توسيع ادعاء الثقة، بل منع الغياب من التحول إلى سلطة.

المصادر