الخلاصة

  • أتاح RFC 3029 لخدمة التحقق أن تنفذ بنجاح وتصدر شهادة DVC موقعة، مع بقاء نتيجة التحقق نفسها «غير صالحة»؛ فالتنفيذ وصحة المصدر وحالة الكائن حقائق منفصلة.
  • ربطت الشهادة الطلب أو البصمة والوقت والرقم التسلسلي والسياسة والحالة الجماعية والتفاصيل، وظل على التطبيق المتلقي أن يتحقق من الرد ويقرر كفايته.

توحي كلمة «شهادة» عادة بالموافقة. أما Data Validation Certificate في RFC 3029 فكانت سجلاً موقعاً لحكم أصدره خادم وفق شروط محددة. لم تكن طبقة تمنح الكائن الصلاحية. وكان الحكم السلبي منتجاً صحيحاً للخدمة، لا خللاً في الشهادة.

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

أربع خدمات لأربع دعاوى مختلفة

كانت cpd تصدق حيازة بيانات قُدمت فعلاً إلى الخادم. أما ccpd فتتلقى ملخصاً رقمياً فقط وتصدق الادعاء المرتبط به؛ ولا يعني ذلك أن الخادم رأى البايتات الأصلية. الفرق هو بين مشاهدة الكائن ومشاهدة معرف تشفيري له.

تتحقق vsd من المستندات الموقعة، فلا تكتفي بصحة العملية الرياضية، بل تنظر أيضاً في الشهادات وحالتها ومسارات الثقة والسياسة. وتتحقق vpkc من شهادة مفتاح عام أو أكثر في وقت محدد. يمكن للخادم استعمال CRL وOCSP والأدلة وخدمات DVCS أخرى، لكن RFC 3029 لم يقدمه بديلاً من CRL أو OCSP في البيئات المفتوحة الكبيرة.

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

التوقيع أحاط بحكم منظم

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

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

تفسر السياسة إمكان وصول خادمين إلى نتيجتين مختلفتين من دون كذب. قد يختاران جذور ثقة أو مصادر حالة أو عدداً مطلوباً من التواقيع بصورة مختلفة. لا تقول DVC إن الكائن صالح في كل مكان؛ بل تقول إن خادماً معيناً أعاد نتيجة معينة، في وقت معين، لطلب وبصمة وتحت سياسة معلومة.

النتيجة الجماعية لا تلغي التفاصيل

قد يرجع فشل مجموعة شهادات إلى عنصر واحد، وتكشف البنى الفردية أيها فشل. وفي مستند متعدد التواقيع لا يؤدي فشل توقيع واحد بالضرورة إلى فشل المستند كله؛ إن اكتفت السياسة بعدد كافٍ من التواقيع، أمكن إصدار grantedWithMods. والعكس ممكن أيضاً: قد تكون التواقيع الموجودة صحيحة كل على حدة لكنها لا تحقق العدد أو التركيبة المطلوبة. أما granted فمخصص لنجاح التحقق من جميع التواقيع.

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

الحكم السلبي الموقع ليس خطأً بلا سلطة

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

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

صدر RFC 3029 في فبراير 2001 بصفة Experimental، لا Internet Standard. تناول RFC 3379 ثم RFC 5055 لاحقاً متطلبات وبروتوكولاً آخرين للتحقق المفوض. لا تثبت هذه السلسلة انتشار DVCS. لكنها تبرز درساً ثابتاً: تفويض الحساب لا يلغي قرار الطرف الذي سيعتمد النتيجة.

المصادر

لم يكتب Lu Heng وثيقة RFC 3029 أو معايير PKIX المرتبطة بها ولم يقرها؛ وتستعمل مقالاته هنا كعدسات تحليلية معلنة.