Summary

  • يحدد RFC 10003 أربعة نواقل لرسائل CMC: HTTP والملف والبريد وTCP. نجاح الناقل يصف حركة الغلاف، ولا يقرر نجاح عملية PKI التي يحملها.
  • لا يثبت رمز 2XX أو قبول البريد أو وجود الملف أو اكتمال الكتابة عبر TCP أن CA أو RA منحت الطلب، ولا أن الشهادة المقصودة صدرت ودخلت الخدمة.
  • يقترح Daniel Kade «إيصال النقل إلى القرار» لربط دليل محدود عن القناة بالاستجابة المتحقق منها وحالة الانتظار وبصمة الشهادة الصادرة وملاحظة تركيبها، من دون تخزين الأسرار.

للرسالة طريق وللطلب حكم

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

ينظم RFC 10003 العمل الأول. فهو يضع قواعد نقل Certificate Management over CMS عبر HTTP والملفات والبريد الإلكتروني وTCP. ويشترط RFC 10004 أن تدعم جميع كيانات CMC النقل عبر HTTP، بينما تبقى الآليات الأخرى اختيارية. بذلك يتفق الطرفان على التغليف ونوع الوسائط وتسلسل التبادل.

أما الحكم فينتمي إلى RFC 10002. تستطيع Full PKI Response أن تعبر عن النجاح أو الفشل أو الانتظار أو الاكتمال الجزئي أو عدم الدعم أو طلب التأكيد أو خطوة إضافية. وقد يحتاج الإصدار المؤجل إلى أكثر من جولة. انتهاء تبادل HTTP لا يساوي انتهاء معاملة الشهادة.

ماذا يقول 2XX بالفعل

يفرض RFC 10003 استخدام POST لطلبات HTTP واستخدام رموز 2XX للاستجابات الناجحة. ويحدد الجسم الثنائي ونوع المحتوى. تحمل Full PKI Request القيمة application/pkcs7-mime; smime-type=CMC-Request، وتحمل Full PKI Response المعامل CMC-Response. وللصيغ البسيطة معرّفات أخرى.

تنتج هذه العناصر دليلاً جيداً عن القناة: عنوان الوجهة والطريقة والتوقيت والرمز ونوع المحتوى ومرجع سياسة TLS وبصمات محدودة للطلب والرد. يمكن للمشغل إثبات أن نقطة معينة استلمت طلباً وأعادت استجابة وفق HTTP.

لكن الدليل لا يفسر قرار PKI. قد تحمل استجابة 2XX حالة CMC من نوع failed أو pending أو partial. نجح خادم HTTP في إعادة الرد، بينما رفضت السلطة الطلب أو أجلته أو أكملت جزءاً منه.

والعكس صحيح. ليس كل رد خارج 2XX رفضاً من CA. ربما تعطل وكيل أو مسار أو مصادقة HTTP أو معالجة نوع المحتوى قبل وصول الطلب إلى منطق CMC. عندئذ تكون العبارة الصادقة «لم نر قرار CMC»، لا «رُفض الطلب».

الانتظار التزام بالعودة

لا تعني pending نجاحاً متأخراً يمكن افتراض حدوثه. يتضمن PendInfo رمزاً وزمناً مقترحاً لإعادة الاستعلام، وعلى صاحب الطلب أن يعود. وتبقي partial الأجزاء غير المنجزة مفتوحة. وإذا استُخدم معرّف معاملة فيظل محفوظاً إلى أن تغلقه Full PKI Response.

لذلك يجب أن يسجل الإيصال الأول «تم النقل والقرار معلق». ويرتبط الاستعلام اللاحق بالمعاملة نفسها وبمرجع محمي للرمز وبواقعة نقل جديدة. ضياع الرمز أو عدم إجراء الاستعلام أو إتمام بعض عناصر الدفعة لا يتحول إلى نجاح لمجرد مرور الوقت.

إعادة الإرسال تزيد المشكلة. POST غير idempotent، ولهذا يمنع RFC 10003 بيانات 0-RTT المبكرة عندما تدعم تطبيقات CMC ‏TLS 1.3 أو QUIC. إذا ضاع الرد ثم أُعيد الطلب، فقد تحدث عمليتا تسليم. تساعد البصمة والـnonce ومعرّف المعاملة في التفريق بين محاولة استعادة وإعادة تشغيل وطلب جديد مصرح به.

لكل ناقل اختصار زائف

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

يحدد البريد تغليف MIME وأسماء الملفات وأنواع الوسائط وأمثلة base64. لكن Message-Id أو قبول SMTP أو وصول الرسالة إلى صندوق بريد حقائق تخص نظام البريد. تبقى حالة CMC داخل الجسم. وينبه RFC 10003 إلى أن TLS مع وكيل الإرسال الأول لا يضمن تشفير أو مصادقة القفزات التالية. يمكن لـREQUIRETLS طلب الحماية عبر المرحلات الداعمة، وقد يؤدي إلى عدم التسليم إن افتقدها أحدها.

