الخلاصة

  • يخصص RFC 9939 نوعي محتوى CMS للبنيتين PrivateKeyInfo وEncryptedPrivateKeyInfo في RFC 5958.
  • يعرّف OID بنية متوقعة للمحلل، ولا يثبت امتلاك المفتاح أو نجاح فك التشفير أو سلامة الحماية أو غرضاً مصرحاً به.

من السهل أن يتحول الاسم الفني إلى ختم ثقة. تقول ورقة التسليم إن الكائن هو id-ct-privateKeyInfo، فيُقرأ ذلك كأن المفتاح صار صالحاً للعمل. لكن التسمية تزيل غموضاً واحداً فقط: ما نوع المحتوى الذي يحمله CMS.

RFC 9939 يضع هذا الحد بوضوح. إنه يعرّف تعيينات محتوى CMS لمثيل واحد من بنيتي RFC 5958. الرقم 52 في قوس أنواع محتوى CMS هو id-ct-privateKeyInfo والرقم 53 هو id-ct-encrPrivateKeyInfo. ويسجل كذلك معرف وحدة ASN.1 واسمَي المحتوى الداخلي لتطبيق CMS. سجل IANA يجعل هذه الأسماء قابلة للتبادل بين الأنظمة؛ لا يجعل السجل قيّماً على السر ولا جهة مانحة للتفويض.

RFC 5958 يصف البنية التي يحملها الاسم. تضم PrivateKeyInfo/OneAsymmetricKey إصداراً ومعرف خوارزمية ومادة مفتاح خاص وحقولاً اختيارية. وتحمل EncryptedPrivateKeyInfo معرف خوارزمية تشفير وبيانات مشفرة. يمكن التحقق من صحة هذه الحقول محلياً، لكن يبقى خارجها سؤال من يملك سر الفك، وهل الغلاف يحمي النقل، وهل المفتاح المستعاد يطابق السجل المطلوب، وهل سياسة مستقلة تسمح باستخدامه.

RFC 5652 يتيح في CMS أغلفة للتوقيع أو التوثيق أو التشفير، وتختار البروتوكولات المستعملة خوارزميات مناسبة لبيئتها. RFC 5959 يضع اصطلاحات خوارزمية لـ EncryptedPrivateKeyInfo. ويحذر RFC 5958 من أن كشف المفتاح الخاص قد يتيح انتحالاً، وأن محتوى الحزمة لا يكتسب حماية لمجرد أن له نوع محتوى.

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

Sources