تنتهي الشهادة عام 9999، لكن ربطها بالمستند قد يبقى بلا تحقق

الخلاصة

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

تشير قيمة notAfter إلى آخر ثانية من عام 9999. ويقول noRevAvail إن معلومات الإلغاء غير متاحة. ويحتوي signedDocumentBinding على تجزئة مخصصة لمستند واحد. أما التوقيع المعتاد فينجح.

أي من هذه الوقائع يثبت أن التطبيق فحص الربط؟ لا شيء منها.

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

الوثيقة Internet-Draft نشط من فريق LAMPS ضمن مسار IETF ومقصود بها Proposed Standard. تحمل المراجعة 02 تاريخ 1 يوليو 2026 وتنتهي في 2 يناير 2027، ويعرضها Datatracker بوصفها وثيقة فريق وحالة IESG هي I-D Exists. ليست RFC، ولا دليلاً على أن سلطة ما تصدرها فعلاً أو أن مفتاحاً أُتلف أو أن برنامجاً يفحص الربط أو أن الأرشيف سيظل قابلاً للتحقق.

شهادة واحدة تحمل ادعاءات من أنواع مختلفة

يسمى الامتداد signedDocumentBinding. تضم قيمته ASN.1 الحقول dataTbsHash وhashAlg وbindingType الاختياري. تعرّف التجزئة البيانات المراد توقيعها، بينما يحدد نوع الربط كيف اشتُقت سلسلة البايتات من صيغة المستند المحيطة.

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

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

قد ينجح التوقيع من دون فحص الربط

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

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

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

نوع الربط هو الذي يحدد البايتات

عند غياب bindingType، تُجزأ المدخلات الدقيقة لخوارزمية التوقيع، مثل SignedInfo في XML أو SignedAttributes المرمزة بـDER في CMS. تظهر المشكلة إذا احتوت مدخلات التوقيع على الشهادة نفسها أو على تجزئة لها: قيمة dataTbsHash داخل الشهادة، فيصبح حساب كل منهما معتمداً على الآخر. تحظر المراجعة 02 الربط الافتراضي في هذه الحالات الدائرية وتضع استثناءات خاصة بكل صيغة.

في CAdES تكون المدخلات SignerInfo بصيغة DER بعد إزالة SigningCertificate وSigningCertificateV2. وفي XAdES تكون SignedInfo بعد canonicalization وحذف مراجع نوع SignedProperties مع إبقاء سائر الأحرف والمسافات ونهايات الأسطر. أما JWS وCOSE فيربطان payload وحده ويستبعدان الرؤوس المحمية وغير المحمية.

وبذلك قد ينتج المستند المرئي نفسه قيماً مختلفة لـdataTbsHash. كما أن تطابق payload في JWS لا يثبت تطابق الرأس المحمي أو معرف المفتاح أو الخوارزمية أو مرجع الشهادة؛ تبقى تلك العناصر ضمن تحقق JWS العادي وسياسة التطبيق. يجب حفظ الصيغة والمعرف وقاعدة التحويل أو الاستبعاد وإصدار التنفيذ وتجزئة البايتات المعاد بناؤها.

غياب الإلغاء ليس دليلاً على إتلاف المفتاح

يوصي المشروع بأن تكون notAfter هي 99991231235959Z، وبامتداد id-ce-noRevAvail الوارد في RFC 9608. الأول يعني عدم وجود انتهاء محدد عملياً، والثاني أن معلومات الإلغاء غير متاحة لهذه الشهادة. لا يثبت أي منهما سبب عدم الحاجة إلى الإلغاء.

الحجة تعتمد على التشغيل: إذا عاش المفتاح فترة قصيرة، ووقع مرة واحدة، ثم أُتلف بالفعل، فلن ينبغي لحادث إلغاء لاحق أن يغيّر صلاحية توقيع سبق إنشاؤه. يقل سطح التعرض مقارنة بمفتاح دائم، لكن المخاطر تنتقل إلى صحة سجل الإنشاء. هل كان المفتاح جديداً؟ هل وُجد طلب واحد مصرح به؟ هل احتفظت نسخة احتياطية أو سجل أو crash dump أو قناة تكرار HSM أو retry بنسخة؟ هل تم الإتلاف قبل أي اختراق؟

لا يجيب noRevAvail عن ذلك. إنه يخبر المدقق ألا ينتظر CRL أو OCSP. ويجب التمييز بين «لا إلغاء بحكم التصميم» و«تعذر الوصول إلى خدمة الإلغاء» و«ملف شهادة غير معروف».

وقت الإصدار يمنح سلطة التصديق دوراً زمنياً

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

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

عام 9999 لا يجعل سلطة التصديق خالدة

تضع الوثيقة حداً ضرورياً للوعد. يظل التحقق مقيداً بالقدرة على الوثوق بسلطة الإصدار. تفترض المعاينة الأولى أنها تتم خلال صلاحية شهادة السلطة. لاحقاً قد يلزم الاحتفاظ بمفتاح السلطة كـtrust anchor محلي، أو استخدام cross-certification، أو استرجاع شهادات مجددة، أو تطبيق وسيلة أخرى. كيفية إنشاء تلك الثقة بعد انتهاء شهادة السلطة خارج نطاق المشروع.

إذن إزالة انتهاء شهادة الطرف النهائي لا تحفظ المسار إلى 9999. تتقادم الخوارزميات، وتتغير trust stores، وتُستبدل السياسات، وتغلق السلطات أو تغير مفاتيحها، وتهاجر الأرشيفات، ويختفي البرنامج. يجب أن تبقى البايتات الأصلية والمسار والسياسة وأدلة الزمن والتحقق وتاريخ trust anchors قابلة للاسترجاع.

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