الخلاصة

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

التكرار يقلّل الكلفة ولا ينشئ حقيقة جديدة

إنشاء رد موقّع جديد لكل طلب لا يتناسب بسهولة مع بيئة تضم ملايين الشهادات. لذلك يستبدل RFC 9919 سلفه RFC 5019 ويعتمد الردود المعدة مسبقاً، والرسائل الأخف، وطلبات GET القصيرة، وطبقات التخزين المؤقت.

ينتج عن ذلك معنيان للحداثة. يقرر HTTP هل يمكن إعادة تقديم نسخة مخزنة ومتى ينبغي تجديدها. ويقرر OCSP هل لا يزال بيان الحالة الصادر عن جهة مخوّلة داخل نافذته الموقّعة. تساعد Expires وETag وCache-Control في المهمة الأولى، لكنها ليست جزءاً من توقيع OCSP.

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

ثلاثة أزمنة وساعة تقارنها

يمثل thisUpdate الوقت الذي كانت فيه الحالة المعلنة معروفة بالصحة لدى المستجيب. ويحدد nextUpdate الوقت الذي ستتوافر عنده، أو قبله، معلومات أحدث. أما producedAt فهو وقت توقيع الرد. قد تتقارب القيم في رد معد مسبقاً، لكن وظائفها لا تتطابق.

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

الساعة المتقدمة ترفض رداً صالحاً قبل أوانه فتسبب خللاً في التوافر. والساعة المتأخرة تقبل good منتهية بينما قد يقول رد أحدث revoked. قد يكون التوقيع سليماً في الحالتين؛ سلامة البايتات لا تصحح وقت المقارنة.

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

max-age يوزع التجديد وnextUpdate يغلق الدليل

يضع RFC 9919 قيمة max-age بعد thisUpdate وقبل nextUpdate. يبدأ العملاء التجديد قبل نهاية النافذة، ويجهز المستجيب رداً جديداً قبل نقطة التجديد. فلا تعود كل الأجهزة في الثانية نفسها لشهادة شائعة.

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

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

successful ليست good وgood ليست صلاحية كاملة

تشير successful في المستوى الأعلى إلى أن بنية OCSP تملك سجلات موثوقة تمكنها من الرد. أما نتيجة الشهادة الواحدة فهي good أو revoked أو unknown. الخلط بين المستويين يحول نجاح الصيغة إلى حكم إيجابي على الشهادة.

ويحد RFC 6960 معنى good: في الحد الأدنى لا توجد شهادة تحمل الرقم التسلسلي المطلوب وتقع ضمن فترة صلاحيتها وقد أُبطلت. لا يضمن ذلك بالضرورة أن الشهادة أُصدرت أصلاً، ولا أن الرد أُنتج أثناء فترة صلاحيتها. ويبقى مسار X.509 والاسم والغرض والتفويض المحلي فحوصاً مستقلة.

قبل الاستخدام، يثبت العميل أن الرد يخص CertID المطلوب، وأن التوقيع صحيح، وأن الموقّع مخوّل من جهة التصديق المعنية. يحتفظ الإيصال القابل للمراجعة بمعرف الهدف، وبصمة الرد، والموقّع وسلسلة سلطته، والخوارزمية، والحالة، وproducedAt وthisUpdate وnextUpdate، ووقت المقارنة والانحراف والهامش وnonce. ويسجل بصورة منفصلة age وmax-age وExpires وETag والتجديد وتجاوز الوسيط. قرار التطبيق وأثره يأتيان لاحقاً.

يفرض RFC 9919 أيضاً SHA-256 لتجزئة اسم المُصدر ومفتاحه في CertID. وقد يستخدم عملاء RFC 5019 القدامى SHA-1 مؤقتاً، لكن عليهم الانتقال. عددهم إشارة إلى عبء التوافق، وليس دليلاً على صحة حداثة الرد.

المصادر