الخلاصة

  • يفرض RFC 9919 وجود nextUpdate؛ تُرفض الإجابة إذا غاب، وتُرفض باعتبارها قديمة إذا تجاوزته ساعة العميل الحالية.
  • يثبت التوقيع سلامة محتوى OCSP ونسبته إلى مجيب مخوّل، لكنه لا يمدّد حالة good القديمة ولا يحمي ترويسات HTTP المحيطة.
  • يحتاج التدقيق إلى الإجابة ذاتها وسلطة الموقّع وفترة الحالة والساعة وهامشها ومسار الذاكرة الوسيطة وسياسة المدقق وفعل التطبيق النهائي.

كائن أصيل فقد صلاحيته لاتخاذ القرار

قد تعود إجابة OCSP من ذاكرة قريبة بسرعة، وتنجح بنيتها وتوقيعها، وتحمل الحالة good. ومع ذلك يجب رفضها إذا وقع الزمن الحالي بعد nextUpdate. لم تُزوّر الإجابة؛ الذي انتهى هو نطاق استخدامها.

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

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

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

good إجابة محدودة لا تصريح شامل

يعرّف RFC 6960 الحالات good وrevoked وunknown. في حدها الأدنى، تعني good أن المجيب لا يعرف شهادة تحمل الرقم التسلسلي المطلوب، وهي ضمن مدة صلاحيتها، بوصفها ملغاة. لا تثبت بالضرورة أن الشهادة أُصدرت أصلاً. ولا تحل محل فحص عمر الشهادة أو مسار الثقة أو اسم الخدمة أو صلاحيات التطبيق.

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

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

ساعة العميل جزء من سطح الأمان

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

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

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

حداثة HTTP ليست حداثة حالة الشهادة

تستخدم الطلبات الصغيرة GET لتمكين الذاكرة الوسيطة. يرفق المجيب حقولاً مثل Date وLast-Modified وExpires وETag وCache-Control. يساعد max-age على توزيع التحديث قبل nextUpdate، ويمنع must-revalidate الذاكرة من اختيار تقديم مادة قديمة عمداً.

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

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

كذلك لا يمنح إرفاق الإجابة داخل TLS خادم TLS حق تأليف الحالة. هو يحمل الإجابة ويوفر اتصالاً منفصلاً؛ العميل يحتفظ بقرار قبولها.

الانتقال إلى SHA-256 لا يختصر السلسلة

يلغي RFC 9919 ملف RFC 5019 السابق ويطلب من العملاء المتوافقين استخدام SHA-256 في تجزئتي اسم المصدّر ومفتاحه داخل CertID. يقلل ذلك الحاجة إلى إبقاء دعم SHA-1 القديم وما يضيفه من تعقيد وسطح هجوم.

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

وصل قرار يمكن إعادة بنائه

ينبغي حفظ بصمة الشهادة ورقمها التسلسلي، وتجزئتي اسم المصدّر ومفتاحه وخوارزمياتهما، وبايتات إجابة OCSP كاملة وتجزئتها، وهوية المجيب، ونتيجة سلسلة الموقّع وتفويضه، وproducedAt وthisUpdate وnextUpdate والحالة وحقول الإلغاء.

يضاف إلى ذلك وقت الاستلام ومصدر الساعة وعدم يقينها والهامش وسلوك nonce وإصدار المدقق وسياسته وسبب القبول أو الرفض وفعل التطبيق اللاحق. تُحفظ عقدة الذاكرة وAge وETag وExpires ومحاولة التجاوز بوصفها دليل نقل، لا جزءاً من الادعاء الموقّع.

بهذا تبقى الطبقات واضحة: يثبت HTTP وصول البايتات، وتثبت إجابة OCSP ما قاله مجيب مخوّل ولأي فترة، ويثبت السجل المحلي سبب القرار، ويثبت سجل التطبيق الأثر. لا يحل مؤشر نجاح واحد محل هذه الوقائع.

المصادر