الملخص

  • في 10 سبتمبر 2026 رفضت IESG استئنافاً، ورفعت تعليق النشر، وأرسلت إعلان الموافقة على draft-ietf-tls-mldsa-05. تحدد الوثيقة كيفية استخدام توقيعات ML-DSA الواردة في FIPS 204 للمصادقة في TLS 1.3. وحالتها المستهدفة RFC معلوماتية؛ لكنها عند التحقق بقيت Internet-Draft من دون رقم RFC.
  • يتضمن سجل TLS SignatureScheme لدى IANA القيم mldsa44 وmldsa65 وmldsa87 عند 0x0904 و0x0905 و0x0906. وتحمل القيم الثلاث N. ووفق RFC 9847، تعني N أن IETF لم تصدر حكماً على الملاءمة أو أن التوافق غائب؛ وليست علامة D التي تعني أن الآلية غير موصى بها.
  • الموافقة على النشر، وتخصيص معرفات قابلة للتشغيل البيني، والتوصية بالنشر التشغيلي أفعال منفصلة. أنهى قرار الاستئناف نزاعاً إجرائياً حول نشر الوثيقة، ولم يختر ML-DSA الخالصة أو المركبة نيابة عن كل مشغّل.
  • على الجهة التي ستفعّل الآلية أن تصدر إيصال قرار محلياً يحدد سطح TLS، والمعامل والملف المختارين، ونطاق الأقران والشهادات، والأدلة المؤرخة، وحدود الفشل، وصاحب سلطة التراجع، وموعد المراجعة.

القرار المنتهي يخص نشر الوثيقة

يفصل سجل Datatracker التاريخي بين مرحلتين. وافقت IESG على النص في 8 يوليو، ثم علقت إرساله في اليوم نفسه أثناء نظر استئناف. وفي 10 سبتمبر رفضت الاستئناف ورفعت التعليق وأعادت الوثيقة إلى حالة إرسال إعلان الموافقة. ويصفها الإعلان الرسمي بأنها منتج لمجموعة عمل TLS يراد نشره في فئة Informational.

لا يخفي السجل الخلاف. يشير ملخص راعي الوثيقة إلى نحو 275 رسالة وإلى نسبة تقارب أربعة مؤيدين مقابل معارض واحد للاستمرار. كما يسجل مواقف متعددة: عدم نشر ML-DSA الخالصة، أو التوصية بالتوقيعات المركبة، أو تحريك المسارين معاً. وتقول إجابة IESG عن الاستئناف إنها راجعت ردود Working Group Last Call، ووجدت دعماً واسعاً، ورأت أن الاعتراضات نوقشت وأُخذت في الاعتبار. ولم تشارك مديرة مجال الأمن Deb Cooley في القرار.

تثبت النتيجة أن تقدير rough consensus كان كافياً كي تتقدم الوثيقة رغم بقاء اعتراضات. لكنها لا تجعل نسبة الرسائل تصويتاً على تشغيل الآلية، ولا تجعل رفض الاستئناف برهاناً تشفيرياً. الإجراء يجيب عن صلاحية قرار المجموعة بالنشر؛ أما سلامة سلسلة شهادات أو مجموعة عملاء أو خدمة بعينها فتبقى مسؤولية مالكها.

ولا تزال هناك خطوة بين الموافقة وصدور RFC مرقمة. تعرض صفحة الوثيقة الحالية الحالة Approved-announcement sent، لكنها تصنف النسخة 05 Internet-Draft نشطة. وحالة مراجعة IANA هي Version Changed - Review Needed، وحالة الإجراء In Progress. لذلك فالوصف الدقيق هو «موافق عليها للنشر»، لا «RFC صادرة بالفعل».

ثلاث قيم تحل مشكلة تعريف مشتركة

يحدد FIPS 204 خوارزمية التوقيع الرقمي ما بعد الكمي ML-DSA. أما وثيقة IETF فتربط ثلاثة مستويات معاملات بآلية التفاوض على توقيع المصادقة في TLS 1.3: ML-DSA-44 بـmldsa44 و0x0904، وML-DSA-65 بـmldsa65 و0x0905، وML-DSA-87 بـmldsa87 و0x0906.

يوفر RFC 9881 معرفات AlgorithmIdentifier المقابلة في X.509. وتوصل وثيقة TLS هذه المعرفات بقيم SignatureScheme. فعند استخدام إحدى القيم في CertificateVerify، يجري التوقيع والتحقق وفق FIPS 204 مع ctx فارغ، ويجب أن تستخدم شهادة الكيان النهائي المعرف المقابل. ولا تشمل الآلية نسخ HashML-DSA ذات التجزئة المسبقة.

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

