الخلاصة

  • حذفت المراجعة 01 لمسودة ACME فردية الوضع الصارم الوارد في المراجعة 00. كان ذلك الوضع يفرض تواقيع ما بعد الكم أو التواقيع الهجينة على توثيق خادم TLS وطلبات JWS، ويرفض الرجوع إلى توقيع تقليدي وحده.
  • تقترح الصياغة الجديدة السماح للخادم بالتخلي عن ES256، رغم أن RFC 8555، القسم 6.2 يفرض تنفيذه حالياً. وإذا أبقاه الخادم، جاز له قبول طلبات JWS التقليدية خلال فترة انتقال يختارها.

النفق الجديد لا يقرر من يطلب الشهادة

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

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

تغيرت قائمة الخوارزميات أيضاً. نسخة يونيو ألزمت خوادم الوضع المعني بتنفيذ بدائل محددة من ML-DSA وتوقيع مركب، مع الإبقاء على ES256. القسم 4.2 الجديد يقول إن الخادم يجوز له دعم أي خوارزمية JWS مسجلة في سجل JOSE، ولا يفرض خوارزمية أو مجموعة معاملات بعينها. ويجوز له ألا ينفذ ES256 أصلاً. أما الخادم الذي يحتفظ به لخدمة العملاء القدامى فيستطيع مواصلة قبول توقيعاتهم التقليدية للمدة التي يحددها. هكذا قد تحمل خدمتان الوصف نفسه وتختلفان جذرياً عند باب الطلب.

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

المصادر: مراجعة أكتوبر؛ نسخة يونيو؛ RFC 8555؛ حالة المسودة.