الخلاصة
- يتيح RFC 9763 لطالب شهادة جديدة أن يثبت تحكمه بالمفتاح الخاص لشهادة قائمة، ثم يتيح لسلطة التصديق أن تضع تجزئة الشهادة القائمة كاملة داخل الشهادة الجديدة.
- العلاقة الناتجة بيانٌ وقت الإصدار، وليست نتيجة مصادقة حية. فلا تلزم باستعمال الشهادتين معاً، ولا تثبت أن المفتاحين شاركا في الجلسة، ولا تقرر إن كان نجاح أحدهما كافياً.
- يجب أن يفصل سجل التدقيق بين دليل التسجيل وسياسة الإصدار والبايتات الدقيقة ومساري الثقة وإثباتات المفاتيح الحالية والتفاوض وقرار الطرف النهائي.
تبدأ المشكلة حين تُختصر كلمة «مرتبطة» إلى كلمة «موثوقة». قد تكون التجزئة مطابقة تماماً، وقد تكون الشهادتان صادرتين للكيان نفسه، ومع ذلك يكون رفض الاتصال هو القرار الصحيح. فالعلاقة لا تخبرنا أي مفتاح وقّع الرسالة الحالية، ولا أي مرساة ثقة يقبلها المستقبل، ولا أي خوارزمية نجت من التفاوض.
يعرّف RFC 9763 السمة relatedCertRequest في طلب توقيع الشهادة والامتداد RelatedCertificate في X.509. يمنحان معاً ضماناً إضافياً بأن شهادتي كيان نهائي تخصان الكيان نفسه. لكن النص يوضح أن الآليتين تعبّران عن علاقة فقط ولا تنفذان وظيفة أمنية بذاتهما.
إثباتان عند باب التسجيل
نفترض وجود الشهادة A وطلب شهادة جديدة B، في سياق انتقال محتمل من خوارزمية تقليدية إلى أخرى ما بعد كمومية. يحتوي الطلب العادي لـ B على المفتاح العام الجديد. في نموذج PKCS#10 الوارد في RFC 2986، يوقّع صاحب الطلب معلوماته، فيربط الاسم والمفتاح والسمات ويبرهن امتلاك المفتاح الخاص المقابل.
يضيف RFC 9763 فعلاً منفصلاً يخص A. تشمل السمة مُصدر A ورقمها التسلسلي ووقت الطلب ومكان الحصول عليها وتوقيعاً. يوقّع مفتاح A الخاص تسلسل المعرّف المشفر بـ DER مع قيمة BinaryTime.
يعرّف RFC 6019 تلك القيمة بعدد الثواني منذ بداية 1 يناير 1970 بالتوقيت العالمي، من دون الثواني الكبيسة. الصيغة مشتركة، لكن حدّ الحداثة المقبول تحدده سياسة سلطة التصديق محلياً. لذلك لا يكفي حفظ نتيجة «حديث». يلزم حفظ الوقت والنافذة ونسخة السياسة.
سلسلة فحوص لا شارة واحدة
على السلطة التي تدعم السمة أن تحصل على A من الموقع المحدد، وأن تتحقق من مسارها وفق RFC 5280. ثم تقارن المُصدر والرقم التسلسلي، وتطبق سياسة الحداثة، وتتحقق من التوقيع بالمفتاح العام لـ A.
كل خطوة تنتج حقيقة مختلفة. الجلب يحدد البايتات المستلمة. فحص المسار يطبق مراسي ثقة وسياسات معلومة. المطابقة تثبت أن الكائن هو المقصود. الوقت يطبق قرار مخاطرة محلياً. والتوقيع يثبت أن مفتاح A شارك في هذا الطلب.
يؤكد RFC 5280 أن مراسي الثقة والسياسات مدخلات للتحقق، وأن التطبيق قد يفرض قيوداً أضيق من الشروط الدنيا. كما يجب معالجة key usage وextended key usage كل على حدة عندما يجتمعان.
بعد ذلك يمكن إصدار B مع الامتداد. لا يجوز أن يشير إلا إلى A المذكورة في الطلب، ويجب أن تحمل A استخدامات المفاتيح التي تؤكدها B، وينبغي التحقق من صلاحية A وقت الإصدار. أما مدة التداخل المفيدة بين صلاحيتيهما فتبقى مسؤولية المشترك.
التجزئة تشير إلى إصدار بعينه
يحمل الامتداد خوارزمية تجزئة وتجزئة الشهادة A كاملة، لا اسم صاحبها وحده ولا مفتاحها العام فقط. يستطيع المستقبل إعادة الحساب محلياً ومقارنة النتيجة. هذه قاعدة حتمية لا تحتاج إلى تفسير فوري من سلطة على الشبكة.
لكن إعادة إصدار A تغيّر غالباً الرقم التسلسلي والمدة والامتدادات والتوقيع، حتى لو بقي الاسم والمفتاح. عندها تتغير التجزئة، ولا تصبح النسخة الجديدة تلقائياً هي الشهادة المشار إليها في B. جردٌ يعتمد الأسماء فقط قد يعرض علاقة لا توجد في البايتات المنشورة.
لا ينبغي تعليم الامتداد بأنه حرج حتى لا تنهار قابلية التشغيل مع البرمجيات الأقدم، ولا يوضع إلا في شهادة كيان نهائي. تجاهل الامتداد بلا خطأ يحقق التوافق، لكنه لا يثبت أن العلاقة فُحصت.
القرار يبدأ بعد نجاح المطابقة
إذا دعم الطرف مصادقة هجينة غير مركبة واستلم المادتين، يبحث عن الامتداد ويحسب تجزئة الشهادة الأخرى. بعد المطابقة يتوقف نطاق RFC 9763. قد تشترط سياسة طرف نجاح المصادقتين، وقد تقبل سياسة أخرى واحدة على الأقل.
في CMS وS/MIME يختار الموقّع ما يقدمه، بينما تمنح البروتوكولات التفاوضية جهة التحقق دوراً مختلفاً. يعرّف RFC 5652 صيغة CMS، ويصف RFC 8551 حزم الشهادات المشار إليها. لا تمنح الصيغة إذن التطبيق.
ينص RFC 9763 على أن العلاقة ليست شرطاً ولا أمراً باستخدام شهادة مع الأخرى. إنها تؤكد إمكان استعمالهما معاً لأن الكيان نفسه يتحكم بالمفتاحين. تتحدث سلطة التصديق عما فحصته عند الإصدار؛ أما الطرف الحي فيتحمل قرار القبول.
التحكم عند التسجيل ليس تحكماً وقت الاستخدام
يتطلب النهج الهجين دليلاً على تحكم الكيان بكل المفاتيح وقت التسجيل أمام السلطة ووقت الاستخدام أمام جهة التحقق. توقيع relatedCertRequest دليل تاريخي على فعل مفتاح A. طلب B العادي يعالج المفتاح الجديد. ويحفظ الامتداد علاقة الإصدار. لكن الجلسة اللاحقة تحتاج أفعال المفاتيح التي تشترطها سياستها الآن.
وجود B لا يعني أن مفتاحها الخاص وقّع. ووصول توقيعين لا يكفي إن فُحص واحد. وصحة التوقيعين رياضياً لا توسع مرساة الثقة المحلية. كما لا تصلح العلاقة تفاوضاً جرى تخفيضه قبل عرض الخوارزمية الأقوى.
وهذا يختلف عن RFC 9883، الذي يسمح بتصريح موقع عن امتلاك مفتاح تأسيس آخر من دون إثبات تقني لذلك المفتاح الآخر. أما RFC 9763 فيستعمل توقيعاً حقيقياً من A، وطلباً عادياً موقعاً لـ B، ثم يسجل العلاقة. الموضوع هنا منع تحويل إثبات التسجيل إلى إثبات جلسة.
أما RFC 9955 فيبحث خصائص التواقيع الهجينة وقواعد التحقق. لا يختار RFC 9763 قاعدة جمع عامة، بل يقدم إشارة علاقة لقواعد أخرى.
بين سلطتين تظهر طبقة اتفاق جديدة
إذا أصدرت المؤسسة نفسها A وB، فقد تملك المستودع ومراسي الثقة اللازمة. أما سلطة B المختلفة فقد لا تستطيع التحقق من A. يذكر RFC الحاجة المحتملة إلى ترتيب مسبق: عقد، مراسي مهيأة، واتفاق على سياسات الطلب والإصدار والقبول.
سيطرة كيان واحد على مفتاحين لا تعني تساوي ضمانات المؤسستين. قد تختلف هوية المشترك وحماية المفتاح والاستجابة للإلغاء. على سلطة B اختيار سياسة توفر حماية قابلة للمقارنة مع A، لكن المقارنة قرار موثق وليست نتيجة التجزئة.
ولهذا يجب عدم مساواة «الكيان نفسه» بـ«مستوى ضمان واحد»، أو «مسار صالح» بـ«مقبول لهذا التطبيق»، أو «علاقة مطابقة» بـ«مصادقتين ناجحتين».
موقع الشهادة سطح هجوم أيضاً
تحدد السمة مكان A. داخل المؤسسة يمكن استخدام HTTP(S) لحزمة CMS تحتوي الشهادات. وبين مؤسستين يوصى بعنوان data: يحمل الشهادات ومواد الإلغاء؛ يعرّف RFC 2397 هذا المخطط.
توقيع العنوان لا يجعل المحتوى آمناً. قد يقود إلى مادة خبيثة، لذا يلزم فحص البنية والتحقق الكامل. وقد تُراقب عملية الجلب فتكشف أن سلطة تعالج طلباً مرتبطاً بشهادة محددة. يقلل التضمين هذا التسرب ولا يلغي الفحص.
ينبغي حفظ نوع الموقع وتجزئة ما جُلب ونتيجة التحليل ومسار الشهادة ومعلومات الإلغاء والمراسي. الشهادة B وحدها لا تعيد بناء مدخلات الإصدار.
الامتداد لا يمنع التخفيض
يمكن لطرف خبيث ألا يعلن دعمه للخوارزمية الأقوى، فيجعل التبادل يعتمد الأضعف. يُفحص الامتداد بعد وصول الشهادة، فلا يثبت القدرات المعروضة ولا سلامة التفاوض.
الدليل يوجد في الحدود الدنيا المضبوطة، وسجل التفاوض المحمي حيث يتاح، والنمط المختار، والتنبيه عند التراجع. عدد الأزواج المرتبطة يقيس الجاهزية الإدارية؛ المرور الحي وحده يقيس التبني.
يتفق ذلك مع أولوية الشيفرة العاملة عند Heng Lu. وتسمح المواصفة الأولية الدنيا والقرار المستقبلي المحلي والتبني الطوعي بتوحيد الحقول والتوقيع والتجزئة، مع إبقاء القبول لدى من يشغّل البروتوكول.
أما طبقات الواقع فتفصل دليل التسجيل وبيان الإصدار وبايتات الشهادة ومطابقة التجزئة والتوقيع الحالي والمسار والقرار والأثر. لا يجوز صهرها في حالة خضراء واحدة.
سجل يمكن إعادة تشغيله
عند التسجيل يجب حفظ CSR ومعرف A والوقت والموقع والبايتات الموقعة ونتيجة التوقيع ومواد المسار. وعند الإصدار تحفظ بايتات A وتجزئتها وبايتات B ومقارنة الاستخدام والسياسة وتداخل الصلاحية.
وعند الاستخدام تحفظ الشهادات المستلمة فعلياً ونتيجتا المسارين وحساب العلاقة والإثباتات المنفذة والنمط المتفاوض عليه ونسخة السياسة وقرار الاتصال. الغاية ليست جمع كل شيء، بل معرفة أي سلطة وأي آلية أخفقت.
المصادر
- https://www.rfc-editor.org/rfc/rfc9763.html
- https://www.rfc-editor.org/rfc/rfc2986.html
- https://www.rfc-editor.org/rfc/rfc5280.html
- https://www.rfc-editor.org/rfc/rfc5652.html
- https://www.rfc-editor.org/rfc/rfc6019.html
- https://www.rfc-editor.org/rfc/rfc2397.html
- https://www.rfc-editor.org/rfc/rfc8551.html
- https://www.rfc-editor.org/rfc/rfc9883.html
- https://www.rfc-editor.org/rfc/rfc9955.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
