الخلاصة

  • يجعل RFC 9995 ناتج الهاش نفسه payload في COSE، ويلزم بوضع payload_hash_alg في الرأس المحمي، مع إمكان حماية نوع الـpreimage وموقع اختياري له.
  • يمكن التحقق من التوقيع أو MAC من دون الأصل؛ وهذا يثبت نطاق الغلاف ضمن المفتاح وسياق التطبيق، لا توافر الكائن ولا سلامته أو حداثته أو معناه أو الإذن باستخدامه.
  • على النظام المعتمد أن يربط المفتاح بالهوية والغرض، ويسترجع ضمن حدود، ويحفظ البايتات الدقيقة ويعيد حساب الملخص، ثم يحلل ويقيّم ويصرّح بالفعل ويراقب أثره.

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

نشرت IETF RFC 9995 في يوليو 2026 ضمن Standards Track لتعريف COSE Hash Envelope. الفائدة مقصودة: لا يحتاج موقع التوقيع البعيد إلى استقبال كائن ضخم، ولا يحتاج المستهلك إلى نسخة أخرى إن كان يحتفظ بالأصل. خفض النقل لا يلغي العمل الباقي؛ بل يجعله ظاهراً إذا حافظ المشغّل على الأسماء الصحيحة.

الأصل والملخص والـpayload المنفصل

الـpreimage هو تسلسل البايتات الذي دخل فعلاً إلى دالة الهاش. الـdigest هو الناتج القصير، وهو payload الغلاف. وتسمح قواعد COSE العادية بفصل هذا الـpayload القصير نفسه عن البنية المتسلسلة وتقديمه إلى التحقق من الخارج.

إذن يوجد غيابان مختلفان. عدم حمل الأصل الكبير هو جوهر Hash Envelope. أما فصل الملخص الصغير فهو خيار نقل إضافي. إذا سجل النظام عبارة “تم توفير detached payload” فقط، فلن يعرف المدقق هل وصل الملخص أم الكائن الذي يفترض أن يمثله.

تحدد RFC 9052 بنى COSE. في COSE_Sign1 يغطي حساب التوقيع الرؤوس المحمية، والبيانات الخارجية الموثقة التي يختارها التطبيق، والـpayload الكامل المستخدم في Sig_structure. الرؤوس غير المحمية لا تدخل في النطاق نفسه. وفي Hash Envelope يدخل الملخص، لا الأصل الغائب.

لهذا يكون التحقق دون اتصال بالإنترنت نتيجة صحيحة ومحدودة. بعد الحصول على بايتات مرشحة، يلزم حكم ثانٍ: هل ينتج حسابها الملخص المحمي نفسه؟

ثلاثة أرقام تنسق العلاقة ولا تنقل الكائن

الوسم 258، payload_hash_alg، إلزامي في الرأس المحمي وممنوع في الرأس غير المحمي. يحدد خوارزمية الهاش التي أنتجت payload.

الوسم 259، preimage_content_type، اختياري ومحمي عند وجوده. يصف media type أو CoAP Content-Format للبايتات الأصلية. وهو ليس وسم COSE المعتاد content_type رقم 3؛ فهذا الأخير سيصف payload الحالي، أي الملخص. يحظر RFC 9995 الوسم 3 حتى لا يخلط المستهلك بين نوع الأصل ونوع قيمة الهاش.

الوسم 260، payload_location، سلسلة أو URI اختيارية ومحميّة تساعد على العثور على الـpreimage. الحماية تمنع تبديل الإشارة من دون كسر الغلاف. لكنها لا تضمن أن الوجهة متاحة أو بقيت تحت المالك نفسه أو تقدم البيانات نفسها أو يجوز للعميل الوصول إليها.

ينسق سجل COSE لدى IANA الأوسمة والمراجع. وتشرح RFC 8126 سياسات التسجيل. وجود رقم في سجل ليس شهادة تنفيذ أو مطابقة أو قرار قبول محلي.

تعطي RFC 8610 لغة CDDL لوصف الشكل. تستطيع القواعد كشف حقل ناقص أو نوع خاطئ، ولا تستطيع إثبات المصدر أو السلطة. وتعطي RFC 7252 فضاء CoAP Content-Format الذي قد يستخدمه الوسم 259؛ اختيار parser لا يعني أن البايتات صحيحة أو آمنة أو مناسبة.

صحة التوقيع لا تعرّف صاحب القرار

التوقيع الصالح يثبت علاقة بين المدخلات المحمية والمفتاح والخوارزمية التي قبلها المتحقق. ويثبت MAC علاقة مماثلة داخل سياق السر المشترك. لكنه لا ينطق باسم صاحب المفتاح ولا يحدد صلاحياته.

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

