الخلاصة

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

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

هذا مثال افتراضي لا يصف جهة أو حادثاً حقيقياً. تكمن قيمته في قراءة RFC 10004 كجدول مسؤوليات مرتبط بالبنية، لا كشهادة موحدة للمنتج.

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

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

تعرّف RFC 10002 بنى الرسائل وعناصر التحكم، وتعرّف RFC 10003 وسائل النقل، بينما توزع RFC 10004 واجبات التنفيذ. وتثبت صفحة RFC Editor وسجل التصحيحات النسخة التي بُني عليها الحكم.

يجب على جميع الكيانات دعم Full PKI Requests وSimple وFull PKI Responses وصيغة CRMF ونقل HTTP. وينبغي للخوادم دعم Simple PKI Requests وPKCS 10. غير أن الحد الأدنى المشترك لا يلغي الملاحظات الشرطية في جدول عناصر التحكم.

إذا صُممت CA للعمل مع سلطات التسجيل تصبح بعض عناصر RA واجبة عليها. وإذا تحققت RA من الهوية أو أنشأت المفتاح، يشتد التزام EE تجاه Response Body. ويتغير دعم Encrypted POP وDecrypted POP مع اتفاق المفاتيح، والمفاتيح العتادية التي لا تستطيع التوقيع، وتفويض إثبات الحيازة.

إذن قد يتغير نطاق المطابقة من دون تبديل البرنامج. تكفي إضافة RA أو تفعيل ميزة أو نقل التحقق من الهوية كي تظهر واجبات لم يختبرها التقرير السابق.

للخوارزميات السياق نفسه. يشكل RSA-SHA256 وAES وAES-GCM بأطوال محددة ونقل المفتاح RSA الأساس. وتدخل DH وPBKDF2 وAES Key Wrap وHMAC-SHA256 عند تحقق شروط معينة. تقدم RFC 5652 بنية CMS، وRFC 5754 استخدام SHA-2، وRFC 5084 التشفير الموثق.

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

يكشف إثبات الحيازة عن صاحب السلطة. يجب على CA فرض POP قبل الإصدار، لكنها تستطيع تفويضه إلى RA في حالات محددة. توضح RFC 6955 مسار DH. لذا يجب أن يسمي الإيصال الطلب والطريقة والجهة وسياسة التفويض والدليل الذي انتقل إلى السلطة التالية.

وللمطابقة زمن أيضاً. تحل RFC 10004 محل RFC 5274 وتدمج تحديثات RFC 6402، فترفع الحد الخوارزمي إلى SHA-256. قد تعرض الخوادم خوارزميات أقدم للتوافق، لكن الوثيقة توصي بتحديد الشهادات التي ينبغي نقلها. التوافق مجموعة انتقالية تحتاج إلى مالك وموعد انتهاء، لا إذناً دائماً.

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

تفصل طبقات الواقع لدى Heng Lu بين المعيار والقدرة والإعداد والتنفيذ والإصدار والاستخدام. وتقدم أولوية الشيفرة العاملة السلوك المشاهد على الرمز. أما الحد الأدنى للمواصفة الأولية فيقصر العقد المشترك على ما يمكن اختباره ويُبقي القرار اللاحق عند المشغل المسؤول.

السجل المفيد هو إيصال مرتبط بالدور: إصدار المكوّن، ونسخة RFC والتصحيحات، واتجاه العميل والخادم على كل وصلة، وأدوار EE وRA وCA، والشروط المفعلة، والخوارزميات، ونسخة السياسة، والسلطات التي مر بها الطلب، وعناصر التحكم المعالجة، وقرار POP، والاستجابة والقبول. وما لم يُرصد يجب أن يبقى فجوة معلنة.

المصادر