الخلاصة

  • يتيح RFC 9908 لخادم EST أن يثبت قيماً وأن يطلب أنواع حقول وأن يترك مواضع يكملها العميل في طلب PKCS #10 لاحق.
  • تثبت الاستجابة تعليمات بناء الطلب، أما التوقيع وحيازة المفتاح وتوثيق العميل والتفويض وقرار سلطة التصديق والشهادة المنشورة والاستخدام الفعلي فلكل منها سجل مستقل.

وصلت إلى الجهاز استجابة /csrattrs تحتوي على وحدة تنظيمية محددة، وتطلب منه أن يملأ الاسم الشائع، وتفرض المفتاح P-256، وتترك عنواناً فارغاً داخل الاسم البديل للموضوع. عندها أضاءت لوحة الإدارة حالة «الهوية معتمدة». لكن الجهاز لم يكن قد أرسل طلباً موقعاً، والخادم لم يوثق طالب التسجيل، وسلطة التصديق لم تطبق سياستها أو توقع شهادة.

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

يحدّث المستند بروتوكول EST في RFC 7030، وكذلك EST عبر CoAP في RFC 9148. كان بإمكان العميل أصلاً أن يسأل الخادم عن السمات التي تتوقعها سلطة التصديق. لكن لم يكن هناك فهم موحد لكيفية نقل القيم الفعلية، ولا سيما قيم امتدادات X.509. يوضح RFC 9908 الترميز القائم ويضيف قالباً مباشراً.

يشبه CertificationRequestInfoTemplate جزء المعلومات من طلب PKCS #10، لكنه لا يتضمن غلاف التوقيع ويجعل بعض الحقول اختيارية بقواعد واضحة. إنه مسودة ناقصة معدة لبناء الطلب؛ ليس طلب CSR كاملاً، وبالتأكيد ليس شهادة.

للوجود والغياب معنى. إذا لم يضع الخادم شرطاً على الاسم المميز للموضوع، يغيب subject. وإذا اشترط نوعاً من RDN، يظهر ذلك النوع. وجود القيمة يعني أن العميل يُتوقع منه استخدامها؛ أما وجود النوع بلا قيمة فيعني أن العميل يملأ قيمة مناسبة. ويغيب subjectPKInfo إن لم يشترط الخادم مفتاحاً، بينما يحدد وجوده الخوارزمية المطلوبة. ويمكن لقيمة مفتاح عامة مؤقتة أن تعبّر عن طول معامل RSA المطلوب.

يطبق id-aa-extensionReqTemplate المنطق نفسه على الامتدادات. يحدد الخادم هوية الامتداد، ويستطيع إعطاء قيمته كاملة أو تركها غائبة أو ملء جزء منها. وهكذا يمكن أن يحتوي SAN على اسم يقرره الخادم وموضع آخر يملؤه العميل. وتوضح حالة Autonomic Control Plane في RFC 8994 الحاجة إلى تمرير subjectAltName بعينه أثناء التسجيل.

تظل بنية CsrAttrs على السلك كما هي دعماً للتوافق. نسخة القالب v1، ولا يجوز تكرار id-aa-extensionReqTemplate أو جمعه مع id-ExtensionReq. هذه شروط للترميز والتشغيل البيني، لا براهين على أن اسماً ما مخول.

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

عند وصول CSR الموقع تبدأ اختبارات مختلفة. يوثق الخادم العميل ويتحقق من تفويضه لاستخدام الخدمة المطلوبة. ويقدم توقيع CSR، عندما تنطبق الآلية، دليلاً على حيازة المفتاح الخاص المقابل. ويمكن لـ EST ربط ذلك بالجلسة الموثقة عبر TLS. ويقدم RFC 5272 إطار CMC الأوسع لإثبات الحيازة وضوابط إدارة الشهادات.

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

يبقى الإصدار خاضعاً دائماً لسياسة سلطة التصديق المحلية. يسمح RFC 7030 بالمراجعة اليدوية وبإجابة HTTP 202 عندما يظل القرار معلقاً. ويشرح PKCS #10 أن السلطة توثق الطالب وتتحقق من التوقيع، ثم تبني الشهادة إذا اعتبرت الطلب صالحاً، مستخدمةً اختياراتها ومعلومات أخرى. لذلك يمكن رفض CSR صحيح البنية أو تأجيله أو تعديله.

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

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

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

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

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

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

تُذكّر أولوية الشيفرة العاملة لدى Heng Lu بأن نشر التعليمات ليس تنفيذاً. ويمنع مبدأ الحد الأدنى للمواصفة الأولية والقرار المستقبلي المحلي والتبني الطوعي تحول الدلالة المشتركة الضيقة إلى سلطة ضمنية.

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

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

المصادر