من أجاز تدوير مرساة Company-Certs؟

Summary

تقترح مسودّة إنترنت فردية المسار /.well-known/company-certs لاكتشاف مراسي ثقة خاصة بتطبيق معين عبر HTTPS، من دون إدخالها في مخزن الثقة العام لنظام التشغيل.
مصادقة المصدر وصلاحية مسار X.509 واختيار السلسلة ذات valid_from الأحدث لا تثبت أن الجهة التنظيمية المختصة أجازت الاستبدال. أثناء فترة التداخل قد تتغير الثقة الفعلية قبل أن يصبح هذا التفويض قابلا للإثبات.
يقترح Daniel Kade وصل تغيير لمرساة الثقة يجمع نسخة البيانات الدقيقة وبصمتي المرساة القديمة والجديدة والنطاق وفترة التداخل وسلطة الموافقة وسياسة العميل والتأكيد المستقل وخطة التراجع. هذا اقتراح تحريري لا مطلب صادر عن IETF.

التدوير السليم يكشف الفجوة

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

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

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

ما الذي تقترحه المسودّة فعلا

draft-doehle-company-certs-discovery-00 مسودّة إنترنت فردية مؤرخة في 22 يوليو 2026 ومقصود بها مسار المعايير. لم يكن لها عند موعد البحث سوى النسخة -00. ليست RFC ولا دليلا على إجماع IETF أو نشر إنتاجي.

تضع الآلية كائن JSON ذا إصدار في /.well-known/company-certs. يحتوي على authority_information وtrust_anchors. ترتبط كل مرساة بـusage_context وبسلسلة واحدة أو أكثر من certificate_chains. وقد تتضمن السلسلة valid_from وvalid_until ورابط HTTPS من المصدر نفسه وسلسلة X.509 بصيغة PEM ومراجع CRL أو OCSP وبصمة SHA-256.

للنطاق قيود مهمة. يجب أن تكون قيمة permitted_domains مطابقة لمعرف DNS في شهادة TLS التي تحقق منها العميل أو فرعا منه. ويعبر isolated_store_required عن رغبة الناشر في إبقاء المرساة داخل مخزن منعزل خاص بالاستخدام. إذا لم يستطع العميل تحقيق العزل فعليه الرفض.

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

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

المصدر ليس خريطة الصلاحيات الداخلية

ينظم RFC 8615 فضاء عناوين well-known، ويحذر من أن حق الكتابة إلى مورد من هذا النوع قد يمثل حق الكلام باسم المصدر كله. في الاستضافة المشتركة أو بيئات الأذونات المعقدة قد تكون صلاحية تبدو صغيرة أوسع أثرا مما توقعه مشغلها.

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

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

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

الوقت الأحدث قاعدة اختيار لا توقيع موافقة

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

يسهل RFC 3339 تمثيل الوقت بطريقة متوافقة. لا يشرح التاريخ الصحيح من وضعه ولا سبب فترة التداخل ولا موافقة الفرق المعنية. يستطيع ناشر مشروع أو مخطئ أو مخترق أن يكتب قيمة أحدث صحيحة نحويا.

ولا يسد RFC 5280 الفجوة. يأخذ التحقق من المسار مراسي الثقة والسياسات المحلية كمدخلات، ثم يقرر صلاحية السلسلة تحتها. لا يدقق في العملية التي أدخلت المرساة إلى مجموعة المدخلات.

المشكلة إذا ليست في قاعدة الأحدث. الخطأ يحدث عندما يحول التقرير «اختار العميل السلسلة وفق السياسة» إلى «أجازت المؤسسة المرساة الجديدة». الفعلان يحتاجان دليلين مختلفين.

العزل سلوك يجب اختباره

isolated_store_required تعبير عن نية الناشر وليس حاجزا تقنيا. يعرف العميل ما إذا كانت بنيته تستطيع إبقاء المرساة منفصلة. وجود القيمة true لا يكفي لإثبات العزل.

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

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

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

استجابة حديثة قد تحمل تفويضا منتهيا

يفصل RFC 9110 وRFC 9111 بين دلالة HTTP وحداثة الذاكرة وإعادة التحقق. تدعو المسودّة إلى تخزين متحفظ ومراجعة دورية ومقاومة إعادة العرض والبيانات القديمة، وتسمح للعميل بحد محلي للحداثة.

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

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

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

حالة الشهادة لا تشرح حالة التفويض

يمكن للبيانات أن تشير إلى CRL أو OCSP. يقدم RFC 6960 معلومات عن حالة الشهادات، وهو تحكم مهم في دورة حياتها. لكنه لا يسجل من أجاز تغيير مجموعة المراسي.

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

وحذف العنصر من المصدر لا يصحح فورا الذاكرات والعملاء غير المتصلين والجلسات الطويلة والنسخ التي غادرت المخزن المعزول. يلزم تحديد المجتمعات والمهلة القصوى ودليل الإغلاق.

وصل تغيير مرساة الثقة

يقترح Daniel Kade وصل تغيير لمرساة الثقة لكل انتقال جوهري في Company-Certs. ليس حقلا عاما جديدا تفرضه المسودّة ولا قاعدة من IETF. إنه سجل تشغيلي يصل النشر بالتفويض والقرار المحلي.

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

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

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

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

تأكيد يناسب أثر القرار

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

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

RFC 5011 مقارنة محدودة فقط. يستخدم حالات إضافة وانتظار وإزالة في تحديث مراسي DNSSEC الآلي، ولا يحكم Company-Certs. الدرس الضيق هو أن البرنامج الذي يغير أساس ثقته يحتاج إلى ذاكرة انتقال دائمة لا إلى قيمة «حالية» واحدة.

الحفاظ على الأفعال منفصلة

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

لا تثبت المصادر تنفيذا مسمى أو حادثة أو تدويرا مسيئا. مشهد البداية اختبار تصميم مستمد من قاعدة تعدد السلاسل، لا اتهام لمؤسسة.

تحافظ العملية الناضجة على الأفعال: يصادق HTTPS على الاسترجاع، ويمثل JSON البيانات، ويتحقق X.509 من المسار تحت مدخلات محلية، وتختار سياسة العميل مرساة، وتجيز سلطة المؤسسة التغيير. يصل الوصل هذه الحقائق ولا يسمح لإحداها بأن تتحدث باسم البقية.

نقطة Company-Certs لا تثبت من أجاز تدوير مرساة الثقة

لماذا هذا مهم

Summary

التدوير السليم يكشف الفجوة

ما الذي تقترحه المسودّة فعلا

المصدر ليس خريطة الصلاحيات الداخلية

الوقت الأحدث قاعدة اختيار لا توقيع موافقة

العزل سلوك يجب اختباره

استجابة حديثة قد تحمل تفويضا منتهيا

حالة الشهادة لا تشرح حالة التفويض

وصل تغيير مرساة الثقة

تأكيد يناسب أثر القرار

الحفاظ على الأفعال منفصلة

المصادر

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

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

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

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

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