الخلاصة

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

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

معرّف OID هو 1.3.6.1.4.1.22112.2.1. وبنيته الكاملة هي PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }: يحدد signer شهادة التوقيع باسم المُصدر والرقم التسلسلي، بينما يحمل الحقل الاختياري cert شهادة التوقيع نفسها. لا يجوز حذف cert إلا عندما تكون سلطة الشهادات هي أيضاً مُصدِر شهادة التوقيع وقادرة على استرجاع جميع الشهادات الصحيحة التي أصدرتها. هذا استثناء ضيق للاسترجاع، وليس تفويضاً لاستنتاج الهوية.

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

في PKCS#10 تحمل subjectPublicKeyInfo المفتاح العام لإنشاء المفتاح، وتحمل السمات البيان، ويُتحقق من توقيع الطلب بشهادة التوقيع. أما CRMF فتحمل فيه شهادة الطلب الموضوع والمفتاح العام؛ ويستخدم proof-of-possession اختيار التوقيع وهوية المرسل، بينما تحمل regInfo البيان. تشابه الغرض لا يلغي اختلاف بنية الترميز بين الصيغتين.

توفر RFC 5280 أساس مسار الشهادة واستخدام المفتاح. وتوفر RFC 6955 نقطة مقارنة لآليات تثبت تقنياً حيازة مفاتيح Diffie-Hellman. أما RFC 9883 فلا تحول السمة إلى إثبات تشفيري للمفتاح الخاص الثاني. كما يختلف نطاقها عن معرّفات ML-DSA في PKIX التي يعالجها RFC 9881، وعن نطاق البايتات الموقعة في CMS الذي يعالجه RFC 9882.

تحليل Theo March: يمكن تشغيل شهادة التوقيع باعتبارها جذر ضمان مفوضاً للمفتاح الثاني. هذا تحليل وليس إلزاماً من RFC. ينبغي ربط كل شهادة إنشاء مشتقة بالشهادة الموقعة المصرِّحة في سجلات التدقيق، وتسجيل قرار تكافؤ الهوية، ومراقبة العدد والتكرار وتغير الموضوع وأخطاء التحقق.

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

تشمل حالات الاختبار: مساراً وتوقيعاً صحيحين، مساراً غير صحيح، توقيعاً معدلاً، شهادة مفقودة خارج حالة الاستثناء، استرجاعاً ناجحاً لدى المُصدر، اختلاف الموضوع وSAN مع توثيق التكافؤ وبدونه، طلب شهادة توقيع، مفتاح توقيع أضعف، وفحص PKCS#10 وCRMF في موضعيهما المختلفين. يجب ربط المُصدر والرقم والبصمات وقرار السياسة والشهادة الناتجة.

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

المصادر