الخلاصة

  • يضع RFC 9646 استجابة HTTP 400 بين طلبي get-bootstrapping-data: إعلان القدرة، واختيار الخادم، وطلب CSR العائد سجلات مستقلة.
  • يثبت التحقق من توقيع CSR أن منشئه حاز المفتاح الخاص المقابل، لكنه لا يثبت وحده أصل الجهاز أو موافقة سلطة التصديق أو تثبيت الشهادة واستخدامها.
  • لأن csr-request ينتقل داخل خطأ HTTP لا يمكن توقيعه مثل بيانات RFC 8572، فلا يجوز استخدام الآلية مع خادم تمهيد غير موثوق.

التوقيع الصحيح هو بداية التحقيق

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

في الطلب الأول يرسل عميل SZTP عقدة csr-support. يعلن إن كان يستطيع إنشاء مفتاح غير متماثل جديد، والخوارزميات التي يدعمها، وصيغ CSR التي يستطيع إنتاجها. إذا أراد الخادم طلبًا، يرد بحالة HTTP 400 ويضع بنية csr-request داخل error-info في RESTCONF. تختار البنية الخوارزمية والصيغة وقد تتضمن معلومات مطلوبة للشهادة.

ينفذ الجهاز الاختيار ثم يرسل طلبًا ثانيًا يحمل p10-csr أو cmc-csr أو cmp-csr. عندها يتحقق الخادم أو سلطة التسجيل أو سلطة التصديق من الطلب. وإذا وافقت السياسة، قد تعيد معلومات الإدخال شهادة موقعة.

لهذا فإن 400 ليس حكمًا نهائيًا بالفشل. إنه حالة خطأ وفق HTTP، لكنه انتقال متوقع في هذه الآلية. كما أنه ليس موافقة على الهوية. حفظ لون الحالة دون محتوى csr-request يمحو القرار، وحفظ القرار دون معنى الحالة يمحو سياق النقل.

إعلان القدرة لا يثبت التنفيذ

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

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

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

حيازة السر ليست إثبات الأصل

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

إثبات الأصل يسأل: أي جهاز أو صاحب صلاحية أنشأ الطلب؟ لا يوفر PKCS #10 الخام مصادقة للأصل داخل البنية. قد تأتي المصادقة من هوية العميل على TLS أو HTTP. لذلك يجب حفظ سياق الجلسة وربطه بملف CSR؛ فالملف المنفصل يحتفظ بالحيازة ويفقد الأصل.

يدعم CMC وCMP مصادقة الأصل باستخدام PKI أو سر مشترك، ويمكنهما المرور بسلطة تسجيل قبل CA. لكنهما لا يصدران الشهادة تلقائيًا. يجب التحقق من مسار IDevID أو مرجع السر أو حماية البروتوكول، ثم تطبيق سياسة الإصدار.

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

الجِدة والحماية ليستا الخاصية نفسها

يوصي RFC 9646 بمفتاح خاص جديد لكل CSR. إذا أُنشئ فعلًا بعد طلب الخادم، تعمل عشوائيته كقيمة شبيهة بـ nonce. وعندما تحتوي الشهادة العائدة على المفتاح العام الجديد، يحصل الجهاز على دليل يربط الرد بالدورة الحالية.

لكن إعلان key-generation لا يثبت الجِدة إذا تكررت البصمة. كما أن المفتاح الجديد قد يكون أضعف حماية. إذا تعذر على الجهاز حماية المفتاح الجديد بمستوى مفتاح المصنع المدمج، يوصي RFC بإعادة استخدام المفتاح المحمي أفضل. تقلل الجِدة بعض مخاطر الإعادة، بينما تقلل الحيازة داخل HSM بعض مخاطر انتحال الهوية.

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

الرسالة غير الموقعة ترسم حد الثقة

يسمح RFC 8572 للعميل بالاتصال بخادم لم يثق به بعد والاعتماد على بيانات تمهيد موقعة. لا يرث csr-request هذه الحماية لأنه يوجد في رسالة خطأ HTTP لا يمكن توقيعها كبيانات التمهيد.

والنتيجة صريحة: لا تستخدم آلية CSR مع خادم غير موثوق. لا ينبغي للعميل إرسال csr-support إليه، بل يفضل signed-data-preferred. هذا حد للسلطة، لا مجرد خيار تسجيل.

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

الإصدار والتسليم والتثبيت والاستخدام

بعد استلام CSR، تتحقق البنية من الحيازة والأصل والجرد والسمات، ثم توافق RA أو CA أو ترفض. لا يحل توقيع CSR محل هذا القرار.

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

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

تعطي أولوية الشيفرة العاملة للوه هنغ الوزن لما نُفذ وظهر أثره. يصف YANG التبادل، بينما تنتج CA ومخزن الجهاز والخدمة حقائق مختلفة.

وصل الأدلة دون دمجها

ابدأ بهوية خادم التمهيد ومسار الثقة وحقائق TLS وHTTP وسبب اختيار csr-support أو signed-data-preferred. احفظ nonce وبيانات الجهاز والخوارزميات والصيغ في الطلب الأول.

سجل 400 كانتقال بروتوكولي مع csr-request الكامل والاختيار والمحتوى والوقت ومعرف الارتباط. وسجل للمفتاح: إنشاء أم إعادة استخدام، البصمة العامة، دليل العشوائية أو HSM، حد حماية السر، وحكم الجِدة.

في الطلب الثاني احفظ صيغة CSR وملخصه. أعط حكمين منفصلين للحيازة والأصل، وسمِّ مسار IDevID أو السر أو هوية TLS أو HTTP. ثم أضف قرار RA/CA وبصمة الشهادة وطريقة نقلها وتثبيتها وأول استخدام وتدويرها أو محوها.

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

Sources