الخلاصة

  • تقترح pull request 679 إضافة ML-DSA-44 وML-DSA-65 وML-DSA-87 إلى TLS Baseline Requirements لتنظيم المفاتيح والتواقيع في شهادات المشترك وCA وCRL واستجابات OCSP.
  • تقول المقدمة إن المقترح لا يجبر أي root store على الثقة بـML-DSA ولا يغير خوارزمية توقيع SCT. لكنها تسوّغ العمل بعملاء SDK والأنظمة المضمنة وIoT والبرمجيات الوسيطة والتطبيقات التي تستخدم مخازن ثقة النظام.
  • يشمل ميثاق SCWG شهادات خوادم TLS المتاحة عبر الإنترنت. وفي المقابل، يشترط في Certificate Consumer المصوّت أن ينتج برنامجاً عاماً لتصفح الويب بأمان، كما ترتبط أهلية المُصدر بقبول شهاداته في متصفح من هذه الفئة.
  • يستبعد الميثاق صراحة PKI داخلية ضيقة النطاق. لا يعني ذلك أن كل استخدام غير متصفحي خارج الاختصاص، ولا أن كل برنامج يستخدم root عاماً ممثّل في التصويت.
  • عند قطع البحث في 2 سبتمبر/أيلول 2026، بقيت SC-106 مسودة PR مفتوحة وغائبة عن صفحة الاقتراعات الرسمية. التعليقات ومحاضر طوكيو تسجل مواقف، لا قراراً جماعياً.
  • ينبغي أن يبين إيصال التفويض الفئات المقصودة، ونص الميثاق، وطريق المشاركة والتصويت، والثابت التقني المشترك، وحدود root وCT، ودليل التنفيذ، والمنتدى البديل، وموعد المراجعة.

من يطلب الملف ومن يملك صوتاً عليه؟

تبدأ القضية الحقيقية في SC-106 من قائمة، لا من معادلة تشفير. تقول المسودة إن أطرافاً معتمدة كثيرة لا تجد طريقاً عملياً إلى المصادقة المقاومة للحوسبة الكمية داخل بنية الثقة العامة X.509. ثم تحدد هؤلاء: عملاء خدمات مبنية على SDK، أجهزة مضمّنة وIoT، middleware للمؤسسات، وتطبيقات تعتمد على مخازن ثقة تديرها شركات أنظمة التشغيل.

قد تتحقق هذه البرامج من شهادة خادم من دون أن تكون متصفحاً. أما ميثاق Server Certificate Working Group فيضع شرطاً مختلفاً لعضو فئة المستهلكين المصوّت: أن ينتج للجمهور برنامجاً مخصصاً لتصفح الويب بأمان، وأن يوثق تحديثاته وقائمة الجذور ومتطلبات امتثال جهات الإصدار. ويُقاس تأهل المُصدر بقبول شهاداته في متصفح ينتجه عضو مستهلك.

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

يوفر تمييز Lu Heng بين stakeholder وprincipal قاعدة مناسبة: المشاركة دليل، وليست ولاية. ولذلك على السجل أن يحدد هل SC-106 حد أدنى للويب تستفيد منه تطبيقات أخرى، أم نشاط ancillary تابع لمهمة الويب، أم profile عام لفئات ثقة متعددة لا تتطابق مع الدائرة المصوّتة.

ما الذي يقيده الـcommit الثابت؟

يضيف eefc670… مجموعات المعلمات الثلاث في FIPS 204، وفحص encoding للمفتاح، وقواعد Key Usage لشهادة المشترك، والقيم الدقيقة لـAlgorithmIdentifier. يجب أن تغيب parameters، ولا يجوز HashML-DSA؛ المسموح هو ML-DSA «pure» فقط.

بعد ذلك تربط المسودة المفتاح بالتوقيع في اتجاهين. لا يجوز إدراج public key من ML-DSA إلا إذا كان توقيع الشهادة ML-DSA. ولا يجوز لتوقيع شهادة أو precertificate من ML-DSA أن يصدق إلا مفتاح ML-DSA. أما CRL واستجابة OCSP فمستثنيان من القيد الثاني لأنهما لا يصدقان public key.

تضع المقدمة حدوداً مهمة. السماح بهذا profile لا يلزم مشغل root store بإدراج hierarchy. ولا يغير التوقيع الذي يصدره CT log على SCT. إذن النص المشترك، وسياسة الثقة، وسياسة الشفافية، والمسار الذي يقبله العميل حالات منفصلة.

لكن الفصل نفسه يستدعي سؤالاً: ما العائق الذي تزيله Baseline Requirements لكل فئة مذكورة؟ هل هو تدقيق CA، أم سياسة root، أم أداة إصدار، أم path building، أم توزيع trust store، أم إعداد الخادم؟ لا تقدم المصادر جرداً للنسخ أو عدداً للعملاء المتعطلين أو تجربة توضح أن قاعدة واحدة للنقاء تعالج جميع الحالات.

غياب هذه البيانات لا يثبت أن الحاجة متخيلة. إنه يحدد ما يجب قياسه قبل نسبة الحاجة إلى جمهور كامل.

