Summary

  • عرّفت RFC 2440 وسوماً كثيرة لحزم OpenPGP، لكنها لم تضع إجراءً عادياً لإضافة وسوم دائمة جديدة، لأن التفاعل بين الخصائص قد يقلل أمن البروتوكول كله.
  • وجود أرقام متاحة في الترويسة لا يعني الإذن باستخدامها. بقيت القيم 60 إلى 63 للاستخدام الخاص أو التجريبي، وأُحيلت طلبات القيم الجديدة إلى مديري مجال الأمن في IESG أو إلى مجموعة عمل مناسبة في IETF.
  • كانت البرمجيات تتجاهل عادةً الحقول الفرعية غير المعروفة في التوقيع. أتاح بتّ الحرج للموقّع أن يفضّل الخطأ على إسقاط معنى الخاصية بصمت. والتعرّف لا يساوي التنفيذ، كما أن البيانات الوصفية غير المجزّأة ليست دليلاً حاسماً.
  • حوّلت الإصدارات اللاحقة هذا التحفّظ إلى سجلات وإجراءات مراجعة أوضح. لكن تخصيص رقم أو نجاح التحليل أو صحة التوقيع لا يثبت سلامة التركيب أو النشر الفعلي.

الخانة الشاغرة لم تحسم القرار

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

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

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

أظهرت التوقيعات موضع الحد

ظهرت المفاضلة نفسها على نطاق أصغر في الحقول الفرعية للتوقيع. فتجاهل حقل غير معروف يحافظ على التوافق الأمامي: يستطيع برنامج قديم معالجة توقيع يحمل بيانات وصفية جديدة. لذلك أوصت RFC 2440 بتجاهل الأنواع غير المعروفة. لكن التجاهل الصامت قد يمحو خاصية يعتمد عليها الموقّع.

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

ولا تكتسب البيانات المعروفة المرفقة بتوقيع صالح سلطة ذلك التوقيع تلقائياً. فقد توضع الحقول الفرعية في القسم المجزّأ أو غير المجزّأ. وحذرت RFC 2440 من أن معلومات القسم غير المجزّأ ليست نهائية لأنها ليست جزءاً من التوقيع نفسه. يستطيع القارئ رؤيتها والمدقق تحليلها، لكن ذلك لا يجعلها محمية تشفيرياً. الحضور والتحليل والتعرّف والتنفيذ والتغطية حالات منفصلة.

من التحفّظ إلى السجلات

أنشأت RFC 4880، التي حلّت محل RFC 2440 في 2007، سجلات صريحة لدى IANA واشترطت توافق IETF لإضافة أنواع حزم جديدة باعتبارها خصائص أساسية. كما نبهت إلى مخاطر خفض المستوى والتبديل المتقاطع في الامتدادات المرتبطة بكشف التعديل. أصبح الإجراء أوضح، لكن قابلية التشغيل المتبادل والتنفيذ وتحليل الأمن لم تتحول إلى خانة واحدة.

حلّت RFC 9580 المنشورة في 2024 محل RFC 4880، وأبقت إجراءات تخصيص متباينة. تستخدم بعض سجلات OpenPGP مسار Specification Required، بينما تفرض أنواع الحزم وبعض مساحات الإصدارات والمعرّفات المسار الأشد RFC Required. ويُطلب من الخبراء فحص خصائص الأمن المتوقعة والتوافق مع التطبيقات القائمة. إنها إجابة مؤسسية عن الفراغ السابق، وليست برهاناً على أن كل امتداد مقبول آمن في كل نشر.

لا تقول هذه الوثائق إن كل امتداد ضار أو إن جميع المنفذين اتبعوا ممارسة واحدة. لكنها تثبت حقيقة تاريخية أضيق وأكثر فائدة: إضافة معنى إلى بروتوكول تشفيري قد تغيّر سلوك المسارات القائمة. العدد المتاح مجرد عنوان داخل التنسيق؛ ولا يبرهن على التوافق أو التغطية التشفيرية أو فهم المستخدم أو السلامة التشغيلية.

المصادر