ينقل RFC 9925 ثقة X.509 إلى خارج الشهادة

الخلاصة

نُشر RFC 9925 في فبراير/شباط 2026 معياراً مقترحاً من IETF، وعرّف id-alg-unsigned بوصفه خوارزمية X.509 تُحذف معاملاتها وتكون قيمة توقيعها بطول صفر.
يحمل الملف معلومات الموضوع من دون إثبات صادر عن جهة إصدار. وقد يمتلئ حقل المُصدر للتوافق، لكن ذلك لا يجعل الكائن موقّعاً ذاتياً أو صادراً عن نفسه.
يمكن أن تقبل الكائن تطبيقات لا تتحقق من توقيع X.509 في سياقها المحدود. أما مدقق مسار الشهادات فعليه أن يرفض id-alg-unsigned حين يكون التوقيع مطلوباً.
قد يقلل حذف توقيع ذاتي شكلي من حجم توقيعات ما بعد الكم، ومن إعادة استخدام المفتاح بين بروتوكولات مختلفة، كما يتيح مفاتيح KEM التي لا تستطيع التوقيع. ليس هذا تجاوزاً أمنياً، بل إظهار لحافة ثقة غير موجودة.
لذلك يجب أن تأتي الثقة والسلامة والسلطة من آلية أخرى. وينبغي لوصلٍ عن أصل الثقة ونطاقها أن يربط البايتات الدقيقة بالدليل الخارجي، والمُثبّت، ومخزن الثقة، والاستخدام المسموح، وسجل التغيير، ومسار الإزالة.

شهادة تُرك فيها حقل الإثبات فارغاً عمداً

أكثر الأرقام دلالة في RFC 9925 هو الصفر.

تستخدم الشهادة غير الموقعة معرّف الكائن 1.3.6.1.5.5.7.6.36 للدلالة على id-alg-unsigned. لا توجد معاملات للخوارزمية، وتكون signatureValue سلسلة BIT STRING بطول صفر. تبقى بنية X.509 لأنها حاوية واسعة الدعم لاسم الموضوع ومفتاحه العام والامتدادات. لكنها لا تطلب من المحلل أن يتظاهر بأن مُصدراً ما صدّق على تلك الحقول تشفيرياً.

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

الحد فاصل ونظيف: قد يكون الكائن مفيداً من الناحية النحوية، لكنه غير صالح في الوقت نفسه ليكون حافة تشفيرية في رسم الثقة. ومن هنا تبدأ مسألة الحوكمة. فكثيراً ما تستعير واجهات الأمن معنى السلطة من شكل مألوف. قد يظهر ملف اسمه «شهادة» مع مُصدر وفترة صلاحية ورمز أخضر، وقد يُعد في الجرد بجانب أوراق اعتماد صادرة عن سلطة شهادات. وربما يتذكر المشغّل أنه جاء في صورة جهاز موثوقة، ثم يضيع سجل الشخص الذي أجاز تلك الصورة. لا يفرض RFC 9925 أياً من هذه الأخطاء؛ دقته هي التي تجعلها أسهل رؤية.

بقيت العقدة واختفت الحافة

يقدم RFC 9925 نموذجاً بيانياً مناسباً. تربط شهادة X.509 العادية طرفين: معلومات عن موضوع، وإثباتاً من مُصدر. في رسم البنية التحتية للمفاتيح العامة يكون الموضوع والمُصدر عقدتين، وتكون الشهادة الموقعة حافة بينهما.

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

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

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

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

قد يبقى حقل المُصدر الممتلئ مجرد عنصر نائب

الحقل الأصعب ليس التوقيع الفارغ، بل اسم المُصدر المكتوب.

تتطلب صياغة X.509 وجود حقل issuer ولا تسمح بأن يكون خالياً. كما تتوقع تطبيقات قائمة أن تتطابق أسماء subject وissuer في تمثيل مرساة الثقة. لذلك يسمح RFC 9925 للمرسل بنسخ اسم الموضوع إلى حقل المُصدر، أو باستعمال اسم قصير مخصص ليكون عنصراً نائباً.

لا ينشئ أي من الخيارين مُصدراً. لا توقيع، فلا توقيع ذاتي؛ ولا علاقة إصدار، فلا إصدار ذاتي. إذا عرضت الشاشة العنصر النائب تحت عبارة «صادر عن» من دون توضيح، تحوّل خانة نحوية إلزامية إلى ادعاء مؤسسي. وإذا رسم عارض المسار حلقة من الموضوع إلى نفسه، أعاد صنع الحافة التي حذفها المعيار.

