الخلاصة

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

مفتاحان تحت اسم واحد

يبني RFC 10007 المثال على الموضوع X. تصدر سلطة التصديق شهادة للمفتاح A، وتضع فيها keyUsage مع cRLSign. ثم تصدر للموضوع X شهادة أخرى للمفتاح B لغرض عادي، بلا keyUsage.

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

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

يوحّد RFC 10007 جانبي الإصدار والاستهلاك. في شهادة v3 يجب أن يوجد الامتداد أولًا، ثم يثبت البت الغرض. أما v1 وv2 فلا يملكان حقل امتدادات، فلا يطالب التصحيح ببيان يستحيل حمله.

الاسم ليس بصمة المفتاح

لا يحتاج المثال إلى منتحل. قد يملك X المفتاحين بصورة مشروعة. الخلل هو تحويل هوية صحيحة إلى تفويض شامل لكل مفاتيح الموضوع.

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

يفصل RFC 5280 بين digitalSignature وkeyCertSign وcRLSign. ويعني الأخير التحقق من توقيعات قوائم الإبطال والقوائم التفاضلية وقوائم إبطال السلطات. قدرة المفتاح على إنشاء توقيع لا تعني أن الشهادة صدّقت استخدامه لإعلان حالة الإبطال.

توثق نسخة Datatracker وتاريخ الوثيقة وميثاق LAMPS وتاريخ المجموعة المراجعة والنشر. لا تثبت هذه السجلات نسبة التبنّي أو توافق منتج بعينه.

القائمة غير المباشرة تحتاج أدلة متوازية

قد يختلف مُصدر القائمة غير المباشرة عن سلطة التصديق التي أصدرت الشهادة محل الفحص. يستطيع موضع التوزيع في الشهادة تسمية cRLIssuer، فيما يعلن امتداد issuingDistributionPoint الحرج في القائمة indirectCRL ويحدد النطاق.

على الطرف المعتمد أن يفصل بين اسم المُصدر، والدور غير المباشر، والنطاق، والمسار، ومرساة الثقة، والتوقيع، والغرض، والزمن، وتغطية أسباب الإبطال. يصلح RFC 10007 الغرض فقط. وجود cRLSign لا يثبت صحة المحتوى أو حداثته أو اكتماله أو توافر المستودع.

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

قد يصيب الإصلاح إرثًا كان يعمل

يحذر RFC 10007 صراحة من أن التطبيق المحدّث لن يستطيع التحقق من قائمة موقعة بشهادة v3 أُريد لها هذا الغرض لكنها خلت من keyUsage. النية التشغيلية قد تكون مشروعة، لكن ملف الشهادة غير مطابق.

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

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

لـOCSP تفويض مستقل. يفرض RFC 6960 توقيع السلطة نفسها، أو إعدادًا محليًا، أو شهادة تفويض تحمل id-kp-OCSPSigning ضمن علاقة إصدار محددة؛ وتشرح صفحة معلوماته آلية أخرى. لا يجعله RFC 10007 بديلًا تلقائيًا. ويظهر RFC 6818 مع صفحة معلوماته صيانة سابقة لملف RFC 5280، لا نشرًا تلقائيًا في الأنظمة.

قاعدة رفيعة قابلة للتحقق محليًا

يميّز مبدأ Lu Heng عن أولوية الشفرة العاملة بين النشر والواقع التشغيلي. ويضع إطار الحد الأدنى للمواصفة والقرار المحلي والتبنّي الطوعي الثوابت الأمنية الحتمية في الطبقة المشتركة، ويترك تسلسل النشر لمن يتحمل النتيجة.

شرط cRLSign في v3 قاعدة محددة يستطيع كل طرف فحصها على الشهادة الدقيقة. لا يحتاج إلى تقدير مؤسسة لما إذا كان B «جديرًا بالثقة». أما إعادة الإصدار والتجربة وموعد التفعيل والحفاظ على التغطية فتظل قرارات محلية تثبتها الأنظمة العاملة.

المصادر