الخلاصة

  • تعرّف RFC 9608 امتداد noRevAvail كي تعلن سلطة التصديق أنها لن تنشر معلومات إلغاء لشهادة كيان نهائي. تتجاوز معالجة المسار خطوة الإلغاء ولا تحصل على جواب إيجابي عن الحالة.
  • قد يكون الاختيار مشروعاً لشهادات قصيرة العمر أو لبعض هويات الأجهزة الطويلة جداً، لكن الامتداد لا يثبت بقاء المفتاح في حيازة صحيحة ولا استمرار التفويض ولا قدرة النظام على الاستبدال.
  • يمكن لإيصال محلي مصغّر لدورة الحياة بلا إلغاء أن يربط سبب الملف وسياسة القبول والإشارات البديلة وطريق الخروج. هذا اقتراح تحريري من Daniel Kade، وليس امتداداً جديداً أو شرطاً من IETF.

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

نُشرت RFC 9608 في يونيو 2024 بوصفها Proposed Standard من IETF، وهي تحدّث RFC 5280. يحمل noRevAvail قيمة NULL، وهو غير حرج، ومخصص لشهادات المفاتيح العامة للكيانات النهائية. لا يجوز وضعه في شهادة CA. ومعناه المحدد أن سلطة التصديق لن تتيح معلومات إلغاء لهذه الشهادة.

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

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

التجاوز ليس نتيجة «سليمة»

تتضمن معالجة المسار في RFC 5280 عادةً تحديد أن الشهادة غير ملغاة. تعدّل RFC 9608 هذا الفرع: عند وجود noRevAvail تُتجاوز الخطوة. كما تحافظ على الحالة الخاصة لامتداد ocsp-nocheck في شهادة مستجيب OCSP، مع اختلاف الغرض والسياق.

لو وصلت استجابة OCSP إيجابية لكانت تصريحاً عن الحالة في سياق زمني وتشغيلي محدد. ولو نُشرت CRL لأمكن فحص الرقم التسلسلي في جسم معلوم. أما noRevAvail فلا يعيد نتيجة مماثلة. إنه يخبر البرمجية أن جسم الحالة لن يوجد.

تمنع الوثيقة الرسائل المتناقضة. لا يجوز أن تجمع الشهادة بين noRevAvail وبين CRL Distribution Points أو Freshest CRL أو طريقة OCSP داخل Authority Information Access. إن جمعت بينها وجب اعتبارها غير صالحة. لا تترك RFC للمتحقق اختيار أي تصريح متعارض يتبع.

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

أما لوحة تعرض «الشهادة صالحة» فقط فتجمع أحكاماً مختلفة. الأدق أن تقول: المسار صالح؛ فحص الإلغاء متجاوز بسبب الملف؛ القبول المحلي نشط وفق القاعدة المعينة؛ والمراجعة القادمة في تاريخ معلوم. لكل سطر مصدر ومالك ويمكن أن يتغير مستقلاً.

العمر القصير سباق بين ساعات متعددة

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

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

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

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

لذلك لا تكفي مقارنة notBefore وnotAfter. المؤشر المهم هو العمر المتبقي حين تصبح إشارة الاختراق قابلة للتنفيذ، وقدرة الجهة على وقف التجديد وإغلاق الطريق القديم. عندئذ فقط تصبح قِصَر المدة ضابطاً مُختبراً لا شعاراً.

الهوية الطويلة تحتاج طريقاً محلياً للتوقف

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

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

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

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

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

إلغاء CA يكشف حجم القرار

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

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

لذلك يشمل قرار الاعتماد الثقة في تشغيل CA وضوابطها واستجابتها للحوادث. تميز RFC 3647 بين Certificate Policy التي تعلن متطلبات لفئة، وCertification Practice Statement التي تشرح كيفية تنفيذ الإجراءات والضوابط. لا يستطيع بت واحد أن يحمل هذا السياق.

ينبغي ربط القبول بإصدار محدد من الملف وCP/CPS وسبب محدد. ما الساعات التي تجعل المدة قصيرة؟ ما مسار الاستبدال للهوية الطويلة؟ أي تطبيقات تقبل وأيها ترفض؟ من يعيد فتح القرار إن تغيرت الخوارزمية أو ظهر حادث عند المصدّر؟

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

صحة المسار لا تحفظ السلطة الحالية

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

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

يفصل منهج Heng Lu بين المواصفة الدنيا والقرار المحلي والتبني الطوعي والكود الجاري والنتيجة المشاهدة. تجعل RFC الغياب قابلاً للفهم المشترك. تختار الخدمة قبول الفئة في سياقها. ينتج التشغيل إشارات، وتستطيع الإشارات تغيير القرار اللاحق.

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

إيصال دورة الحياة بلا إلغاء

الاقتراح هنا سجل محلي مصغّر. عند القبول يربط بصمات الشهادة والمصدر، والملف، وإصدارات CP/CPS، وسبب noRevAvail، ونموذج الصلاحية، والتطبيق، والقاعدة وصاحب القرار. ويسجل غياب مؤشرات CRL وOCSP المحظورة والفرع الذي تجاوزه المتحقق.

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

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

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

تجعل RFC 9608 الغياب صريحاً. مهمة الحوكمة أن تبقيه غياباً وألا تحوله إلى ضمان متخيل. عدم وجود مسار إلغاء يعني أن تلك الآلية لن تكون متاحة. ولا يعني أن المستقبل لن يحمل سبباً لسحب الثقة.

المصادر