الاسم ليس حالة إجرائية

يحمل عنوان المستودع الرقم SC-106، وتسمي المقدمة الهدف ballot. لكن الصفحة العامة كانت تعرض Open وDraft، وcommit واحداً، من دون review رسمي. ولم تظهر SC-106 في صفحة SCWG تحت Voting أو IPR Review أو Discussion أو Draft / Under Consideration أو السجل التاريخي.

الحالة الموثقة في 2 سبتمبر هي draft pull request. لا يوجد في الأدلة إشعار نقاش رسمي أو proposer وendorsers معتمدون أو فترة اقتراع أو نتيجة أو IPR مكتملة أو Final Maintenance Guideline أو تاريخ نفاذ.

لكل خطوة سلطة مستقلة. يكتب المؤلف diff؛ يختار Working Group نسخة لإدخالها المسار؛ تصوت الفئتان؛ تعالج IPR الاستثناءات؛ ينشر النص النهائي؛ ثم يقرر كل من CA وroot وCT والعميل كيف يعتمد النتيجة. تسمية الملف الأول «ballot» لا تمنحه سلطة السلسلة كلها.

وتبقى المقارنة غير القابلة للتغيير مفيدة لأنها تحفظ ما طُرح فعلاً، حتى لو تغير النص لاحقاً.

الميثاق واسع في النشاط وضيق في مصدر القرار

لا تكفي كلمة browser لإغلاق المسألة. يخول بند النطاق SCWG وضع متطلبات وممارسات لإصدار وإدارة شهادات TLS التي تصادق خوادم متاحة عبر الإنترنت، وتحديثها لمواجهة المخاطر الناشئة، والقيام بأعمال ancillary. هذا وصف وظيفي أوسع من منتج متصفح بعينه.

ولا تكفي عبارة Internet-accessible server لتوسيع دائرة التمثيل. شروط العضوية تقول من يصوّت بصفة المستهلك، وتربط ذلك بتصفح الويب. وتربط المُصدر بالقبول في المتصفح. قد تستخدم برمجيات كثيرة الشهادة نفسها من دون أن تملك طريق التصويت نفسه.

يضيف بند Out of Scope حداً محدداً: PKI تديرها مؤسسة لاستخدام داخلي فقط، ولا يوزع أي Certificate Consumer جذرها. كما يستبعد استخدامات رئيسية مثل S/MIME وcode signing. لا يقول النص إن كل system client خارج النطاق، لكنه يبين أن الاستبعاد يحتاج صياغة صريحة.

فالنتيجة الصحيحة هي وجود مسألة تفسير، لا ثبوت تجاوز. إذا استند Working Group إلى بند خادم الإنترنت أو ancillary، فعليه أن يسمي النص وصاحب التفسير وحدوده وطريقة التعامل مع من لا ينتمي إلى فئة التصويت.

نقاش طوكيو أقدم من هذه المسودة

خصص محضر F2F 64 في مارس/آذار 2025 قسماً لتوضيح نطاق TLS BR. تناول النقاش المتصفحات وغير المتصفحات، ومخازن أنظمة التشغيل، والاتصالات بين الخوادم، وPKI الخاصة، والمرونة، وإمكان إنشاء Working Group جديد.

رأى اتجاه أن root programs للمتصفحات هي الواقع التنفيذي للـBR، وأن الاستخدامات الأبطأ لا ينبغي أن تقيد أمان الويب. ورأى اتجاه آخر أن أنظمة التشغيل والتطبيقات تشترك في الجذور ولا تملك مرجعاً بديلاً، وأن القواعد المخصصة للمتصفح قد تفتت التشغيل.

احتفظ المحضر بالاتجاهين ولم يسجل تعديل ميثاق أو قراراً. قيمته أنه يثبت أن الفجوة كانت معروفة قبل ML-DSA.

ظهرت الفجوة نفسها في تعليقات 2026. وصف مشارك الحالات بأنها non WebPKI. وشرح Ben Wilson أن assurance تعتمد على المسار الذي يبنيه ويقبله relying party. ثم فصل مشارك من Chrome بين اتجاهي السلسلة المختلطة، وأثار مسألة الميثاق، واقترح WG آخر.

هذه مواقف منسوبة لأصحابها. لا تتحول كثرة التفاعلات إلى تصويت، ولا تتحول سياسة شركة إلى رأي SCWG.

نقاش pure chain يرسم خريطة سلطة

تقول حجة المسودة إن وجود توقيع كلاسيكي في path معروض يحد ضمان ذلك path إلى القوة الكلاسيكية. يمكن أن تكون هذه العبارة صحيحة من دون أن تثبت أن كل mixed construction يجب أن يحظر في profile. فقد يقبل العميل path كاملاً من PQ ويرفض البديل الكلاسيكي؛ وجود البديل لا يغير تواقيع المسار المقبول.

يضع RFC 5280 prospective path ومعلومات trust anchor بين مدخلات التحقق. اختيار anchor مسألة policy، وقد تستخدم paths مختلفة جذوراً مختلفة. يتحكم profile فيما تصدره CA، ولا يختار بالنيابة عن العميل.

