الخلاصة

  • استخدمت RFC 2015 بنية multipart/signed: بقي كيان MIME في الجزء الأول قابلاً للقراءة، ووُضع توقيع PGP المنفصل في الجزء الثاني، مع شمول ترويسات المحتوى في نطاق التوقيع.
  • كانت CRLF والتمثيلات ذات السبعة بتات وQuoted-Printable وBase64 والمسافات النهائية والأسطر التي تبدأ بـ From جزءاً من حدود الدليل، لا تفاصيل تنسيق.
  • يثبت التحقق علاقة بين بايتات وتوقيع ومفتاح؛ ولا يثبت وحده الهوية أو الصلاحية أو القصد أو التسليم أو القراءة أو النتيجة.

عالج التصميم عيباً في الصيغ الأقدم. كان استرجاع النص من application/pgp قد يفرض على البرنامج تحليل تراكيب PGP نفسها. أما RFC 1847 فعرّفت إطاراً أمنياً محايداً من جزأين بالضبط. ربطت RFC 2015 هذا الإطار بـ PGP: المحتوى الموقّع أولاً، ثم application/pgp-signature. وهكذا يستطيع عميل يفهم MIME تحديد المحتوى حتى إن لم يستطع التحقق من PGP.

لكن قابلية القراءة لم تمنح الوسطاء حق التعديل. بالنسبة إلى النص، يختار المرسل التمثيل، ويحوّل نهايات الأسطر إلى CRLF، ويطبّق Content-Transfer-Encoding، ثم يضيف ترويسات محتوى MIME، وبعد ذلك فقط يحسب التوقيع على الترويسات والبيانات المرمّزة. شمول الترويسات يمنع تغيير نوع المحتوى أو طريقة تفسير البايتات دون إبطال التوقيع.

حوّلت قيود SMTP ذات السبعة بتات هذه الخطوات إلى شرط تشغيل. قد تحوّل بوابة محتوى من ثمانية بتات إلى Quoted-Printable أو Base64 كي يمر إلى نظام أقدم. يحافظ ذلك على التسليم، لكنه يستبدل مدخل دالة التجزئة. لذلك وجب أن يكون التمثيل الآمن للنقل هو نفسه التمثيل الذي وُقّع قبل الإرسال.

أبرز مثال RFC 2015 تغيرات صغيرة يصعب رؤيتها. بعض برمجيات صناديق البريد تضيف > قبل سطر يبدأ بـ From ، وقد تحذف بوابات أخرى المسافات في نهاية السطر. جاءت RFC 3156 لاحقاً بتفصيل استعادة CRLF وحماية المسافات وحد السطر الأخير. قد يبقى المعنى المرئي ثابتاً فيما يتغير السجل المشفّر.

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

جعلت RFC 2480 قرار البوابة صريحاً عند الانتقال إلى بيئة لا تدعم MIME. يجب أن تتمكن من تمرير الكيان الأمني دون تغيير، أو من تفكيك multipart/signed لإظهار المحتوى مع العلم بأن التوقيع سيفقد صلاحيته. في الحالة الثانية ينبغي الاحتفاظ بالتوقيع وإضافة تحذير. أما التحقق أو إعادة التوقيع في البوابة فينشئ حارس مفاتيح ونقطة ثقة جديدين، لذلك لا يكون مفعّلاً افتراضياً.

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

بقي درس RFC 2015 سابقاً للحسابات التشفيرية: يجب أولاً تحديد التمثيل الذي لا يُسمح للطريق بأن «يحسّنه» بعد الآن.

المصادر