الخلاصة

  • خفضت النسخة 06 المؤرخة في 30 سبتمبر 2026 من مسودة معرّفات مرتكزات الثقة لدى مجموعة TLS الحد الأقصى للتمثيل الثنائي للمعرّف من 255 إلى 32 بايت، وأصبح تركيب TrustAnchorID يحمل من بايت واحد إلى 32. ما زالت الوثيقة مسودة إنترنت لمجموعة عمل، وحالتها لدى IESG هي I-D Exists، وليست RFC منشورة.
  • أضافت النسخة إرشادات لمنع فيض الأعداد وسوء تفسير مكونات OID التي قد تكون كبيرة بلا حد نظري، وللتعامل المتوافق مع معرّف صالح لا يستطيع نظام عرض محلي تمثيله. المعرّف يوجه اختيار مسار شهادة محتمل، ولا يقرر أي سلطة تصديق ينبغي الوثوق بها.

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

يمكن إثبات الفارق الأوضح بمقارنة النصين اللذين تستضيفهما IETF. نسخة 14 سبتمبر سمحت بمعرّف ثنائي يصل إلى 255 بايت؛ نسخة 30 سبتمبر خفضته إلى 32، وعدلت مجال بنية TLS من <1..2^8-1> إلى <1..32>. يربط النص هذا الحد بإمكان إبقاء الصيغ الثنائية والعشرية المنقطة، النسبية والكاملة، ضمن حجم مريح يقل عن 255 بايت. لا يعني الرقم 32 أن مخزن الثقة لا يحتمل إلا 32 سلطة، ولا أنه يحد عدد مسارات التصديق التي يستطيع الخادم إعدادها.

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

قد يحتاج المسؤول، في المقابل، إلى كتابة المعرّف بأرقام عشرية منقطة في سجل تشخيص أو ملف إعداد. تسمح المسودة بوضع حد محلي لتلك الأدوات، لكنها لا تسمح بمعاملة كل قيمة صالحة تتجاوز قدرة العرض وكأنها إدخال فاسد. يجب أن تقبل تطبيقات TLS معرّفات بمكونات OID كبيرة بلا حد في رسائل المصافحة المحددة؛ ويمكنها إسقاط قيمة غير مدعومة قبل تسليمها إلى مكوّن آخر. وإذا أُسقطت كل القيم في EncryptedExtensions عومل الأمر كما لو أن الامتداد لم يرد. وتنصح المسودة من يضع حداً للمكونات بأن يدعم على الأقل القيم حتى 2^32-1 ليغطي نطاق أرقام المؤسسات الخاصة، وأن تُخصص المعرّفات داخل ذلك النطاق. هذه توصية SHOULD وليست شهادة بأن جميع المنتجات حققتها.

كما تغير مثال لمجموعة مرتكزات ذات نسخ من حد 2^64-1 إلى ما لا نهاية. لا يصح تقديم ذلك المثال دليلاً على تغيير سجل جذور يعمل اليوم. وحالة الوثيقة نفسها مهمة: هي عمل جارٍ لدى مجموعة TLS، لا معيار اعتمده IESG، ولا بيان عن انتشار تنفيذ أو وقوع خلل أمني لدى جهة بعينها.

المصادر