الخلاصة

  • يتيح draft-ietf-cose-hpke-27 نقل النص المشفّر خارج COSE_Encrypt أو COSE_Encrypt0، مع وضع nil في خانة ciphertext. ولا يشمل توقيع COSE أو MAC المضاف لاحقاً تلك البايتات المنفصلة.
  • يمكن لـ AEAD حماية سلامة النص المشفّر الخارجي، لكن نجاح الوسم لا يثبت وحده هوية المرسل العامة ولا صلاحية الأمر ولا تحقق أثره في النظام.
  • في 1 أكتوبر 2026 بقيت المراجعة 27 في حالة AD Evaluation::AD Followup لدى IESG. ووجود ثلاثة تطبيقات تحققت من الأمثلة لا يعني اعتماد سلسلة حيازة أي منتج فعلي.

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

ينص الإصدار 27 من مسودة COSE-HPKE بوضوح على أن استخدام نص مشفّر منفصل مع COSE_Encrypt أو COSE_Encrypt0 يعني أن حماية النزاهة اللاحقة عبر COSE_Sign أو COSE_Sign1 أو COSE_Mac أو COSE_Mac0 لا تغطي ذلك النص. ويجب على المنفذين ضمان سلامته بوسيلة أخرى.

القيمة nil تشير إلى مسار آخر للبيانات

يسمح RFC 9052 بفصل المحتوى عن بنية COSE. تُملأ الخانة الداخلية بـ nil، بينما يوفر التطبيق البايتات عبر قناة أخرى. يفيد ذلك في الملفات الكبيرة والتخزين الكائني، لكنه ينشئ وصلة جديدة يجب إثباتها.

في النمط المتكامل ينتج HPKE قيمة ct. وفق النص الخام للمراجعة، يمكن إدراجها في COSE_Encrypt0 أو نقلها منفصلة. وفي نمط تشفير المفتاح تشفّر الطبقة صفر المحتوى مرة واحدة بمفتاح CEK، ثم تحمي الطبقة الأولى هذا المفتاح لكل مستلم. ويعرض مصدر XML البنية نفسها.

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

الأدلة ليست ضوءاً أخضر واحداً

التوقيع أو MAC الخارجي يثبت ما دخل فعلياً في Sig_structure أو MAC_structure. لا تدخل البيانات المجاورة في الحساب لمجرد أن واجهة المستخدم تعرضها داخل البطاقة نفسها.

أما AEAD في الطبقة صفر فيستطيع حماية النص المشفّر المنفصل. فإذا نجح التحقق بالـ CEK والـ nonce والبيانات المرتبطة الصحيحة، أمكن كشف التعديل. غير أن هذا دليل سلامة تحت مفتاح متناظر، لا إعلان عام عن هوية المرسل.

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

الدليل ما يثبته ما لا يثبته
التوقيع/MAC الخارجي صحة البايتات المغطاة تحت مفتاح سلامة blob لم يدخل الحساب
AEAD سلامة النص المشفّر والبيانات المرتبطة تحت CEK هوية عامة للمرسل
HPKE Open نجاح المعالجة لمفتاح المستلم صلاحية المرسل للأمر
قرار الهوية ربط المفتاح بفاعل موثوق تفويض العملية الحالية
التفويض سماح السياسة بالفعل الآن وقوع التنفيذ
إيصال الأثر تغير الحالة الخارجية المصدر التشفيري ما لم يُربط به

بنية المستلم تربط الخوارزمية بسياقها المباشر

تُدخل Recipient_structure معرّف خوارزمية الطبقة الأدنى والرؤوس المحمية للمستلم في مدخل info الخاص بـ HPKE. والغاية هي منع خوارزمية تشفير المحتوى من الانفصال دلالياً عن الآلية التي تحمي CEK.

يجب ترميز هذه البنية بصورة حتمية وفق RFC 8949، لأن المرسل والمستلم يبنيانها كلٌ على حدة ولا تُنقل كما هي. يحل الترميز الحتمي اختلاف تمثيل البايتات، لكنه لا يحل ملكية المفتاح أو صلاحية القرار أو ثبات blob.

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

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

التشفير إلى مستلم لا يوثق المرسل تلقائياً

حدد RFC 9180 الإطار المعروف لـ HPKE. وتسعى المسودة اللاحقة النشطة إلى استبداله إذا اعتمدت، لكنها ما زالت عملاً جارياً. لذلك يجب تسجيل الإصدار والنمط ومجموعة KEM/KDF/AEAD، لا كلمة HPKE وحدها.

لا يوفر نمط Base مصادقة المرسل داخل KEM. ويمكن لتوقيع COSE أو MAC إضافة المصادقة، شرط فحص نطاقه الحقيقي. ويشرح RFC 9338 فرقاً قريباً: إثبات البيانات المشفّرة ليس إثباتاً لمعنى النص الصريح. فإذا كان المطلوب موافقة على المعنى، وجب بناء ذلك الدليل قصداً.

يحدد RFC 9053 خوارزميات COSE، وينسق سجل IANA لـ COSE وسجل HPKE الأرقام والمراجع. التسجيل لا يشهد بأن منتجاً رفض خوارزمية قديمة أو أدار تدوير المفتاح أو طبّق التفويض.

التقدم المعياري ليس شهادة تشغيل

يعرض Datatracker المراجعة 27 بوصفها وثيقة من مجموعة COSE تستهدف Proposed Standard، مقدمة إلى IESG وفي AD Evaluation::AD Followup في 1 أكتوبر 2026. ويسجل التاريخ صدور المراجعة في 12 سبتمبر. لم يكن لها رقم RFC بعد.

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

بيان تغطية لكل قرار

ينبغي حفظ بايتات COSE الكاملة؛ النوع والوسم؛ الرؤوس المحمية وغير المحمية؛ حالة الدمج أو الفصل؛ موقع blob غير القابل للتغيير وطوله وبصمته؛ بصمة مدخل التوقيع/MAC؛ خوارزمية AEAD وبصمة AAD ونتيجة الوسم؛ نمط HPKE والمجموعة؛ بصمات ek وRecipient_structure؛ أصل المعلومات الإضافية؛ مساحة اسم kid ونسخة المفتاح؛ نتيجة الفتح؛ بصمة النص داخل الحد الموثوق؛ قرار الهوية؛ التفويض؛ رقم التنفيذ؛ والأثر المرصود.

لا حاجة لتسجيل المفاتيح الخاصة أو كشف النص الصريح. تكفي البصمات والمراجع ذات النسخ وإيصالات القرار. ويجب حفظ الغياب كما هو: قد يكون outer_signature_covers_blob=false تصميماً سليماً إذا ثبتت حماية AEAD، لكنه لا يجوز أن يتحول إلى signed=true غامضة.

تدعم Minimum Initial Specification بياناً مشتركاً صغيراً مع بقاء سياسة العمل محلية. وتطلب Running-Code Primacy فحص البايتات الفعلية. وتكشف The Policy Mirror سلطة التخزين وحل المفاتيح. وتفصل Reality Layers بين البنية والبايتات والإثبات والهوية والإذن والأثر.

المصادر