الخلاصة

  • قيم *_legacy الثلاث في RFC 9963 مقصورة على CertificateVerify الخاص بالعميل بعد عرضها في CertificateRequest.
  • لا يعلنها العميل في ClientHello ولا يقبلها من الخادم، ولا يقبلها الخادم إن لم يكن قد عرضها. وينبغي أن تبقى معطلة افتراضياً.
  • سجل القيمة، وعرضها، وقدرة المفتاح، وجلسة مصادقة ناجحة أدلة مستقلة؛ ولا يتحول أي منها إلى صلاحية تطبيق أو تغيير.

من يطلب التوقيع يحدد نطاقه

استبدل TLS 1.3 ‏RSASSA-PKCS1-v1_5 بـ RSASSA-PSS في CertificateVerify. لكن بعض مفاتيح شهادات العملاء المحمية بعتاد قديم لا تستطيع إنشاء توقيع PSS متوافق. وقد لا يظهر ذلك إلا بعد اختيار TLS 1.3 ثم طلب الخادم مصادقة العميل.

لا يطلب RFC 9963 إيقاف TLS 1.3 للجميع ولا اختراع تراجع خارجي. يستطيع خادم يحتاج هذا التوافق أن يضع إحدى القيم في signature_algorithms داخل CertificateRequest. بعدها فقط يختارها العميل في توقيعه، وبعدها فقط يقبلها الخادم. أما الاتجاه العكسي فمحظور: لا يعلن العميل القيم في ClientHello، ويرفضها إن استعملها الخادم في CertificateVerify، وتبقى مصادقة خادم RSA في TLS 1.3 معتمدة على PSS.

لهذا لا تكفي عبارة «RSA قديم مفعّل». سجل IANA يثبت التعريف وحالة عدم التوصية. إعداد الخادم وطلبه المحفوظ يثبتان العرض المحدود. سجل المفتاح يثبت هل يعجز مفتاح العميل فعلاً عن PSS. وأثر المصافحة يثبت ما اختير وما تحقق. كما أن RFC 9963 يطلب NULL إلزامياً وDER صالحاً وفق RFC 8017، وأن يرفض الخادم التوقيع المخالف.

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

اجعل الاستثناء قابلاً للانتهاء

يحفظ السجل الجيد نسخة السياسة، ومعرف المفتاح، وCertificateRequest، والقيمة المختارة، ونتيجة التحقق، والحساب، وتاريخ الإزالة. كما يختبر الرفض من دون عرض، وعلى جهة الخادم، ومع DER معيب، ومع مفتاح بديل يدعم PSS. عندئذ لا يصبح التوافق وصفاً دائماً غامضاً.