الخلاصة

  • في KEMRecipientInfo يعرّف rid شهادة المستلِم أو مفتاحه العام، ويحدد kem خوارزمية ML-KEM، ويحمل kemct النص المشفّر المنتج لذلك المستلِم.
  • هذه حقائق عن بنية CMS، لا دليل على من يسيطر على مفتاح فك التغليف الخاص، أو على نجاح العملية محلياً، أو على قبول تطبيق أو تفويض قرار.

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

RFC 9936 يحدد استخدام ML-KEM-512 و-768 و-1024 في CMS. يستخدم المرسل مفتاح تغليف عام للمستلِم لإنتاج نص مشفّر وسر مشترك؛ ويستخدم المستلِم مفتاح فك تغليف خاصاً مع النص المشفّر لإنتاج السر المقابل. والغرض في CMS هو نقل مفتاح تشفير المحتوى.

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

الشهادة تضع مفتاحاً عاماً ولا تسجل فعلاً

يتطلب RFC 9936 OtherRecipientInfo مع KEMRecipientInfo لهذا المستلِم، ويقول إن المرسل يحصل على المفتاح العام الساكن من شهادة المستلِم وفق RFC 9935. ذلك سياق لتوزيع المفتاح، لا شهادة آنية لحراسته أو لصلاحية تشغيله أو لهوية العملية التي استخدمته. كما أن SMIMECapabilities قد يعلن دعماً جزئياً للخوارزميات؛ إعلان القدرة ليس دليلاً على معالجة هذه الرسالة.

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

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

المصادر