الخلاصة

  • تتيح RFC 9883 لصاحب شهادة توقيع أن يقر بحيازة مفتاح خاص آخر مخصص لإنشاء المفاتيح، من دون أن ينفذ ذلك المفتاح إثباتاً تقنياً للحيازة.
  • على جهة التصديق التحقق من مسار شهادة التوقيع وتوقيع الطلب وتطابق الهوية، وتطبيق سياسة تسمح صراحة بهذا البديل.
  • إذا اختُرق مفتاح التوقيع، تمتد المعالجة إلى شهادات إنشاء المفاتيح التي صدرت اعتماداً على الإقرارات الموقعة به.

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

مفتاحان وحقيقتان مختلفتان

يولّد صاحب الطلب أولاً زوج توقيع، ويوقّع طلباً عادياً، ثم يحصل على شهادة توقيع. بعد ذلك يولّد زوجاً لإنشاء المفاتيح. يضع المفتاح العام الجديد وإقرار الحيازة في طلب PKCS#10 ثانٍ، ويوقّع الطلب بالمفتاح الخاص الأول.

تحدد RFC 9883 معنى الإجراء بوضوح: موضوع شهادة التوقيع يقول إنه يحوز مفتاح إنشاء المفاتيح الخاص، من دون تقديم برهان. يجوز لجهة التصديق قبول القول فقط إن سمحت سياسة الشهادات بذلك. توفر RFC 6955 براهين تقنية لبعض مفاتيح DH وECDH، لكنها لا تناسب PKCS#10 ولا تدعم KEM مثل ML-KEM. أما الإقرار الجديد فيصلح لـ PKCS#10 وCRMF.

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

السياسة تتحمل فجوة البرهان

يجب على جهة التصديق التحقق من مسار شهادة التوقيع وفق RFC 5280، ثم التحقق من توقيع الطلب بمفتاحها العام. أي فشل يوجب الرفض. يُفترض أن يتطابق اسم الموضوع؛ وإذا اختلف اسم الموضوع أو أسماؤه البديلة، فيجب أن تشرح السياسة طريقة إثبات أنها تشير إلى الكيان نفسه. تعذر الإثبات يعني رفض الطلب.

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

في CRMF يلزم اختيار التوقيع داخل ProofOfPossession ووجود poposkInput وهوية المرسل ونسخة من المفتاح العام الجديد، ويوضع الإقرار في regInfo. يختلف الغلاف، لكن مفتاح إنشاء المفاتيح لا ينفذ إثباتاً.

لهذا تحظر RFC 9883 استعمال السمة للحصول على شهادة توقيع. فالمفتاح القادر على التوقيع يستطيع إثبات حيازته مباشرة بتوقيع طلبه. البديل مخصص للمشكلة الأضيق لمفاتيح الإنشاء.

الإصدار ينشئ رسم تبعية للإبطال

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

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

المصادر