الخلاصة

  • يعرّف RFC 9999 غلافاً ذاتي الوصف لنقل Evidence وAttestation Results وEndorsements وReference Values وAppraisal Policies في RATS عبر CBOR وJSON وJWT وCWT وX.509 وHTTP وMIME وCoAP.
  • تساعد أشكال Record وTag وCollection CMW على التعرف إلى المحتوى وتوجيهه وتجميعه، لكنها لا توفر بمفردها الأصالة أو السلامة أو السرية أو الحداثة أو التقييم الدلالي أو التفويض.
  • عندما تمثل Collection جهازاً مركباً أو متعدد الطبقات، يجب ربط عناصر Evidence ببعضها تشفيرياً؛ فصحة كل توقيع على حدة لا تثبت وحدة الجهاز أو العصر أو المعاملة.

وصل طلب إعادة خادم إلى شبكة الإنتاج بعد صيانة عاجلة. حمل الطلب Collection فيها ثلاثة أعضاء: دليل عن CPU، وآخر عن SmartNIC، وثالث عن GPU. عرف البرنامج الأنواع الثلاثة، وفك البنية الصحيحة، ونجحت التواقيع الداخلية. بدت النتيجة كأن الجهاز كله اجتاز الفحص.

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

نُشر RFC 9999 في يوليو 2026 ضمن Standards Track في IETF، وهو يعرّف Remote ATtestation procedureS Conceptual Message Wrapper أو CMW. يحل المعيار مشكلة حقيقية: رسائل التصديق البعيد متعددة الوظائف والصيغ وطرق التسلسل وبروتوكولات النقل. والغلاف المشترك يسمح للنواة البرمجية باستقبال تقنية جديدة وتمريرها إلى المعالج الملائم من دون إعادة تصميم البروتوكول كله.

هذه مكسب قابلية تشغيل بيني، لا حكم ثقة. يخبر CMW النظام بما وصل وكيف يوجّهه؛ ولا يخبره لماذا ينبغي أن يصدقه.

الأدوار تظل منفصلة داخل الغلاف

يفصل RFC 9334 بين ثلاثة أحكام. ينتج Attester الـEvidence. ويقيّم Verifier هذه الأدلة بالاستعانة بـEndorsements وReference Values وAppraisal Policy، ثم ينشئ Attestation Results. وبعد ذلك يطبق Relying Party سياسته الخاصة ليقرر دخول الشبكة أو إطلاق مفتاح أو قبول أمر.

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

يحمل Record CMW حقلاً للنوع type وقيمة غير شفافة value ومؤشراً اختيارياً ind. ويمكن للمؤشر أن يعلن Reference Values أو Endorsements أو Evidence أو Attestation Results أو Appraisal Policy. أما Tag CMW فيستخدم وسم CBOR مشتقاً من CoAP Content-Format وفق RFC 9277. وتضم Collection عناصر CMW ذات تسميات، ويمكن أن تحتوي Collections أخرى.

ينسق سجل IANA RATS Parameters مؤشرات الرسائل. ويعرّف RFC 9711 Entity Attestation Token، فيما يعرّف RFC 9782 أنواع الوسائط الخاصة بـEAT. وبهذا يستطيع النظام اختيار parser أو handler من دون تخمين.

لكن النوع عنوان معالجة لا شهادة صدق. إعلان Evidence يصف الدور المقصود للحمولة، ولا يثبت أهلية من وضع الإعلان أو صحة الـclaims. وتسجيل IANA يمنع تصادم المعرفات، لكنه لا يضمن أن المشغل يدعم الملف أو يقبل سياسته أو يثق بمصدره.

كلمة «موقّع» لا تكفي من دون نطاق

ينص RFC 9999 على أن CMW غلاف، لا صيغة أمنية. ولا تمنح Records أو Tags أو Collections بذاتها أصالة أو سلامة أو سرية.

قد تكون الحماية داخل الرسالة المفاهيمية. ويمكن تغليف CMW المبني بـCBOR ببنية COSE من RFC 9052، أو توقيع CMW المبني بـJSON بواسطة JWS من RFC 7515. وقد تحمي قناة آمنة النقل، بينما يقيّد challenge-response إعادة الاستخدام.

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

يقدم RFC 9781 مثالاً واضحاً. UCCS مجموعة claims غير محمية. وضعها داخل CMW يجعلها أسهل في التعرف والنقل، ولا يخلق الأصالة. ويمكن إضافة توقيع خارجي عند الحاجة. الخاصية الأمنية تأتي من فعل إضافي قابل للتحقق، لا من اسم الحاوية.

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

الخطر في العلاقة بين القطع

الخادم الحديث مركب. قد تنتج CPU وSmartNIC وGPU أدلتها من بيئات تصديق مختلفة. وقد يضم الموجه هيكلاً وبطاقات تحكم وخطوطاً مستقلة. وفي الإقلاع متعدد الطبقات تقيس طبقة ما الطبقة التالية قبل تسليمها التحكم.

