الخلاصة

  • تميّز RFC 9810 بين accepted، أي حصول الطالب على ما طلبه بالضبط، وgrantedWithMods، أي حصوله على شيء مشابه مع تحمّله مسؤولية اكتشاف الفروق.
  • تثبت حماية رسائل CMP مصدر الاستجابة واستمرار المعاملة، لكنها لا تثبت أن الاسم وSAN ومدة الصلاحية وKey Usage وEKU والقيود والسياسة ما زالت تطابق النية المأذون بها.
  • يمكن لإيصال محلي لنية الشهادة أن يربط الطلب والشهادة الصادرة وفروق الحقول وسلطة كل تعديل وقرار القبول أو الرفض من دون حفظ المفتاح الخاص. هذا اقتراح تحريري من Daniel Kade وليس حقلاً في CMP.

تبدو كلمة «مُنحت» نهائية. تحققت حماية الرسالة، وتطابق رقم المعاملة، وأصدرت جهة التصديق شهادة قابلة للتحليل. إلا أن RFC 9810 لا تضع كل نتيجة إيجابية في خانة واحدة. فهي تفصل بين تحقيق الطلب كما هو وبين منحه بعد تعديلات.

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

قالب الطلب يصف المقصود ولا يأمر جهة التوقيع

نُشرت RFC 9810 في يوليو 2025 ضمن مسار معايير IETF، وتصف بروتوكول إدارة شهادات X.509 بين الكيانات النهائية ومكونات البنية التحتية للمفاتيح العامة، ومنها سلطات التسجيل RA وسلطات التصديق CA. وهي تحل محل RFC 4210، وتحل مع RFC 9811 محل RFC 9480 أيضاً.

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

لكن اكتمال القالب لا يلزم الجهة بنسخة مطابقة. تنص RFC 9810 على أن CA حرة في تعديل حقول الشهادة الفعلية حتى لو حدّد المنشئ كل ما يريده. ولذلك تعني accepted أن النتيجة هي المطلوب بالضبط، بينما تعني grantedWithMods أن النتيجة قريبة وأن على الطالب تحديد الفروق.

هذه ليست نهاية الحكم بل بدايته عند الطالب. إذا حوّل النظام الحالتين إلى قيمة نجاح واحدة ثم ثبّت الشهادة، يكون قد منح الإعداد الافتراضي سلطة قبول لم تُنسب إلى دور مسؤول.

فرق الحقل قد يكون فرقاً في السلطة

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

يفصل Key Usage بين التوقيع الرقمي وتشفير المفتاح واتفاق المفاتيح وتوقيع الشهادات وتوقيع قوائم الإبطال. ويحدد Extended Key Usage أغراضاً إضافية. ويفصل Basic Constraints بين كيان نهائي وسلطة تصديق وقد يقيّد مسار الثقة. ويمكن لـSAN أن يحدد هوية خدمة، فيما تعطي سياسات الشهادة إطاراً لقرار الأطراف المعتمدة.

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

تعطي RFC 9810 مثالاً صريحاً: إصدار شهادة تحتوي EKU لأدوار إدارة PKI قد يفوض صلاحية كانت أصلاً في شهادة CA. تصف الوثيقة هذا بأنه إجراء حساس يستلزم عناية خاصة حتى لا تحصل عليه إلا جهة مشروعة. هنا لا يكون التعديل تجميلياً، بل انتقالاً للصلاحية.

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

صحة مصدر الرسالة لا تعني صحة النية

يربط CMP الرسائل بحماية وتعرّف للمعاملة وnonces. وقد يستخدم سراً مشتركاً أو توقيعاً. وتبين Proof-of-Possession سيطرة الطالب على المفتاح الخاص المقابل. ويمكن لـRA التحقق من الطلب وتفويضه وحمايته ونقله أو تعديله وفق القواعد.

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

إذا عدّلت RA الطلب، فيجب أن يميز الأثر بين قيمة الكيان النهائي، وما غيرته RA، وما وقّعته CA، والأساس الذي سمح بكل فرق جوهري. عبارة «تحققت RA» لا تحفظ هذه السلسلة، ولا تكشف موضع انتقال القرار.

تأكيد الشهادة قرار بقبول جسم محدد

يسمح certConf للعميل بقبول الشهادات الواردة أو رفضها. غياب statusInfo عن شهادة مذكورة يعني قبولها. وغياب بنية CertStatus المقابلة يعني رفضها، ويمكن لتسلسل فارغ رفض جميع الشهادات. كما يمكن إرفاق بصمة الشهادة بحالة رفض صريحة.

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

يعرض الملف الخفيف في RFC 9483 مسار الحالة. بعد accepted أو grantedWithMods يُرسل certConf ثم pkiConf، ما لم يُطلب التأكيد الضمني ويُمنح. وإذا لم يصل التأكيد المتوقع في وقته، يُعامل الأمر كرفض.

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

السياسة تشرح لماذا يجوز التعديل

تميز RFC 3647 بين Certificate Policy التي تعلن متطلبات لفئة من التطبيقات، وCertification Practice Statement التي تصف كيف تنفذ CA إجراءاتها وضوابطها. لا تستطيع حالة CMP واحدة حمل كل المبررات المؤسسية لحقول الشهادة.

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

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

شفافية النشر لا تمنح إذن التشغيل

تجعل Certificate Transparency الإصدار قابلاً للرؤية. تصف RFC 9162 سجلات إلحاق فقط تسمح بتدقيق نشاط CA واكتشاف شهادات مشبوهة، لكنها توضح أن السجلات لا تمنع الإصدار الخاطئ بذاتها.

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

ثم يأتي التثبيت والثقة. قد تُقبل الشهادة ولا تُستخدم. وقد تُثبت لخدمة وترفضها خدمة أخرى. وتطبق الأطراف المعتمدة قواعدها. الرؤية العامة قيمة، لكنها ليست سلطة قبول عامة.

إيصال النية يحفظ الفروق من دون حفظ الأسرار

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

ثم يقارن المفتاح العام والموضوع وSAN والمدة وKey Usage وEKU وBasic Constraints والسياسات والقيود المناسبة وصفة critical والامتدادات التي يعتمد عليها التطبيق. ويُعطى كل فرق جوهري تصنيفاً: متوقع في الملف، وافق عليه دور مختص، مرفوض، أو غير محلول. وتبقى نسخة المقيم والسياسة قابلة للتتبع.

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

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

يجب أن يحتفظ التنفيذ بالفرق الذي احتفظ به البروتوكول

يفصل منهج Heng Lu بين المواصفة والقرار المحلي والتبني والتنفيذ والنتيجة الملحوظة. يحدد RFC الحالات، وتقرر CA ما توقعه، ويقرر الطالب ما يقبله، ويقرر مالك الخدمة ما يشغله، ثم تقرر الأطراف المعتمدة ما تثق به. لا يمكن لنجاح مرحلة أن يتكلم باسم البقية.

ولا تعني أولوية الكود الجاري أن ما ثُبّت آلياً يصبح مشروعاً. تعني أن الانتقال الفعلي يجب أن يبقى قابلاً للمقارنة بالقاعدة المعلنة. إذا دمج العميل accepted وgrantedWithMods في لون واحد، يكون التنفيذ قد حذف معلومة حوكمة قدمها البروتوكول.

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

المصادر