مسودة IETF تترك لصيغة الإثبات تحديد الجهة التي تتحقق من طلب الشهادة

الخلاصة

• بدأت IESG في 2 سبتمبر المشاورة الأخيرة بشأن المراجعة 29 لمسودة تحمل إثباتات عن بُعد داخل طلبات الشهادات، وحددت 16 سبتمبر موعداً نهائياً للتعليقات.
• إذا دعمت جهات تحقق متعددة معرّف الصيغة نفسه، فإن مواصفة الصيغة هي التي توضح كيفية اختيار الوجهة. فهم البيانات وحده لا يحسم اتفاق المعالجة.

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

هذا جانب محدد من المشاورة التي أعلنتها IESG في 2 سبتمبر بشأن draft-ietf-lamps-csr-attestation-29. تُدرس الوثيقة للانتقال إلى مرتبة Proposed Standard، وتُستقبل التعليقات حتى 16 سبتمبر. وما زالت مسودة؛ لا يثبت الإعلان اعتمادها بوصفها RFC أو تشغيلها في أنظمة فعلية.

تتيح البنية المقترحة حمل الإثباتات عن بُعد ضمن طلبات PKCS#10 وCRMF، سواء جاءت بصيغ معيارية أم بصيغ خاصة بالمورّدين. ويمكن لجهة إصدار الشهادات CA أو جهة التسجيل RA إجراء التحقق داخلياً أو إسناده إلى جهة خارجية. وبذلك يستوعب الناقل المشترك أكثر من ترتيب تشغيلي.

مسؤولية تقع في مواصفة الصيغة

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

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

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

التسجيل الخارجي ليس قائمة بالخدمات

لا يزال جدول سمات S/MIME لدى IANA، عند التحقق منه، يعرض القيمة 59 باسم id-aa-evidence. وتطلب المسودة تغيير الاسم إلى id-aa-attestation مع الاحتفاظ بالرقم. هذا تخصيص للسمة الخارجية في طلب الشهادة، وليس دليلاً يختار خدمة التحقق.

أما معرّفات صيغ الإثبات المحمولة داخل البنية فتتركها الفقرة 4.2 لمؤلفي تلك الصيغ، ليخصصوها من فروع معرّفات يسيطرون عليها. الطبقتان مختلفتان في الوظيفة والمسؤولية. ومن ثم لا تكشف قراءة قيد السمة الخارجية وحدها قاعدة التوجيه في نظام معين.

توضح بنية RATS في RFC 9334 أهمية السياق: مالك جهة التحقق يضع سياسة تقييم الأدلة، ومالك الطرف الذي يعتمد على النتيجة يضع سياسة استخدامها. اختيار خدمة قد يحدد إطار تقييم، لا مجرد برنامج يفك ترميز البيانات. ويمكن لمنظمة واحدة أن تؤدي الدورين مع بقاء المسؤوليتين منفصلتين.

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

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

المصادر

1. إعلان المشاورة الأخيرة من IESG
2. مسودة إثبات CSR، المراجعة 29
3. بنية RATS في RFC 9334
4. تخصيصات SMI لدى IANA