أما TCP فينقل رسائل CMC الثنائية بلا غلاف إضافي. سُجلت الخدمة pkix-cmc على المنفذ 5318، وعلى العميل انتظار الرد الكامل قبل إرسال طلب آخر على الاتصال نفسه. فتح المقبس وكتابة كل البايتات لا يقوم مقام التحقق من الاستجابة.

ينتج كل ناقل سجلاً مختلفاً. والمبدأ المشترك هو ألا تتحدث قياسات النقل باسم قرار الجهة المختصة.

حماية الرسالة لا تلغي حوكمة المسار

تقدم تراكيب CMS سلامة الرسالة أو مصادقتها أو سريتها. ويحمي HTTPS الاتصال، ويمكن أن يضيف IPsec أو EnvelopedData أو AuthEnvelopedData طبقات أخرى. لا تجعل أي طبقة نطاق غيرها غير مهم.

اتصال TLS صحيح لا يثبت أن الطالب مخول بالأسماء المطلوبة، أو أن RA تحققت من الهوية، أو أن CA وافقت على ملف الإصدار. ورسالة CMS سليمة لا تبين وحدها أي نقطة استلمتها، ولا أي وسيط فشل، ولا أي محاولة يقابلها الرد.

ويقرر RFC 10003 أيضاً أن عميل CMC غير ملزم بدعم مصادقة HTTP أو ملفات الارتباط، فلا يجوز للخادم افتراض وجودهما. بدء الثقة وسياسة الإصدار قراران معماريان خارج ميكانيكا النقل.

لهذا ينبغي تفكيك عبارة «سُلّمت بأمان» إلى أفعال محددة: تحققت قناة TLS، وصودقت رسالة CMS، وثبتت سلطة الطالب، ووصل قرار CMC، وصدرت بصمة شهادة، وركبت في النظام. الدقة اللغوية هنا تمنع الدقة الزائفة في التشغيل.

إيصال CMC من النقل إلى القرار

أقترح إيصال CMC من النقل إلى القرار. إنه تصميم حوكمة من Daniel Kade، لا مطلب جديداً من RFC 10003 أو IETF.

يسجل القسم الأول واقعة الناقل. في HTTP: هوية النقطة والطريقة والوقت والرمز ونوع المحتوى ومرجع سياسة TLS وبصمات محدودة. وفي البريد: معرّف الرسالة المرسلة والوجهة وحالة التسليم الملحوظة ونطاق حماية المرحلات. وفي الملف وTCP: القناة المضبوطة والاتجاه والوقت والبصمة. لا حاجة إلى الأجسام أو كلمات المرور أو المفاتيح أو تفاصيل الشبكة الحساسة.

يسجل القسم الثاني تفسير التطبيق: طلب واستجابة بسيطة أو كاملة، ومعرّف المعاملة، وأجزاء الجسم التي تنطبق عليها الحالة، ونتيجة فحص السلامة والمصادقة. وصول بايتات لا يمكن تفسيرها يوقف الدليل عند النقل.

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

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

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

آخر مرحلة مثبتة

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

تبحث المراقبة عن الوصلات المكسورة: 2XX بجسم لا يفسر، وفشل CMC يحسب نجاحاً، ورمز انتظار بلا استعلام، وجسم مكرر تحت معاملات مختلفة، وشهادة لا تطابق المفتاح أو الأسماء المتوقعة، وإصدار بلا تركيب، وخدمة لا تزال تعرض القديمة.

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

وحّد RFC 10003 الطرق التي تسافر فيها رسائل CMC. أما الحوكمة فتبدأ برفض مساواة الوصول بالموافقة.

المصادر

  1. Lu Heng — سيادة البيانات: الواقع التقني والعملي
  2. Lu Heng — لماذا وُجدت BTW Media
  3. Lu Heng — أولوية الشيفرة العاملة
  4. RFC 10003 — بروتوكولات نقل CMC
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — متطلبات توافق CMC
  7. RFC 5273 — مواصفة نقل CMC السابقة
  8. RFC 5967 — نوع الوسائط application/pkcs10
  9. RFC 8551 — مواصفة رسائل S/MIME 4.0
  10. RFC 9110 — دلالات HTTP
  11. RFC 9205 — بناء البروتوكولات باستخدام HTTP
  12. RFC 9325 — الاستخدام الآمن لـTLS وDTLS
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — خيار SMTP REQUIRETLS
  16. RFC 3207 — تأمين SMTP عبر TLS