الخلاصة

  • نشرت مسودة «سجل الشهادة» الفردية مراجعتها 01 في 5 سبتمبر، وصححت وصفاً للمسح، وحددت حساب البصمة، وأضافت حدوداً واضحة لحالة التطبيق.
  • تجمع المستويات الأربعة بين صلاحية بنية السجل، وشرح الاعتقادات، وضبط الأفعال ذات العواقب، وإمكان التحقق من سلامة السجل؛ لكن مصدراً لا ينفذ أفعالاً يمكنه اجتياز TR-3 ثم بلوغ TR-4.
  • تميز المراجعة بين اختبارات يستطيع القارئ حسمها من السجل وادعاءات لا تزال على عهدة المصدر، مثل منشأ تصنيف الخطر أو هوية الموافق.
  • يربط ختم RFC 3161 بصمة بوقت وبجهة خارجية، لكنه لا يثبت صحة الشهادة أو اكتمالها أو أنها النسخة الوحيدة التي أنشأها المصدر.
  • ينبغي للمشتري أو المدقق طلب مصفوفة إثبات تعرض النطاق ونتيجة كل مستوى والاختبارات المتحققة والمُقَرّ بها ونظام السلامة وهوية أداة التحقق، لا شارة TR-4 مجردة.

عندما تصحح الوثيقة شهادتها

يسجل إعلان IETF حدثاً مؤسسياً محدوداً: إتاحة مسودة إنترنت من 18 صفحة في 5 سبتمبر. وتوضح صفحة Datatracker حدود هذا الحدث. الوثيقة مسودة فردية نشطة، وليست معياراً أو عملاً معتمداً من IETF. لا مسار RFC لها، ولا مدير منطقة مسؤول عنها، ولا مكانة رسمية. أما وصفها المقصود بأنه «معلوماتي» فهو نية الكاتب لا وضعاً حصلت عليه.

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

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

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

تحدد المراجعة 01 الآن SHA-256 على مجموعة مرتبة من المدخلات المشمولة، وJSON مضغوطاً، وترتيب المفاتيح بحسب نقاط ترميز Unicode، وحذف التعليقات التي تبدأ بشرطة سفلية، وترميز UTF-8، والفصل بـ LF من دون LF أخيرة، وحدود الأعداد التي قد تختلف طريقة تمثيلها. كما يعيد المدقق المرجعي الحساب. بذلك يصبح ادعاء السلامة قابلاً للاعتراض محلياً: يستطيع طرف آخر إعادة العملية على البايتات نفسها.

السلم الواحد يقيس أسئلة مختلفة

يسجل التنسيق مدخلات للنطاق والاعتقاد والدليل والتعارض والقرار والموافقة والسلامة. يختبر TR-1 إمكان التحليل والإصدار والأنواع والحقول المطلوبة وتفرد المعرفات وترتيب أوقات الكتابة واتساق النطاق. ويطلب TR-2 أن يسمي كل اعتقاد أدلته، حتى إن كانت القائمة فارغة لتعلن اعتقاداً بلا سند، وأن تبقى أطراف التعارض وأي تسوية لاحقة ظاهرة.

ينتقل TR-3 إلى الأفعال ذات العواقب. يجب إسناد تصنيف الخطر إلى مصدر خارج مخرجات النموذج المقترح، ولا يجوز تسجيل قرار مرفوض على أنه نُفذ. ويحتاج الفعل عالي الخطر المنفذ إلى موافقة تحمل اسم إنسان، ومصدر هوية خارج نص النموذج، وفصلاً بين الموافق والمقترح.

أما TR-4 فيسأل عن سلامة السجل: هل المدخلات التي قيل إنها مشمولة موجودة، وهل تعاد البصمة إلى القيمة نفسها، وهل يربط مرساة خارجية البصمة المعلنة؟ لكل من هذه الخصائص فائدة، لكنها ليست خاصية واحدة.

تعترف المسودة بأن ترتيبها التراكمي يخلط ضبط الأفعال بإثبات عدم تغير السجل. وتظهر النتيجة بوضوح في الإصدار 0.2: يستطيع المصدر إعلان acts:false. وإذا لم يحتو سجله على قرارات، فإنه يفي بـ TR-3 لأنه لا يملك فعلاً ليضبطه، ثم يمكنه الوصول إلى TR-4. الصياغة الدقيقة هي «TR-4، سجل فقط». حذف العبارة الأخيرة يحول نتيجة مقيدة بالنطاق إلى ضمان عام.

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

النطاق نفسه شهادة

مدخل scope يحل مشكلة حقيقية للمدقق، لكنه إعلان ذاتي. يستطيع نظام ينفذ أفعالاً أن يقول إنه لا يفعل، وأن يتجنب متطلبات القرار. إذا ترك قراراً في السجل ظهر التناقض وفشل TR-1. أما إذا حذف مسار التنفيذ كله، فلا يستطيع السجل وحده إثبات كذب الإعلان.

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

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

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

داخل المستوى الواحد حقائق قابلة للتحقق وإقرارات

تقدم المراجعة 01 تمييزاً أهم من الرقم الترتيبي. الاختبار المتحقق يستطيع القارئ حسمه من السجل: هل مدخل الدليل المشار إليه موجود؟ هل بقي طرفا التعارض؟ هل تجنب النظام تنفيذ قرار مرفوض؟ هل تطابق البصمة البايتات المحددة؟ وهل وقعت خدمة الوقت البصمة نفسها؟

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

لهذا قد يصل سجلان إلى TR-4 بخليطين مختلفين تماماً. أحدهما يمر أساساً بحسابات يعيدها أي قارئ على بايتات محفوظة. والآخر يعتمد في نقاط حاسمة على وصف المصدر لنفسه. الرقم الواحد يمحو تركيب الدليل.

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

يوفر RFC 8785 سياقاً مفيداً لتوحيد JSON، بينما تضع المسودة قاعدة خاصة واضحة للمدخلات المشمولة. وتوضح بنى الشفافية في RFC 9162 ومسودة معمارية SCITT كيف يمكن وضع الأدلة في سجل لا يسيطر عليه مصدر واحد. لا يستطيع أي منها أن يثبت بأثر رجعي أن النطاق المعلن كان كاملاً أو أن اعتقاداً كان صحيحاً.

استبدال الشارة بمصفوفة إثبات

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

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

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

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

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

المصادر

  1. إعلان IETF للمراجعة 01
  2. حالة المسودة في IETF Datatracker
  3. سجل الشهادة، المراجعة 01
  4. سجل الشهادة، المراجعة 00
  5. الفرق الرسمي بين المراجعتين
  6. مستودع Machine Testimony
  7. دليل مسح المطابقة
  8. RFC 3161، بروتوكول الختم الزمني
  9. RFC 8785، توحيد JSON
  10. RFC 9162، شفافية الشهادات 2.0
  11. معمارية SCITT، المراجعة 22
  12. Heng Lu عن أولوية الكود الجاري