الخلاصة

  • قدّمت مجموعة عمل COSE المراجعة 21 من مسودة C509 في 24 سبتمبر 2026. كانت المراجعة 20 قد حازت موافقة IESG في يوليو، لكن الوثيقة لا تزال في طابور محرر RFC وليست RFC منشوراً.
  • تحدد الصياغة الجديدة تسلسل CBOR الذي يُوقّع، وتُلزم بتمثيل الرقم التسلسلي كسلسلة بايتات، ولا تجيز اختصار حقل الجهة المصدرة إلا عند تطابقه مع الموضوع بايتاً ببايت.
  • النوع 3 يعيد ترميز شهادة DER مع الاحتفاظ بتوقيعها الأصلي؛ أما النوع 2 فيوقّع تمثيل CBOR نفسه. كلا المسارين يحتاج إلى تحقق X.509 المعتاد من سلسلة الشهادات.

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

تضع مراجعة 24 سبتمبر حدّاً أوضح بين الكائن الكامل والمادة التي تُوقّع. تصف C509Certificate بأنها مصفوفة CBOR، وتصف عناصرها بأنها تسلسل، ثم تحدد أن مجموعة TBSCertificate من دون قيمة التوقيع الأخيرة هي الجزء المراد توقيعه. لا يشير ذلك إلى عيب أمني مكتشف أو هجوم واقع؛ إنما يجعل السؤال عن حدود البايتات قابلاً للاختبار بصورة أدق.

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

ويفصل المشروع بين نموذجَي توقيع كثيراً ما يُختزلان تحت كلمة «ضغط». النوع 3 يبدأ من شهادة DER موقّعة مسبقاً، ويتيح إعادة ترميز قابلة للعكس مع حمل توقيعها الأصلي؛ ويمكن إجراء الضغط في وظيفة موثوقة بعد إصدار الشهادة. النوع 2 يوقّع البنية الأصلية في CBOR، ما يعني أن مدقّقاً لا يفهم سوى DER لا يصبح متوافقاً معه تلقائياً. اشتراك النوعين في دلالات X.509 لا يعني اشتراك جميع المدقّقات الموجودة في قدرة قبول البايتات نفسها.

ولا ينبغي تحويل حالة الوثيقة إلى شهادة جاهزية. وافقت IESG على المراجعة 20 في 20 يوليو، ثم وصلت المراجعة 21 إلى طابور محرر RFC. يبيّن سجل Datatracker، في تاريخ هذه القراءة، أن المحرر ينتظر مدخلات المؤلفين وأن إجراء IANA ينتظرهم أيضاً. لا يوجد في هذا السجل إعلان نشر RFC جديد أو إحصاء لاعتماد C509 في الشبكات. أمثلة تقليص الحجم في المسودة توضح الإمكان، لا الانتشار.

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

المصادر