الخلاصة

  • خصص RFC 3657 معرّفات CMS مستقلة لـ Camellia عند تشفير المحتوى وعند تغليف المفاتيح. يتطلب تشفير CBC وجود IV من 16 ثُمانيّة، بينما يجب أن تخلو معرّفات خوارزمية تغليف المفتاح من المعلمات.
  • يستخدم إعلان قدرات S/MIME صيغة ثالثة، هي معلمة NULL. ويحدد OID الخاص بالتغليف طول مفتاح تشفير المفاتيح (KEK)، لا طول مفتاح تشفير المحتوى (CEK) المغلّف بالضرورة.

الاسم واحد، لكن العملية ليست واحدة

لا يكفي ذكر «Camellia» في غلاف CMS لمعرفة ما فعله المرسِل. على المستقبِل أن يحدد أولاً هل استُخدمت الخوارزمية لتشفير المحتوى أم لتغليف مفتاح تشفيره (CEK)، ثم يفسر معرّف الخوارزمية وفق ذلك الدور. نشر RFC 3657 في يناير 2004 ضمن مسار المعايير، وحدد اصطلاحات Camellia في CMS عبر عائلتين من المعرّفات: واحدة لتشفير المحتوى بنمط CBC، وأخرى لتغليف المفاتيح. RFC 3657

تظهر الفروق في المعلمات. ففي المعرّفات id-camellia128-cbc وid-camellia192-cbc وid-camellia256-cbc يجب أن يكون حقل معلمات AlgorithmIdentifier موجوداً وأن يحتوي على متجه تهيئة من 16 ثُمانيّة. هذا المتجه جزء من وصف تشفير المحتوى، ولا يمكن استنتاجه من اسم الخوارزمية. كما يحيل RFC إلى قاعدة CMS الخاصة بحشو النص الصريح. RFC 3657 RFC 5652

أما عند تغليف المفتاح فتنقلب القاعدة. تتضمن معرّفات تغليف Camellia الثلاثة فرعاً يدل على طول المفتاح، لكن يجب أن تكون معلمات AlgorithmIdentifier غائبة. تحدد آلية التغليف بنفسها استخدام قيمتها الابتدائية الداخلية؛ لذلك لا يحمل الحقل IV. ويشير طول المفتاح في OID إلى مفتاح تشفير المفاتيح (KEK)، ولا يفرض أن يكون طول CEK المغلّف مماثلاً. يجب أن تدعم التطبيقات تساوي الطولين؛ وإذا دعمت أطوالاً مختلفة، فيجب ألا يكون KEK أقصر من CEK. وهكذا يحدد RFC حدود الترميز والتوافق، لا قاعدة تجعل كل المفاتيح في الغلاف بطول واحد. RFC 3657 RFC 3394

إعلان القدرة له ترميز ثالث

يحدد RFC 3657 أيضاً طريقة إعلان عميل S/MIME دعمه لـ Camellia ضمن SMIMECapabilities. يُرفق OID الخاص بالقدرة بمعلمة NULL. لا يتعارض ذلك مع غياب المعلمات في معرّف التغليف، فهما بنيتان مختلفتان من ASN.1 ولكل منهما معنى خاص. كما أن NULL في التمثيل المنقول ليس هو نفسه غياب المعلمة. ويورد RFC ترميزات DER للأطوال الثلاثة حتى يمكن مطابقة صيغة الإعلان بدقة. RFC 3657 RFC 2633

قائمة القدرات موقّعة ومرتبة بحسب التفضيل، لكنها لا تصف إلا جزءاً مما يدعمه المرسِل. وهي مدخل لقرار لاحق إلى جانب الاتفاقات الخاصة وتفضيلات المستخدم والقيود القانونية. ليست هذه القائمة مصافحة فورية، ولا اختباراً لإعدادات المستقبِل الحالية، ولا دليلاً على استخدام Camellia في رسالة بعينها. لمعرفة العملية المختارة، يجب فحص حقول تشفير المحتوى وإدارة المفاتيح في الغلاف نفسه، لا الاكتفاء بإعلان سابق للقدرات. RFC 3657

التوافق يعتمد على إبقاء الحدود منفصلة

ينبغي أن تفحص مراجعة التوافق السياقات الثلاثة كلّاً على حدة. في CBC للمحتوى، يُراجع المعرّف وطول المفتاح ووجود IV من 16 ثُمانيّة. وفي تغليف المفتاح، يُتحقق من غياب المعلمات ومن ملاءمة الطولين الفعليين لـ KEK وCEK لقدرات التطبيق. أما في إعلان القدرة، فتُقارن قيمة DER الموقّعة — بما فيها NULL — وترتيب التفضيل. قد يؤدي الخلط بين السياقات إلى اختلاف في التحليل أو الاختيار حتى عندما تعلن الأنظمة جميعها دعم الخوارزمية نفسها.

ينص RFC 3657 على اتباع تغليف Camellia لبنية RFC 3394 مع استبدال AES بـ Camellia، لأن كليهما يستخدم كتلة بطول 128 بت. والقيمة الابتدائية الافتراضية للتحقق من سلامة المفتاح هي الثابت A6A6A6A6A6A6A6A6. إذا لم يستعد فك التغليف هذه القيمة، يعيد المستقبِل خطأً ولا يعيد بيانات المفتاح. ويسمح RFC أيضاً بقيم ابتدائية بديلة حين يتطلب التطبيق نطاقاً مختلفاً لسلامة البيانات. يتعلق هذا الفحص ببيانات المفتاح المغلّف وفق الآلية المحددة؛ ولا يثبت هوية المرسِل أو مصدر محتوى CMS أو صلاحية المستخدم للتصرف بناءً على المحتوى بعد فك تشفيره. RFC 3657 RFC 3394

هذا إعادة بناء تاريخية لعقد ترميز، وليس توصية أمنية حديثة أو مسحاً لانتشار التنفيذ. توفر سجلات خوارزميات CMS والملفات اللاحقة سياقاً إضافياً، لكنها لا تثبت أي منتجات نفذت RFC 3657 أو مدى شيوع ذلك. الدرس أضيق: معرّف الخوارزمية حقل بروتوكولي ذو نوع محدد؛ ويجب قراءة OID ووجود المعلمات والبنية المحيطة معاً. RFC 3370 RFC 8419

المصادر