الخلاصة

  • تنص RFC 9690 على أن rsaEncryption في الشهادة لا يدل على استعداد صاحب المفتاح لقبول RSA-KEM؛ الاستعداد سجل مستقل ومحدود.
  • قرار الإرسال القابل للمراجعة يربط الشهادة ومصدر القدرة وعمرها وموضعي KDF وطول KEK وخوارزمية wrap ونوع محتوى CMS.

تبدأ المشكلة حين يقرأ النظام عبارة «مفتاح RSA صالح» ثم يخزنها كأنها «RSA-KEM متاح». النتيجة الأولى تخص بنية المفتاح ومسار الشهادة. أما الثانية فتتحدث باسم برنامج المستلم وسياسته وحالته الحالية من دون أن تملك دليلاً عليها.

تغلق RFC 9690 هذا الاستنتاج صراحةً: استخدام المعرّف rsaEncryption لا يعني أن المستلم سيقبل RSA-KEM بهذا المفتاح. قد تبقى الشهادة صالحة بينما تكون آلية KEM معطلة، أو بينما يقبل الطرف نوع محتوى مختلفاً أو مجموعة أخرى من الخوارزميات.

وليست RSA-KEM خانة واحدة. تُشفّر قيمة عشوائية جديدة z بالمفتاح العام، ثم تُشتق منها مادة سرية عبر KDF داخل RSA-KEM. بعد ذلك تستخدم بنية KEMRecipientInfo في CMS دالة KDF أخرى لاشتقاق مفتاح KEK الذي يفك تغليف مفتاح المحتوى. تسمح الوثيقة بأن تختلف الدالتان. وتمثل KDF3 مع SHA-256 وAES-Wrap-128 الحد الأدنى الإلزامي، لا كل ما قد يدعمه التنفيذ.

ثلاث درجات من الكلام في الشهادة

المعرّف العام rsaEncryption يصف المفتاح ولا يعلن قبول KEM. ويمكن إعلان القبول من خلال SMIMECapabilities في signed-data وفق RFC 8551، أو عبر امتداد الشهادة في RFC 4262. هذا دليل إيجابي، لكنه قائمة جزئية مرتبطة بزمن وموقّع وشهادة محددة.

إعلان قديم في رسالة موقعة لا يقيس إعداد الجهاز اليوم. وجوده لا يثبت أن الخدمة تعمل أو أن المؤسسة وافقت على هذه الرسالة؛ وغيابه لا يثبت دائماً عدم الدعم لأن القائمة جزئية.

إذا كان المفتاح مخصصاً حصراً لـRSA-KEM يستخدم id-rsa-kem-spki. غياب المعلمات يعني KDF3/SHA-256 للاشتقاق الداخلي. وجودها يفرض GenericHybridParameters التي تقيد KDF وطول KEK وخوارزمية wrap. وإذا ظهر keyUsage فلا يسمح إلا بـkeyEncipherment. هذه دلالة أقوى على الغرض، لكنها ليست إثباتاً لحيازة المفتاح الخاص أو نجاح فك التغليف.

التوافق القديم ليس عقداً واحداً

استخدمت RFC 5990 بنية KeyTransRecipientInfo وجمعت C وWK. أما RFC 9690 فتستخدم KEMRecipientInfo العامة من RFC 9629 وتفصل kemct عن encryptedKey. يساعد التوافق الخلفي في الانتقال، لكنه لا يلغي ضرورة تسجيل المسار المختار.

ينبغي أن يذكر السجل RFC 5990 أو RFC 9690، والشهادة، وإعلان القدرة، والمجموعة الدقيقة. وعلى جانب المستلم يفصل فحص طول ciphertext ونطاقه عن عملية المفتاح الخاص واشتقاق السر واشتقاق KEK وفك التغليف ومعالجة المحتوى وقرار التطبيق. نجاح البناء عند المرسل لا يثبت أياً من هذه المراحل البعيدة.

إيصال قدرة له تاريخ انتهاء

يحتفظ المرسل ببصمة الشهادة ونتيجة المسار، ومعرّف المفتاح وبايتات المعلمات، وkeyUsage، ومصدر الإعلان وموقّعه وزمنه، وKDF الداخلية، وKDF الخاصة بـCMS، وطول KEK، وwrap، ونوع المحتوى، ومسار التوافق المختار.

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

تحدد RFC 8017 تمثيل RSA، وRFC 3394 تغليف AES، وRFC 4086 متطلبات العشوائية، وRFC 5280 إطار الشهادات. لا واحدة منها تراقب حالة تطبيق المستلم الحية.

تدعم فكرة Lu Heng عن الحد الأدنى الأولي مواصفات مشتركة ضيقة مع إبقاء القرارات المستقبلية محلية وصريحة. وتفصل طبقات الواقع بين الشهادة والإعلان والبنية والحساب الخاص والقرار التنظيمي. أما أولوية الكود العامل فتجعل الحقيقة الأخيرة ما نفذه المستلم فعلاً، لا ما أوحى به OID.

المصادر