الخلاصة

  • يجعل RFC 9908 استجابة /csrattrs وصفاً دقيقاً لشكل طلب الشهادة، لا قائمة ملتبسة بأنواع السمات المقبولة.
  • يوضح ترميز معرّف الكائن OID مع القيمة، ولا سيما قيم امتدادات X.509، ويضيف بنية CertificationRequestInfoTemplate التي يستطيع الخادم ملء جزء منها.
  • يظل العميل مسؤولاً عن إنشاء زوج المفاتيح وCSR، كما تبقى المصادقة وسياسة هيئة التصديق منفصلتين عن القالب.

صدر RFC 9908 بوصفه IETF Proposed Standard في يناير 2026، وهو يحدّث RFC 7030 وRFC 9148. نقطة البداية هي آلية EST التي يتلقى فيها العميل سمات CSR قبل إرسال طلبه. كان الغموض السابق يترك مساحة واسعة لتفسيرات مختلفة لترميز السمات والقيم. التوضيح الجديد يربط OID بالقيمة المطلوبة بطريقة يمكن للعميل تنفيذها والتحقق منها، ويعالج خصوصاً قيم امتدادات X.509.

الآلية الأهم هي CertificationRequestInfoTemplate. يمكن للخادم أن يرسل قالباً جزئياً لـ CertificationRequestInfo: يثبت الاسم المميز للموضوع كله أو بعض مكوناته، ويترك للعميل ما لم يثبته. وجود حقل subject اختياري؛ يظهر عندما تكون لدى الخادم متطلبات لقيم RDN. وقد يحتوي أحد RDN على نوع الاسم من دون قيمة، وهو فراغ مقصود يعني أن العميل يورد قيمة مناسبة. أما إذا أورد الخادم قيمة RDN، فعلى العميل استعمالها، لا استبدالها بتخمين محلي.

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

تتضح الحاجة في بيئات ACP وBRSKI. تحتاج عملية الإقلاع الآمن إلى أن ينقل الخادم اسم subjectAltName محدداً عبر /csrattrs، وهو سياق يرتبط بـ RFC 8994 وRFC 8995. يحدد RFC 9908 شكل الطلب الذي ينبغي أن يبنيه العميل، لكنه لا يوقع CSR ولا يوافق عليه، ولا يستبدل مصادقة EST أو سياسة هيئة التصديق. كما لا يجوز قراءة الحقول الغائبة باعتبارها «غير مقيدة» من دون الرجوع إلى دلالات الحضور والغياب في القالب.

فحص التوافق على مستوى البايت

قبل قبول التنفيذ، ينبغي تسجيل الاستجابة الخام لـ/csrattrs ومقارنتها بترميز ASN.1 المتوقع: طول الرسالة، ترتيب الحقول، OID لكل سمة، وتمثيل القيمة ونوعها، ثم فك القالب وإعادة ترميزه للتحقق من ثباته. افحص على حدة الفرق بين subject الغائب، وsubject الحاضر مع RDN بلا قيمة، وRDN ذي القيمة التي فرضها الخادم. افحص أيضاً غياب subjectPKInfo، وخوارزمية المفتاح عند حضوره، والقيمة البديلة لطول RSA، مع التأكد من أنها لا تُنسخ كمفتاح نهائي. بعد ذلك قارن CSR الناتج، وامتدادات X.509 فيه، وسلسلة الشهادة بالمتطلبات التي حملها القالب. نجاح فك الترميز وحده ليس برهاناً كافياً.

مسار قرار المشغّل

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

المصادر