الخلاصة

  • يخصص RFC 9963 ثلاث قيم *_legacy كي يطلب خادم TLS 1.3 صراحةً RSASSA-PKCS1-v1_5 من شهادة عميل لا تستطيع إنتاج توقيع RSASSA-PSS متوافق.
  • الاستثناء محصور في CertificateVerify لدى العميل: لا يستخدم في CertificateVerify لدى الخادم ولا في شهادات الخادم، وينبغي أن يكون معطلاً افتراضياً.

يعالج RFC 9963، الذي ألّفه David Benjamin وAndrei Popov، احتكاكاً محدداً في الانتقال. أزال TLS 1.3 دعم RSASSA-PKCS1-v1_5 من CertificateVerify لصالح RSASSA-PSS. وتذكر RFC أن بعض عتاد التشفير لدى العميل، ومنه بعض TPM، قد لا ينتج توقيع PSS متوافقاً. لذلك قد يختار الطرفان TLS 1.3 ثم يفشل الاتصال فقط حين يطلب الخادم شهادة عميل.

ليست الإجابة إعادة المخطط القديم إلى الاستعمال العادي. فالنص يعرف rsa_pkcs1_sha256_legacy وrsa_pkcs1_sha384_legacy وrsa_pkcs1_sha512_legacy. ولا تحمل هذه القيم معنى إلا لتوقيع في CertificateVerify العميل، وليست معرفة في أي سياق آخر. هذا الحد الصغير هو الحد التشغيلي: يبين رمز ما يستطيع طرف التعبير عنه في رسالة بعينها، ولا يمنح اسم الخوارزمية وحده ترخيصاً عاماً لكل مشارك في TLS.

قواعد التفاوض تبقي الاستثناء ظاهراً. يجب ألا يعلن العميل هذه القيم في امتداد signature_algorithms في ClientHello، وألا يقبلها في CertificateVerify من الخادم. ويجوز لخادم يريد دعم عميل ذي مفتاح قديم فقط أن يرسلها في CertificateRequest وأن يقبلها في جواب العميل، لكنه لا يجوز أن يقبل قيمة لم يعرضها. ويمكن للعميل ذي المفتاح القديم أن يتفاوض عليها إذا عرضت. وإذا كان مفتاحه يدعم PSS فلا ينبغي له اختيار المسار القديم، وإن لم يكن تحديد ذلك عملياً دائماً. وينبغي أن تعطل التنفيذات هذه القيم افتراضياً.

والحد عند الخادم صريح أيضاً. فمشكلة الانتقال الموصوفة لا تنطبق على مفاتيح الخادم. القيم الجديدة ممنوعة في شهادات الخادم، ويظل PSS مطلوباً لخوادم TLS 1.3 التي تستخدم RSA. ولا يخفف الاستثناء واجب التنفيذ الصحيح: يجب اتباع RFC 8017، مع معامل NULL الإلزامي وترميز DER صالح، وعلى الخوادم رفض التواقيع غير المطابقة.

لذلك تؤيد السجلات نتيجة محدودة: يمكن لخادم وعميل أن يتفاوضا عمداً على استثناء معلّم في شروط معلنة. وهي لا تثبت أن TPM أو متصفحاً أو مكتبة أو مؤسسة أو خادماً بعينه طبقه؛ ولا تصدق جلسة بعينها ولا تثبت نتيجة أمنية عامة. يربط ملف IETF David Benjamin بـRFC، ويعطي موقعه العام سياقاً مهنياً، لكن أياً منهما ليس دليلاً على نظام عامل لطرف آخر.

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

Sources