تستطيع external authenticated data ربط سياق مثل البيئة أو الإصدار إذا عرّف profile البايتات الدقيقة وبناها الطرفان بالطريقة نفسها. السياق الفارغ لا يكتسب معنى بمجرد نجاح التوقيع.

تقدم RFC 9421 مقارنة مفيدة: تختار مكونات HTTP لتوقيعها وتحتاج إلى profile لتفسير النتيجة. Hash Envelope لا يوقع طلب HTTP ولا يأذن بزيارة الموقع. الدرس المشترك هو ألا تتوسع سلطة التوقيع خارج عناصره وغرضه المحددين.

يجب أن يفصل السجل بين قبول البنية، نجاح التشفير، ربط المفتاح، صلاحية الهوية، الغرض المأذون وتطابق السياق.

الموقع الموقّع ليس أمراً للتنزيل

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

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

تميز RFC 9110 بين resource وrepresentation وcontent coding والموقع وإعادة التوجيه في HTTP. لذلك تحدد سياسة التنزيل schemes وorigins وعدد redirects وDNS/TLS والاعتمادات والوقت والحجم ونسبة التوسع وعزل الشبكة، وتسجل الوجهة النهائية والتحويلات.

تفصل RFC 6920 الاسم القائم على الهاش عن آلية العثور على المورد. يمكن لعدة mirrors أن تقدم البايتات نفسها، ويمكن للموقع نفسه أن يتغير. الإشارة تجلب مرشحاً؛ الملخص يحكم على تطابقه بعد الوصول.

المطابقة تحتاج إلى عقد بايتات

بعد الاسترجاع، يطبق المتحقق خوارزمية الوسم 258 على المرشح ويقارن الناتج بـpayload. لا يكفي اسم الملف أو رقم النسخة أو مفتاح التخزين.

توضح RFC 9530 الفرق بين digest لمحتوى HTTP وdigest لبيانات representation المختارة. يمكن لـcontent coding أن يعطي مورداً مجرداً أكثر من تسلسل بايتات. ولا تمنح حقول Digest وحدها مصادقة أو تفويضاً أو خصوصية.

يجب أن يحدد profile ما الذي هُش: الملف المضغوط كما خُزن، أم المحتوى بعد فك الترميز، أم serialization canonical، أم تدفق آخر. تحليل JSON أو CBOR ثم إعادة كتابته قد يغير الترتيب والمسافات والأرقام. تغيير نهايات الأسطر أو فك الضغط تلقائياً يغير الأصل.

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

المعنى يأتي بعد المساواة

يمكن لـSBOM مطابق أن يفشل في parser. ويمكن أن ينجح parser ويفشل schema. وقد تكون البنية صحيحة لكنها لنسخة أخرى، أو للنسخة الصحيحة مع dependencies ناقصة، أو كاملة مع مكون تحظره السياسة. نوع المحتوى يختار أداة القراءة ولا يصدر الحكم.

البيانات القديمة تستمر في مطابقة hash قديم بدقة. لا يضع RFC 9995 قاعدة موحدة للfreshness؛ على التطبيق ربط الزمن والإصدار وaudience والإلغاء والغرض.

يغطي المستند COSE_Sign وSign1 وMac وMac0، ويترك Encrypt وEncrypt0 خارج النطاق. لا يوفر السرية ولا يحدد ترتيب الهاش والتشفير في تصميم مستقبلي.

حتى الخوارزميات تحتاج إلى قرار مستمر. تعرف RFC 9053 خوارزميات COSE وفحوص المعلمات. ويطلب RFC 9995 ألا تضعف مجموعة الهاش والتوقيع أو MAC قوة payload hash. تشرح RFC 7696 أن agility عملية: يصدر المنتج البديل، ويدعم المستهلك فترة تداخل، وتحدد السياسة تاريخ الرفض وتعالج الأرشيف. القدرة على قراءة identifier ليست إذناً دائماً باستخدامه.

سلسلة التنفيذ هي الدليل

ينقل مبدأ أولوية running code عند Heng Lu البرهان إلى المسار المنفذ: بايتات الأصل، digest، الغلاف، الخوارزميات، المفتاح، الهوية والغرض، قرار الاسترجاع، مسار النقل، إعادة الحساب، المقارنة، parser، التقييم، تفويض الفعل والأثر. عبارة “يدعم RFC 9995” لا تكفي.

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

ويمنع فصل طبقات الواقع دمج parse والتشفير والهوية والحصول والمساواة والمعنى والتفويض والأثر في كلمة “verified”. يمكن لكل طبقة أن تنجح وتفشل التالية.

تثبت المصادر حدود بروتوكول وفكر تحريري، لا معدل تبنٍ أو أداء أو سلوك منتج. مشهد SBOM مثال تفسيري مستند إلى مثال SPDX في المواصفة، لا ادعاء عن نشر حقيقي.