هذا لا ينفي مشروعية قيد مشترك. CA كلاسيكية توقع مفتاح مشترك PQ قد تفرض certificates أكبر تحت root موجود وتترك الحلقة الحاسمة كلاسيكية. CA من PQ توقع مفتاحاً كلاسيكياً قد تخدم انتقالاً أو إشارة ضد downgrade. المخاطر ليست متماثلة.

لذلك يجب تسمية invariant: سعة CT للويب، أو صدق تسمية path بأنه PQ، أو root signalling، أو compatibility، أو انتقال non-Web. جمعها في كلمة «نقاء» واحدة ينقل قرارات متعددة الملاك إلى طبقة مشتركة قبل إثبات ضرورتها المشتركة.

التنفيذ الجاري يثبت تعدد المسارات

تصف خارطة Chromium انتقالاً مرحلياً للويب، مع certificate negotiation، واعتمادات كلاسيكية وPQ متوازية، وحماية downgrade، وإزالة بعيدة جداً للخيارات الكلاسيكية. ويفضل Chrome للثقة العامة Merkle Tree Certificates بدلاً من X.509 التقليدي القائم على ML-DSA.

وتفصل تعليمات Chrome Quantum-resistant Root Program التجربة عن الإنتاج. يدعم Chrome 150 شهادات ML-DSA التقليدية في private PKI. أما MTC فلها test root store منفصل، لا تثق production في مفاتيحه، مع شروطها الخاصة للـlogs وmirroring والخوارزميات.

ليست هذه وصفة لكل جهاز. إنها evidence على إمكان اختبار compatibility sets مختلفة من دون منح واحد منها صفة عالمية.

يعرّف FIPS 204 الخوارزمية. يعرّف certificate profile الـencoding والإصدار. تحدد root policy الثقة. تحدد CT القبول والشفافية. يحدد client الـpath. ويثبت deployment ما يعمل. منطق minimum specification عند Lu Heng يطالب كل طبقة بألا تتكلم إلا في حدود فعلها.

عناصر إيصال التفويض

يبدأ الإيصال بهوية المقترح: base، head، status، proposer، endorsers، discussion، voting، أصوات كل فئة، IPR، النسخة النهائية وتاريخها. ثم يفصل browser وOS validator وSDK وembedded وIoT وmiddleware وprivate/public PKI.

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

ويفصل القسم التقني encoding، وpath assurance، وdowngrade، وسعة CT، وroot admission. لكل سطر invariant وصاحب قرار ودليل وعدم يقين وخيار محلي. ويضيف قسم التنفيذ test vectors، وlibrary/version، والحجم، والمسار، والpilot، والفشل.

وفي النهاية تقارن أماكن العمل: SCWG مع تفسير منشور؛ تعديل الميثاق؛ WG لغير المتصفحات؛ أو تجارب root-specific. ويضاف موعد review وthreshold وطريق exit للقيود الانتقالية.

ما لا يمكن قوله الآن

لا يوجد ballot معتمد أو Guideline نافذة أو قرار root أو نتيجة CT أو تفسير جماعي للميثاق. ولا يوجد census للعملاء المذكورين أو إثبات أن mixed chain بعينه سيُنشر.

ولا يوجد أيضاً ما يثبت أن المقترح باطل أو غير ضروري. الموجود هو حاجة موصوفة وprofile تقني محدد ومسألة تفويض لم تحسم علناً.

إصلاح السجل الآن رخيص. بعد أن تقتبس المشتريات والتدقيق SC-106 بوصفها «industry standard»، قد يصبح الاعتماد التشغيلي حجة رجعية لمنح المكان الأول شرعية لم يسجلها.

وضوح التفويض لا يضعف الـprofile

يمكن لـSCWG أن يعلن أن بند خوادم الإنترنت يكفي، ويحدد معنى تمثيله. ويمكن أن ينشئ Forum مجموعة لعملاء غير المتصفح إذا اختلفت قيودهم عن Web CT. ويمكن أن تستمر root pilots حتى تظهر common invariant مقاسة.

لا يعارض أي خيار ML-DSA. المطلوب فقط ألا يحدد موقع الملف حدود السلطة بصمت.

فصلت SC-106 بالفعل بين permission وroot trust وSCT signature. الخطوة التالية أن تفصل بين beneficiary وvoter. عندئذ يصبح النص التقني بوزن التفويض الذي أنشأه، لا أكثر.

المصادر

  1. Lu Heng، “The Multi-Stakeholder Mirage”
  2. Lu Heng، “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  3. CA/Browser Forum، pull request 679 — SC-106
  4. المقارنة الثابتة لـSC-106
  5. TLS Baseline Requirements المقترحة
  6. ميثاق Server Certificate Working Group
  7. محضر اجتماع SCWG رقم 64
  8. Bylaws الخاصة بـCA/Browser Forum
  9. صفحة حالة ballots في SCWG
  10. NIST FIPS 204
  11. RFC 5280، القسم 6
  12. Chromium، خارطة المصادقة HTTPS المقاومة للحوسبة الكمية
  13. تعليمات اختبار Chrome Quantum-resistant Root Program