الخلاصة

  • يجمع BRSKI-AE بين إثبات حيازة المفتاح الجديد وإثبات منشأ يستند إلى IDevID المثبّت عند التصنيع، كي تستطيع سلطة تسجيل بعيدة التحقق بعد التخزين أو العبور عبر وسطاء.
  • الكائن الموقّع مادة لقرار التفويض، وليس القرار نفسه. وحتى عند إسناد عمل سلطة التسجيل إلى نظام خلفي، تُبقي RFC 9733 مسجّل النطاق طرفاً في قرار انضمام الجهاز.
  • القسيمة، وموافقة المسجّل، وقرار سلطة التسجيل، وإصدار الشهادة، والتأكيد، وقياس حالة التسجيل، والقبول التشغيلي سجلات مستقلة. جمعها في حالة واحدة اسمها «تم الضم» يصنع نتيجة لم تُرصد.

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

تعالج RFC 9733 هذا السؤال بجعل طلب التصديق كائناً موثّقاً قائماً بذاته. يحمل الطلب دليلاً على أن الـPledge يملك المفتاح الخاص الجديد، ودليلاً آخر على أن منشأه هو الجهاز صاحب IDevID المصنعي. يمكن التحقق من الدليلين بعد التأخير وعبر عدة نقلات.

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

امتلاك المفتاح لا يجيب عن هوية صاحبه

إثبات الحيازة يختبر العلاقة بالمفتاح. يوقّع طلب PKCS #10 نفسه عادة بالمفتاح الخاص المقابل للمفتاح العام المطلوب تصديقه. ويدعم CRMF أساليب أخرى، منها ما يلائم مفاتيح لا تستطيع التوقيع. النجاح يثبت الوصول إلى السر، لا أكثر.

أما إثبات الهوية، أو إثبات المنشأ بتعبير RFC 9733، فيربط الطلب باعتماد معروف سابقاً. في BRSKI-AE يكون ذلك عادة توقيعاً بسر IDevID يغطي الطلب ومعرّفاً قوياً للجهاز. فالمفتاح الجديد لا يكتسب هوية لمجرد أنه أثبت ملكيته لنفسه.

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

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

لماذا يجب أن يبقى الدليل بعد الوصلة الأولى

يربط EST في BRSKI التقليدي طلب PKCS #10 بمصادقة العميل داخل جلسة TLS بين الجهاز والمسجّل. يفيد ذلك الطرف المباشر، لكن سلطة تسجيل أخرى خلف المسجّل قد لا ترى الجلسة ولا تستطيع إعادة فحص ذلك الربط العابر.

يستخدم BRSKI-AE بروتوكول تسجيل يوثّق رسائله على مستوى الكائن. ويستعمل التطبيق المعياري CMP وفق ملفه الخفيف. تحمي بنية PKIMessage منشأ IDevID، فيما يثبت CRMF أو PKCS #10 حيازة مفتاح LDevID. وهكذا يمرر المسجّل الطلب الأصلي بدلاً من تحويل جلسة انتهت إلى ادعاء يجب على الخلفية تصديقه.

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

ومع ذلك، لا يلغي استقلال الرسالة أمن النقل. تبقي RFC 9733 قناة TLS أو DTLS بين الـPledge والمسجّل، بينما تترك نقل الرسائل من المسجّل إلى البنية الخلفية خارج نطاقها. سلامة رسالة CMP وأصالتها لا تشفران محتواها تلقائياً. ومن دون سرية إضافية قد يعرف متجسس الأجهزة التي يجري ضمها أو يحجب بعضها انتقائياً.

القسيمة تعيّن جهة الثقة، ولا تمنح LDevID

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

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

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

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

إسناد الفحص لا يسمح بتجاوز المسجّل

تسمح RFC 9733 للمسجّل بإسناد بعض وظيفة سلطة التسجيل أو كلها إلى نظام آخر، لكنها تشترط بقاءه في قرار ضم الـPledge إلى النطاق. لا يجوز للجهاز أن يسلك طريقاً مباشراً إلى سلطة التصديق متجاوزاً بوابة النطاق.

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

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

ويحدد الفصل موضع الخطأ: فشل IDevID في طبقة المنشأ، وغياب الموافقة عند المسجّل، وعدم ملاءمة الملف عند سلطة التسجيل، وخطأ محتوى الشهادة عند سلطة التصديق. وصفها كلها بأنها «مشكلة PKI» يحجب طريق الإصلاح.

الطابور غير المتزامن لا يوقف تغير الواقع

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

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

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

بعد رد الشهادة تبقى نهايات متعددة

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

ويبقي BRSKI، على نحو مستقل، قياس حالة التسجيل الإلزامي بين الجهاز والمسجّل. تفصل RFC 9733 المرحلتين. يخبر تأكيد CMP البنية العامة للمفاتيح بتقييم الجهاز للشهادة؛ وتخبر تليمترية BRSKI المسجّل بنتيجة التسجيل. إقرار استلام التأكيد لا يثبت استخدام الشهادة.

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

الحالة الصادقة تسمي آخر حد ثبت: قسيمة مقبولة؛ حيازة ومنشأ متحققان؛ موافقة مسجّلة؛ قرار RA إيجابي؛ إصدار CA؛ تأكيد الجهاز؛ وصول التليمترية؛ قبول التشغيل ما زال غير مختبر.

العثور على باب لا يثبت سلطة من خلفه

تعمم RFC 9733 المسارات إلى /.well-known/<enrollment-protocol>/<request> وتسجل brski-reg-cmp لاكتشاف مسجّل يدعم CMP بصورة مبسطة. يمكن للـPledge تجربة النقطة وقراءة حالة HTTP لمعرفة دعم العملية.

هذا اكتشاف قدرة، لا اكتشاف شرعية. وجود اسم الخدمة لا يثبت أن المسجّل هو الصحيح لهذا الجهاز، وتسجيل IANA لا يثبت التنفيذ أو المطابقة. وقد يعني نجاح HTTP وصول الغلاف فقط بينما معاملة CMP تنتظر أو تُرفض. يجب ربط النقطة والطرف TLS ومرساة النطاق والبروتوكول والمعاملة وصاحب القرار.

لا تثبت المصادر المجمدة أن مصنعاً أو سكة حديد أو محطة كهرباء أو شبكة شحن بعينها نشرت RFC 9733. الأمثلة تفسر الحاجة الهندسية ولا تعلن نتيجة إنتاجية.

المصادر