يعرض سجل IANA الحي القيم الثلاث مع N. وما زال مرجع السجل يشير إلى نسخة أقدم من المسودة، بينما تبين Datatracker أن إجراء IANA مستمر. لذا يجب حفظ حقيقتين معاً: التخصيص ظاهر وعلني؛ وتنظيف المراجع وسلسلة النشر النهائية لم يكتملَا بعد.

لا تعني N رفضاً

يحدد RFC 9847 ثلاثة أوضاع لعمود التوصية. تعني Y وجود توافق في IETF على أن العنصر موصى به وملائم للغرض المحدد، مع بقاء حدود التطبيق. وتعني D أن استعماله غير مستحسن مع وجوب ذكر السبب. أما N فتعني أن IETF لم تقيّم الملاءمة أو لم تصدر بياناً بشأنها، أو أن التوافق غير موجود، أو أن مجال الاستخدام محدود.

ينص RFC بوضوح على أن N لا تعني بالضرورة أن الآلية معيبة. ولذلك لا يمثل تخصيص القيمة ضوءاً أخضر، كما لا تمثل N ضوءاً أحمر. يسمح السجل للمنفذين باختبار كائن واحد ذي اسم مشترك، من دون اختلاق توصية عامة لم تعتمدها IETF.

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

المساران الخالص والمركب ليسا في الحالة المؤسسية نفسها

تصف الوثيقة الموافق عليها ML-DSA الخالصة. وتوجد مسودة Internet-Draft فردية نشطة تقترح توقيعاً مركباً يجمع ML-DSA وتوقيعاً تقليدياً في TLS 1.3. وتوضح Datatracker أن المسودة الفردية لا تحظى بتأييد مسار وثائق IETF. فهي دليل على بديل تقني مطور، لا على توصية مؤسسية مكافئة.

يعتمد الاختيار على نموذج التهديد. يتجنب الملف الخالص اشتراط نجاح توقيع ثان، لكنه يركز الثقة في ML-DSA وتنفيذها. وقد يحتفظ الملف المركب بمكون تقليدي إذا انكسرت الخوارزمية الجديدة أو شيفرتها، لكنه يزيد حجم الشهادة والرسالة والحساب ونقاط عدم التوافق. ولا يحسم وضع Informational هذه المفاضلات لكل بيئة.

كما أن قائمة التطبيقات في إعلان الموافقة لها حد واضح. وجود شيفرة في OpenSSL أو BoringSSL أو rustls-post-quantum أو s2n-tls أو wolfSSL أو Bouncy Castle أو GnuTLS يثبت عملاً تنفيذياً ملموساً. ولا يثبت تفعيلها افتراضياً أو مرور حركة إنتاج أو توافر سلاسل شهادات مشتركة أو أداء مقبولاً أو تراجعاً مجرباً.

إيصال النشر التشغيلي يصدر حيث يوجد النظام

ينبغي أولاً تسمية الاستخدام المحدد بدلاً من عبارة «جاهز لما بعد الكم». مصادقة الخادم، ومصادقة العميل، وخدمة خاصة محدودة، وتجربة عامة أسطح مختلفة. ويجب تسجيل مستوى ML-DSA، وما إذا كان الملف خالصاً أم مركباً.

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

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

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

حدود الأدلة

لا يثبت أي مصدر تفعيل القيم افتراضياً أو استخدامها العام في الإنتاج. ولا تحسم المصادر أفضلية الملف الخالص أو المركب في كل الأحوال. جواب الاستئناف تقدير إجرائي، لا برهان تشفير. ومعيار NIST ليس تقييماً لنشر TLS محدد. وظهور القيم في السجل لا يثبت انتهاء كل عمل IANA وRFC Editor.

والخلاصة المحدودة هي أن IETF وافقت على نشر طريقة تمنح ثلاثة مستويات ML-DSA معنى قابلاً للتشغيل البيني في TLS 1.3، بينما أبقت حالة التوصية N. أما القرار التالي وأدلته فيخصان كل جهة تعتمدها.

المصادر

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — إعلان الموافقة على Use of ML-DSA in TLS 1.3
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — تاريخ الوثيقة
  7. IESG — جواب الاستئناف، الأثر 320
  8. IANA — معلمات Transport Layer Security
  9. RFC 9847 — تحديث سجلات IANA لـTLS وDTLS
  10. NIST — FIPS 204، معيار ML-DSA
  11. RFC 9881 — معرفات خوارزمية ML-DSA
  12. RFC 9846 — بروتوكول TLS 1.3
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3