هذه صورة دقيقة لمبدأ Policy Mirror لدى Lu Heng: ينبغي للسجل أن يعرض السلطة والحدث الموجودين، لا ما توحي به قواعد قديمة. فالامتدادان authority key identifier وissuer alternative name يصفان مُصدراً، ولذلك ينبغي عادة حذفهُما. ويمكن لـ key usage وbasic constraints أن يصفا قدرة الموضوع، حتى قدرته التقنية على العمل كسلطة شهادات. لكن القدرة لا تمنح إذناً بتثبيته مرساةً للثقة. وصف ما يستطيع المفتاح فعله لا يساوي قرار الاعتماد عليه.

التسجيل ليس تحققاً

سجلت IANA قيمة id-alg-unsigned. يتيح التخصيص لأنظمة مستقلة أن تتعرف إلى القيمة وتصل إلى المواصفة. لكنه لا يجعل التوقيع الفارغ صحيحاً، ولا يصادق على الموضوع، ولا يجيز تغييراً في مخزن الثقة.

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

يحذر RFC 9925 من موضع الفشل: إذا قبل تطبيق المعرّف غير الموقّع داخل مسار شهادات، أو في أي سياق يلزم فيه التحقق من توقيع X.509، فقد تجاوز الفحص. ويقدم RFC 8725 المبدأ الأوسع في نظام رموز آخر: على المستدعي اختيار الخوارزميات المدعومة، وعلى العملية الفعلية أن تتطابق مع الخوارزمية المعلنة. يستطيع سجل خوارزميات تسمية الحالة، لكنه لا ينفذ الانتقال الصحيح داخل كل منتج. يقع ذلك الإثبات على الاختبارات والإعداد والسجل التشغيلي.

لماذا قد يكون حذف التوقيع أكثر أماناً

قد يبدو تعبير «شهادة غير موقعة» وكأنه إضعاف. في السياق المقصود قد يكون العكس أصح.

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

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

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

انتقلت سلطة الثقة إلى المُثبّت

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

تكشف هذه التفاصيل انتقال الحكم. فعندما لا يحمل الملف إثباتاً من مُصدر، لا يعود الشخص أو النظام الذي يثبته مجرد ناقل. إنه يتخذ قرار الثقة النافذ.

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

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

وصل أصل الثقة ونطاقها

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

ثم يسجل الأصل: من أي مستودع أو صورة جهاز أو حزمة أو إجراء رسمي أو مسؤول جاء؟ أي بصمة خارجية أو توقيع أو قناة محمية أو مقارنة مادية أثبتت سلامته؟ ما الدليل الذي صادق على المصدر، وما القاعدة التي أثبتت حق المصدر في توفير معلومات الثقة؟

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

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

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

حدود الأدلة

لا تثبت المصادر التي جرت مراجعتها مدى انتشار RFC 9925، ولا تسمي المنتجات التي تدعمه، ولا تثبت أن تنفيذاً أخطأ في التعامل معه. يبين ميثاق LAMPS المعتمد استمرار العمل على آليات PKIX وS/MIME لما بعد الكم، لكنه ليس قياساً للنشر. وتثبت سجلات IANA تخصيص القيمة، لا صحة المعالجة.

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

ما يمكن إثباته أضيق وكافٍ: فصل RFC 9925 عمداً بيانات الموضوع عن إثبات المُصدر، وألزم مدقق المسار برفض القيمة الفارغة، ووضع السلامة والثقة خارج الكائن. هذا حد تقني سليم. وينبغي للحوكمة أن تجعل النصف الخارجي قابلاً للفحص بالوضوح نفسه.

جعل RFC 9925 شهادة X.509 بلا توقيع، ويجب أن تأتي الثقة من مكان آخر

لماذا هذا مهم

الخلاصة

شهادة تُرك فيها حقل الإثبات فارغاً عمداً

بقيت العقدة واختفت الحافة

قد يبقى حقل المُصدر الممتلئ مجرد عنصر نائب

التسجيل ليس تحققاً

لماذا قد يكون حذف التوقيع أكثر أماناً

انتقلت سلطة الثقة إلى المُثبّت

وصل أصل الثقة ونطاقها

حدود الأدلة

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات