الخلاصة

  • حمت RFC 3923 كائن CPIM باستخدام S/MIME ثم نقلته داخل غلاف XMPP ؛ ولا يحدد نطاق أسماء هذا الغلاف معنى الرسالة.
  • يمكن لبوابة XMPP-CPIM إزالة غلاف الخدمة أو إضافته، لكن عليها تمرير الكائن المحمي كما هو.

التغيير المسموح للبوابة

تصل البوابة بين خدمتي مراسلة لا تستخدمان البروتوكول نفسه. لكن ما إن تبدأ إحداهما بتحويل الرسالة حتى يظهر سؤال أمني: ما الذي يجوز تغييره من دون أن يصبح المحوّل نفسه جزءاً من نطاق الثقة؟ أجابت RFC 3923، المنشورة في أكتوبر 2004 معياراً من IETF، بوحدة ثقة ضيقة عمداً. تستطيع بوابة XMPP-CPIM نزع غلاف خدمة ووضع غلاف خدمة أخرى. لكنها لا تستطيع تعديل كائن S/MIME الموقع أو المشفر الموجود في الداخل.

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

كائن محمي داخل مقطع XMPP

ينشئ المرسل أولاً كائن Message/CPIM. وهو يتضمن الترويسات والمحتوى، وتشترط RFC أن يشملهما توقيع S/MIME أو تشفيره. ثم يوضع الكائن الناتج في مقطع CDATA بلغة XML داخل عنصر <e2e/> تابع لمقطع رسالة أو حضور في XMPP. وقد يكون الكائن المغلف، بحسب الاستخدام، مستند حضور PIDF أو كائن XML من XMPP.

عنصر <e2e/> ناقل وليس مفسراً. وتقول RFC إن نطاق أسماءه لا يحمل دلالة ذاتية؛ فمواصفات CPIM أو PIDF أو XMPP هي التي تحدد معنى الكائن المغلف. لذلك لا يحتاج الوسيط إلى فهم المحتوى المحمي لمجرد قدرته على تحليل مقطع XMPP الذي يحمله.

تنبع قاعدة البوابة من هذا الفصل. عند خروج حركة المرور من XMPP، تزيل البوابة الغلاف، بما في ذلك علامتا <e2e>، لتكشف كائن S/MIME متعدد الأجزاء وتوجهه، مع إضافة غلاف الخدمة غير التابعة لـ XMPP عند الحاجة. وفي الاتجاه المعاكس تزيل غلاف الخدمة الأخرى، وتضع الكائن نفسه داخل غلاف XMPP، ثم توجه المقطع. وتصرح RFC بأن كائن S/MIME المغلف يجب أن يظل ثابتاً ولا يجوز لبوابة XMPP-CPIM تعديله.

حد أمني لا منظومة أمن كاملة

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

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

في 2014، وصفت RFC 7165 نهج S/MIME بأنه لم يحقق انتشاراً واسعاً، وذكرت صعوبات إدارة المفاتيح ومعالجة كائنات S/MIME ضمن الأسباب الجزئية. هذا رصد تاريخي في وثيقة معيارية من ذلك العام، لا إحصاء للاستخدام الحالي ولا تفسير وحيد. لكنه يوضح الدرس: قد يحفظ الحد الواضح المعنى التشفيري فيما تظل إدارة المنتج والمفاتيح صعبة. لم تكن القيمة الدائمة لـ RFC 3923 جعل البوابات موضع ثقة، بل إظهار أن التشغيل البيني لا يتطلب إعادة كتابة ما حماه الطرفان.

المصادر