الخلاصة

  • أُعلن في 5 سبتمبر 2026 عن draft-templeman-scitt-framing-space-00 بوصفه Internet-Draft فردياً من النوع Informational. ليس RFC ولا موقف إجماع من IETF ولا اقتراحاً لنص ملزم.
  • ولّدت التجربة 64 تسلسلاً مختلفاً و64 قيمة data-hash مختلفة من ست حريات ثنائية في تأطير CBOR. قبل decoder كل العينات، وأنتجت جميعها Sig_structure واحداً، فظل التوقيع نفسه صالحاً.
  • أعادت عملية القراءة ثم الترميز 31 عينة بصمت إلى الصيغة المعيارية A. إذا احتفظت الخدمة بالناتج المعاد ترميزه فقط، فقد تفقد البايتات الوحيدة القادرة على إعادة إنتاج المعرّف الذي أعلنته.

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

ليس السبب أن المعنى تغير، بل أن النظام احتفظ بما كان سيكتبه هو، لا بما استلمه.

حوّل مشروع Nicholas Templeman هذا الفصل إلى قياس قابل للتكرار. يسجل إعلان Internet-Drafts في 5 سبتمبر نشر الوثيقة. وهي تحد نطاقها بدقة: تقرير قياس ووصفة إعادة إنتاج وإشارة إلى عمل سابق، بلا متطلبات أو صياغة مقترحة. لذلك لا يجوز عرضها كمعيار أو قرار مؤسسي.

ما يراه التوقيع أصغر مما يراه السلك

يعرّف RFC 9052 بنية Sig_structure التي تدخل في إنشاء توقيع COSE والتحقق منه. في COSE_Sign1 تشمل السياق والخصائص المحمية والبيانات الخارجية الموثقة وpayload. ولا تشمل كل اختيار تمثيلي في غلاف CBOR الخارجي.

أما RFC 8949 فيسمح بأكثر من serialization لبعض قيم نموذج CBOR. قد يكون طول array أو map محدداً أو غير محدد، وقد تُرسل byte string كاملة أو مجزأة، وقد يقبل profile وجود tag أو غيابه. تستعيد المكتبة القيمة نفسها، لكن البايتات العابرة للشبكة تختلف.

بدأ القياس بالعنصر A، وطوله 165 octet. غُيّر وجود tag 18، وطريقة طول array الخارجي وmap الخاص بالـheader غير المحمي، ثم طريقة إرسال byte strings الخاصة بالـheader المحمي وpayload والتوقيع: كاملة أو chunks.

نتجت 64 تركيبة تراوح طولها بين 164 و170 octet. لم يرفض cbor2 6.1.3 أياً منها. وأعادت جميعها بناء Sig_structure واحد بطول 109 octet، فنجح التوقيع نفسه في كل مرة.

لكن حساب SHA-256 على البايتات المرسلة أعطى 64 data-hash مختلفاً بلا collision. هذا ليس كسراً للتشفير؛ فالمدخلات مختلفة للتجزئة ومتطابقة للتوقيع. الخلل يبدأ حين تختصر لوحة واحدة الحكمين في كلمة «صالح».

الرقم 64 بداية الفئة لا نهايتها

لم تغيّر التجربة عرض تمثيل integers ولا ترتيب مفاتيح map. ومن ثم لا تدّعي إحصاء كل تأطير ممكن. أهميتها أن ست حريات مستقلة فقط تكفي لإنشاء فضاء مركب كبير.

حظر شكل معروف واحد لا يغلق هذا الفضاء. منع غياب tag يترك خيارات الطول والتجزئة. وكل محور جديد يضاعف مجموعة التركيبات. المطلوب ليس قائمة متنامية من الأمثلة الممنوعة، بل تعريف واضح للبايتات التي تمثل preimage.

