الخلاصة

  • تقترح المراجعة 03 من مسودة يعمل عليها فريق LAMPS، والمنشورة في 14 سبتمبر، تحديث RFC 5652 ومنع id-data في الاستخدامات الجديدة لـ CMS SignedData.
  • يُحدَّد الاستخدام الجديد بموعد أول مواصفة تشرح إنشاء SignedData أو معالجته للتطبيق، ابتداءً من تاريخ نشر الوثيقة النهائية، لا بموعد كتابة البرنامج أو تشغيله.
  • تحصل الاستخدامات القائمة على إرشاد للانتقال والتحقق بدلاً من الحظر المطلق نفسه، لأن فرض تغيير شامل قد يقطع التوافق مع جهات إرسال مستخدمة بالفعل.
  • النص مسودة نشطة تستهدف صفة Best Current Practice؛ وليس RFC، ولا قاعدة نافذة، ولا دليلاً على استغلال ثغرة أو على إصابة منتج بعينه.

حدٌّ ينتظر تاريخَه

تضيف المراجعة 03 عبارة مهمة إلى رأس الوثيقة وملخصها. فإذا اعتُمدت، ستحدّث RFC 5652، وهي المواصفة الحالية لـ Cryptographic Message Syntax، بحيث لا يجوز للاستخدامات الجديدة لـ CMS SignedData اختيار نوع المحتوى id-data.

التعريف هو الذي يرسم النطاق. الاستخدام الجديد هو ما تحدده مواصفة، للمرة الأولى، من حيث كيفية بناء SignedData أو معالجته لتطبيق ما، على أن تكون تلك المواصفة منشورة في تاريخ نشر الوثيقة المستقبلية أو بعده. ولا يغيّر التصنيف كون المواصفة اللاحقة RFC أو كونها تسجل معرّف نوع محتوى لدى IANA. وما يسبق ذلك التاريخ استخدام قائم.

هذا خط رسمي واضح، لكنه لا يعمل بعد. تسجل صفحة Datatracker الوثيقة بوصفها Internet-Draft نشطة لفريق عمل، مع نية إصدارها كـ BCP. ويصف RFC 2026 مسودات الإنترنت بأنها وثائق عمل. تستطيع المراجعة توجيه النقاش الآن، لكنها لا تعدّل STD 70 بمجرد رفعها.

زمن المواصفة ليس زمن النشر التشغيلي

يكشف الفرق الرسمي بين المراجعتين عن ساعتين ينبغي ألا تُدمجا.

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

لا تقدم المسودة إحصاءً يربط تلك الحالات، ولا تزعم ذلك. تسرد ملاحقها عدداً من وثائق RFC التي تستخدم id-data وتناقش مدى انطباق المشكلة، لكن الإحالة إلى RFC ليست قياساً للقاعدة المثبتة. كما أن صفاً في سجل IANA يثبت المعرّف والمرجع، لا مسار الشفرة الذي يقبله، ولا ما إذا كان المستلم يفرض signedAttrs، ولا ما إذا كان مفتاح توقيع واحد يعبر بين بروتوكولين.

السلوك هو موضع المسألة الأمنية. يسمح RFC 5652 بغياب signedAttrs عندما يكون نوع المحتوى المغلف هو id-data. وتشرح المسودة كيف يمكن عندئذ التحقق من توقيع على بنية لم يقصد الموقّع صراحة توقيعها. لكنها تعرض حدود الانطباق أيضاً: بعض البروتوكولات تفرض السمات الموقعة؛ وتحقق المستلم على النحو الصحيح يمكن أن يمنع الهجوم؛ وبنية الرسالة قد تضيق الاحتمال؛ وثمة وسائل تخفيف أخرى. لذلك لا تعني كلمة «قائم» أن الاستخدام مصاب، مثلما لا تثبت كلمة «جديد» سلامة التنفيذ.

التوافق جزء من الحكم

تقول المراجعة 03 إن الاستخدام الجديد MUST NOT يستخدم id-data. وإذا كان المحتوى MIME، فينبغي SHOULD استخدام النوع المقترح mimeData ما لم يوجد مبرر لنوع مصمم لغرض أكثر تحديداً. وتطلب المسودة من IANA تخصيص معرّفات للوحدات وأنواع المحتوى، إلا أن القيم ما زالت TBD. ولا تحول سجلات SMI وأنواع المحتوى الداخلية لـ CMS الحالية مكاناً شاغراً في مسودة إلى تخصيص فعلي.

أما الاستخدام القائم فيسلك طريقاً آخر. حين تُحدَّث مواصفته، ينبغي التخلي عن id-data. وإذا أبقاه التحديث، تطلب المراجعة بيان السبب كي يستطيع المراجعون وزن المقايضة الأمنية. وقد لا يكون الامتداد المتوافق مع الإصدارات السابقة وقتاً مناسباً لفرض كسر؛ بينما قد تكون نسخة رئيسية جديدة أو تغيير غير متوافق مخطط له نافذة انتقال معقولة.

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

المفاتيح والمكتبات والتطبيقات تتقاسم سطح التحكم

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

كما تضع حداً لمسؤولية مكتبات CMS العامة. في الاستخدامات الجديدة يجب التحقق من نوع المحتوى المتوقع ومن وجود السمات المطلوبة. وإذا لم تنفذ المكتبة سياسة البروتوكول، فعليها إظهار نوع المحتوى المستلم إلى طبقة التطبيق حتى تتخذ القرار.

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

سجل انتقال، لا حكم جماعي

يمكن لسجل عام موجز أن يجعل الحد الزمني قابلاً للتدقيق. ويسجل لكل استخدام معروف لـ CMS SignedData: أول مواصفة وتاريخها؛ نوع المحتوى وحكم signedAttrs؛ فئة أدلة النشر من دون اختلاق أعداد؛ احتمال مشاركة المفاتيح بين بروتوكولات أو نسخ؛ أقرب فرصة منطقية لتغيير كاسر؛ سبب الاحتفاظ بـ id-data أو استبداله؛ ومالك المواصفة وموعد المراجعة وسجل التصحيحات.

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

يمكن لتاريخ النشر أن يبقى الخط الرسمي. أما السجل فيوفر الخريطة التشغيلية المحيطة به.

المصادر