تجمع Collection CMW هذه الصيغ المختلفة. إلا أن RFC 9999 يوجب، عند استخدامها لتمثيل جهاز مركب أو متعدد الطبقات واحد، ربط كل رسائل Evidence ببعضها تشفيرياً. ومن دون حماية للكائن كله أو روابط داخلية، يستطيع المهاجم استبدال دليل عنصر مخترق بدليل عنصر سليم من جهاز آخر.

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

وليست كل Collection ادعاءً عن جهاز واحد. يمكنها جمع Endorsements أو Reference Values أو نتائج تخص عدة أجهزة. ولا معنى لترتيب العناصر، كما أن التسميات فريدة فقط داخل المجموعة. لا تصبح gpu أو slot-2 هوية عالمية. يلزم collection type أو assembly profile يفسر التسمية، إلى جانب جرد مادي ومعرف جهاز وجيل طوبولوجيا.

الحاوية تحدد موضع العنصر. والـprofile يحدد معنى الموضع. والجرد التنفيذي يثبت أي قطعة تشغله الآن.

التداخل المتكرر يحتاج ميزانية

يمكن أن تحتوي Collection على Collection أخرى. تعبر هذه العودية عن الجهاز متعدد الطبقات، لكنها تزيد عمق parsing وعدد الأعضاء والبايتات وفك Base64 والعمليات التشفيرية والاستعلامات الخارجية.

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

ويحتاج النوع المجهول إلى نتيجة صريحة. يمكن لخدمة أرشفة حفظ كائن غير مفهوم. ولا يجوز لخدمة تفويض تجاهل عضو مجهول ثم إعلان تقييم الجهاز كله. «غير صالح» و«غير مدعوم» و«مفقود» و«اختياري وفق الـprofile» حالات مختلفة.

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

الدليل القديم قد يظل صحيح التوقيع

التصديق البعيد يتحدث عن حالة في وقت ذي صلة. وبعد تحديث firmware أو تبديل قطعة أو تغيير Reference Values، قد يبقى توقيع Evidence القديمة صحيحاً بينما تفقد قيمتها التشغيلية.

يعامل RFC 9334 الحداثة كضابط مستقل باستخدام الوقت المتزامن أو nonces أو epoch IDs. يستطيع CMW حمل الرسائل الداخلة في هذه الآليات، لكنه لا يثبت أن كل الأعضاء أجابوا التحدي نفسه. فإذا ارتبطت CPU بـnonce A وSmartNIC بـnonce B وGPU بطابع زمني فقط، فعلى assembly profile وسياسة Verifier أن تقررا إن كانت هذه معاملة واحدة.

يجب الاحتفاظ بالتحدي ومصدره والنافذة وافتراضات الساعة والـepoch والأعضاء المشمولين. «التوقيع صالح» ليس حكماً على الحداثة.

ثم يبقى التفويض. قد يقرر Verifier أن الجهاز يطابق baseline، لكن Relying Party يستطيع رفض الوصول إلى بيانات عميل أو توقيع إصدار. Attestation Result الصحيح لا يتحول تلقائياً إلى تصريح عام عند نقله إلى سياق آخر.

الإغلاق الكامل يثبت الأعضاء المتوقعين، والتحليل، والحماية، والربط، والحداثة، والتقييم، وتسليم النتيجة، وقرار الخدمة، والأثر الملاحظ.

النقل عبر X.509 قد يحول الإفصاح الخاص إلى سجل عام

يسمح RFC 9999 بحمل CMW في شهادات X.509 وطلبات الشهادات وCRLs. هذا يستفيد من قناة قائمة، لكنه قد يجعل تفاصيل مادية حساسة طويلة العمر وواسعة الانتشار.

قد يقبل طالب شهادة توقيع برمجيات أن يكشف لـCertification Authority طراز HSM ومستوى التصحيح، من دون أن يوافق على كشفهما لكل مستلم للشهادة. يحدد RFC 5280 الملف العام للشهادات والامتدادات، ولا ينشئ موافقة الإفصاح. ويوفر RFC 3647 إطار certificate policy وCPS. ويوصي RFC 9999 بأن توضح الممارسة متى تستطيع CA تضمين Evidence من طرف ثالث.

يجب حسم تقليل الـclaims والجمهور والاحتفاظ والـprofile وسلطة النشر قبل الإصدار. سحب الشهادة لا يستعيد المعلومات التي نُسخت بالفعل.

التنفيذ هو الذي يغلق الفجوة

يحوّل مبدأ Heng Lu بشأن أولوية running code السؤال إلى المسار المنفذ: أي parser وhandler عملا، وأي بايتات ومفاتيح تحققت، وكيف ثبت الربط والحداثة، وأي سياسة صنعت القرار، وما الفعل الذي حدث فعلاً.

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

أما طبقات الواقع فتفصل بين صحة بنية CMW، والحماية التشفيرية، والتقييم الدلالي، والأثر التشغيلي. لا يجوز لضوء أخضر واحد أن يمحو أربعة أحكام مختلفة.