ينشر سجل framing-space النتائج وطريقة إنتاج العينات، ويوفر data-hash vector بايتات البداية. كما تذكر الوثيقة بيئة التنفيذ وإعادة حساب مستقلة لمحور واحد على منصة وقارئ مختلفين ومن دون مكتبة COSE.

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

التطبيع الصامت قد يمحو سلسلة الإثبات

عادت 31 من أصل 64 عينة إلى بايتات A بعد decode ثم re-encode، من دون خطأ. ما يبدو تنظيفاً عادياً للبيانات يصبح تغييراً جوهرياً عندما يكون المعرّف معرفاً بأنه تجزئة «ما أُرسل».

إذا أعادت واجهة الاستقبال قيمة data-hash إلى العميل ثم مررت القيمة المفككة فقط إلى queue، فقد لا تحمل الطبقات التالية الأصل أبداً. تخزن قاعدة البيانات تمثيلها المفضل. وعند إعادة الحساب تحصل الخدمة على تجزئة ما أنتجته، لا ما قبلته.

تتوسع النتيجة إذا كان data-hash مفتاح lookup أو deduplication أو registration أو receipt أو موضوع attestation لاحقة. قد يظهر البيان نفسه كسجلين أو يبدو غائباً، مع أن الطرفين يوافقان على صحة توقيعه. ومن يستطيع التأثير في framing قد يغير موضع السجل العملي بلا تغيير payload أو تزوير التوقيع.

يجب بناء نقطة الحفظ قبل parser. تُخزن بايتات request كاملةً كجسم غير قابل للتغيير، وتُحسب التجزئة عليها، ويُسجل مصدرها ووقتها وطولها والـbyte production المسماة التي يغطيها المعرّف. تُربط القيمة المفككة والصيغة المعيارية كنسخ مشتقة ولا تحلان محل الأصل.

يمكن للبروتوكول بدلاً من ذلك أن يختار deterministic encoding واحداً ويرفض غيره. يقدم القسم 4.2 من RFC 8949 أساساً لذلك. لكن إصدار encoder لصيغة مفضلة لا يعني أن decoder فرضها على الإدخال.

يختار مشروع as-transmitted، السابق لهذه القياسات، حدود البايتات الدقيقة: لا canonicalization، مع selector يشير إلى تسلسل مسمى في صيغة الحاوية. وهو أيضاً مشروع فردي. القياس اللاحق يوضح فائدة الدقة ولا يمنحه صفة معيارية.

سلامة التوقيع لا تمنح سلطة الاستخدام

يفصل RFC 9943 في معمارية SCITT بين Signed Statement وTransparency Service وReceipt والتقييم اللاحق. وتبين مسودتا SCITT Reference APIs وCCF receipt profile لماذا يمكن أن يصبح data-hash إحداثية فعلية للتسجيل والاسترجاع.

لكن كل دليل يتحدث ضمن حدوده. البايتات الخام تثبت ما تسلمه component. التوقيع الصالح يثبت سلامة Sig_structure تحت key؛ وعلى التطبيق التحقق من هوية صاحب المفتاح وصلاحيته. يثبت receipt قبول سجل وفق قواعد خدمة، ولا يثبت صدق المحتوى أو حداثته أو ملاءمته لقرار.

مبدأ Heng Lu في تقديم الواقع على الدفاع المؤسسي يمنع اختراع خصم: قد يعمل decoder المتسامح وencoder المعياري كما صُمما. الفشل بنيوي حين يُعامل ناتجاهما كالدليل نفسه.

وتنقل أولوية الكود العامل الاختبار عبر gateway وqueue وdatabase وAPI الفعلية. أما التمييز بين القدرة التقنية والسلطة فيمنع قدرة المكتبة على إعادة الترميز من التحول إلى حق في إعادة تسمية الدليل المنشور.

ليست canonicalization خطأً دائماً، وليست بايتات السلك هويةً مثالية دائماً. الخطأ هو إعلان أحدهما ثم حذف المادة التي تسمح بإعادة إنتاجه.

Sources