الخلاصة

  • يصف RFC 9932 بيانات وصفية موقّعة للاتحاد وpins محمّلة مسبقاً ومصادقة TLS متبادلة بين الآلات؛ وهو RFC معلوماتي ناتج عن تقديم مستقل، لا معيار IETF ولا دليل على تشغيله في خدمة بعينها.
  • صلاحية البيانات وتطابق مفتاح الشهادة والهوية المستمدة من TLS أدلة محددة الحدود. قد تغذي سياسة محلية، لكنها لا تثبت أن التطبيق أجاز طلباً أو نفّذه أو حقق أثراً معيناً.

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

يستحق وضع RFC 9932 أن يسبق تفسير آليته. فوثيقة Mutually Authenticating TLS in the Context of Federations منشورة بوصفها Independent Submission لأغراض معلوماتية. لا تعدّل TLS، ولا تمثل إجماع مجتمع IETF، ولا تخبرنا بأن شبكة أو خدمة ما نشرتها بالفعل. موضوعها أضيق: طريقة تتيح لأعضاء اتحاد أن يتعرفوا إلى أقرانهم في اتصال TLS آلة-إلى-آلة باستخدام جذر ثقة تديره الجهة الاتحادية وبيانات تصف الأعضاء وتُوزع وفق قواعد محددة. هذه الحدود ليست تفصيلاً قانونياً؛ فهي تمنع القارئ من تحويل وصف تصميم إلى إقرار عن العالم التشغيلي.

أول سجل في السلسلة هو تجميعة البيانات الوصفية. يجمع مشغّل الاتحاد معلومات الأعضاء وينشرها بصيغة JSON Web Signature. قد تضم التجميعة معرفات الكيانات، وعناوين endpoints، ومادة المصدر المصدّق، وpins، ووقتي الإصدار والانتهاء، وقواعد التخزين المؤقت. توقيعها يثبت أمراً ضيقاً: أن كائناً معيناً صدر عن مفتاح توقيع قرر القارئ مسبقاً أن يثق به. لا يثبت أن نسخة القارئ هي الأحدث، أو أن برنامج الاتصال استشارها، أو أن endpoint المقصود اختير، أو أن سياسة التطبيق لا تزال تسمح للفعل الذي يليه.

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

السجل الثاني هو التحقق من النظير. قبل الاتصال، يحمل العضو pins للـ endpoints التي اختار الاتصال بها أو قبولها. وخلال تبادل TLS تقارن الجهة المفتاح العام في شهادة النظير بالـ pin المنشور لذلك endpoint. عدم التطابق يستلزم إنهاء الاتصال. هذه قاعدة ذات أثر واضح: تمنع نظيراً لا يحقق سياسة المفتاح المعلنة. لكنها لا تثبت أن جلسة ناجحة وقعت لمجرد أن pin موجود في ملف، ولا تثبت أن التطبيق بعد المصافحة سيسمح بقراءة أو كتابة أو أمر إداري.

تظهر الحدود بوضوح أكبر مع الوسيط. إذا أنهى proxy اتصال TLS، فلا يجوز للتطبيق الذي خلفه أن يتخذ من HTTP header أرسله النظير أو من حقل يختاره العميل هوية موثقة. على الوسيط أن يتحقق من pin بنفسه أو أن يمرر الشهادة أو pin المشتق أو entity_id عبر قناة محمية من العبث ومصادق على طرفيها. يقول RFC 9932 إن هذه المعلومات تُنقل لتمكين التفويض. الصياغة تحدد الترتيب: الهوية الناتجة عن TLS سابقة لقرار التطبيق. قد تصبح مدخلاً في قاعدة التفويض، لكن القاعدة ومقيّمها والطلب ونتيجته تبقى سجلات أخرى.

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

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

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

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

المصادر