حملت الاستجابة مرساة ثقة، لكن المتلقي لم يكن ملزماً بقبولها

الخلاصة

• يشترط RFC 5276 التحقق من توقيع استجابة SCVP بمفتاح عام يثق به الطرف المعتمد، ويجيز له رفض مراسي الثقة المحمولة داخل الاستجابة واستخدام مراسٍ حصل عليها خارجها.
• سجل الدليل يثبت علاقة طويلة الأجل ببايتات شهادة أو مسار أو مادة إلغاء محددة؛ ولا يقرر وحده أن الموقّع مخوّل أو أن التطبيق ملزم بتنفيذ نتيجة.

وصلت استجابة أرشيفية متقنة. كان توقيع SCVP موجوداً، ومسار الشهادة محفوظاً، وسلسلة الطوابع الزمنية قابلة للتحقق. وداخل الاستجابة ظهرت مرساة ثقة تصلح للتحقق من طبقة داخلية في سجل الدليل. بقي سؤال واحد لا تستطيع الحزمة أن تجيب عنه بنفسها: هل يثق المتلقي بهذه المرساة أصلاً؟

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

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

الثقة تدخل قبل النتيجة

يعامل RFC 5280 مرساة الثقة كمدخل إلى خوارزمية التحقق من المسار. قد تعتمد تطبيقات مختلفة مراسي مختلفة، وقد تضيف قيوداً على المسارات المقبولة. المسار الصحيح تحت مرساة معينة لا يحمل تفويضاً ذاتياً لكل استعمال.

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

تأتي استجابة RFC 5276 بعد ذلك. قد تحمي توقيعها مراسي مرفقة وتسمح بالتحقق من طبقات ERS، لكنها لا تلغي اختيار الطرف المعتمد. وجود المرساة داخل رسالة موثقة يثبت أن الخادم أرسلها، لا أنها أصبحت مصدراً إلزامياً للثقة.

ينبغي لذلك أن يسجل النظام ثلاث حقائق منفصلة: هوية مفتاح توقيع خادم SCVP ومصدر الثقة فيه؛ المرساة التي استُخدمت فعلاً لمسار الشهادة؛ والمرساة المستخدمة للتحقق من طبقات سجل الدليل. دمجها في خانة «موثوق» يخفي اختلاف الوظائف.

كل دليل مرتبط بهدف محدد

يضيف RFC 5276 معرفات WantBack لطلب EvidenceRecord يغطي شهادة نهائية أو مساراً كاملاً أو مساراً جزئياً أو معلومات إلغاء. ولا يجوز طلب دليل لمسار ثم ترك المسار نفسه غائباً؛ يجب أن يظهر الطلبان والردان معاً.

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

يستخدم الطلب الجامع بنية EvidenceRecordWantBacks. يحدد targetWantBack نوع الرد المغطى، ويشترط المعيار تطابقاً واحداً لواحد مع بقية عناصر الرد. هذه ليست زينة بنيوية، بل وسيلة لمنع دليل صحيح عن عنصر من أن يُعرض كأنه يغطي عنصراً آخر.

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

غياب الدليل لا يساوي حكماً سلبياً

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

القيمة الفارغة تعني أن برهان الحفظ غير متاح. لا تعني أن الشهادة ملغاة. وبالعكس، نجاح التحقق من EvidenceRecord لا يجعل شهادة ملغاة صالحة. هناك محور لحالة الشهادة تحت السياسة، ومحور لتوافر دليل الحفظ وسلامته.

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

المسار الجزئي يوزع الحراسة

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

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

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

المعرفة اللاحقة تستطيع تغيير الماضي المقيم

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

لكن RFC 5055 يحذر من أن الحالة المعروفة وقت الاستعلام قد لا تكون أكمل ما سيُعرف لاحقاً. قد يصدر إشعار إلغاء بعد سنوات ويحدد invalidityDate يسبق زمن التحقق الأصلي. عندها تبقى الاستجابة الأولى بياناً أصيلاً عما كان معروفاً، لكنها لا تبقى كافية لقرار اليوم.

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

كما يحتاج العميل إلى فحص توقيع الاستجابة أو MAC ومطابقة nonce عندما يستخدمه. وإلا يستطيع مهاجم إعادة استجابة قديمة أو تعديلها. لا يحوّل التخزين الطويل اقتناءً ضعيفاً إلى اقتناء موثوق.

سجل الدليل يحتاج إلى صيانة

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

الدليل الطويل خدمة مستمرة، لا ختم مرة واحدة. يحتاج إلى مراقبة آخر طبقة قوية وموعد التجديد ومواد التحقق اللازمة للطبقات السابقة.

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

سجل قرار قابل لإعادة البناء

ينبغي أن يربط السجل بين الملف المؤرشف وهاشه وتوقيعه، وشهادة الموقّع، وزمن الاستعلام، وسياسة SCVP، والمراسي المختارة، وهوية الخادم وتوقيعه، وكل مادة أعادها، وEvidenceRecord الذي يغطيها، وتاريخ التجديد، والمعلومات اللاحقة التي غيّرت النتيجة، وترخيص التطبيق والنتيجة التشغيلية.

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

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