الخلاصة

  • RFC 9891 مواصفة IETF تجريبية توسّع ACME للتحقق من Node ID في شبكة متحملة للتأخير، ممثلاً كهوية شهادة BundleEID وكمعرّف ACME من نوع bundleEID.
  • Node ID في DTN هو singleton Bundle Protocol Endpoint ID، أي معرّف Endpoint منفرد. ولا يجعل الامتداد non-singleton EID، أي معرّف Endpoint غير منفرد، معرّف Node ID صالحاً.
  • تُقسّم مادة التفويض بين القناتين: يحتوي تحدي ACME على token-chal، بينما يربط token-bundle كل تحقق بـChallenge Bundle معيّن.

كيف يعمل الإثبات

يبدأ العميل بإجراء ACME المعتاد، بما في ذلك إثبات امتلاك مفتاح الحساب. وينشئ الخادم تحدياً يتضمن token-chal، ثم يرسل Challenge Bundle واحداً أو أكثر إلى Node ID المطالب به. يتلقى BP Agent لدى العميل ذلك الـBundle ويعيد Response Bundle. ولا يكفي أن يكون الرد قابلاً للوصول عبر مسار ما؛ يجب أن تتضمن الاستجابة digest تربط تحدي الحساب ورمز التحدي وإثبات استلام Challenge Bundle بعينه، بما في ذلك token-bundle الخاص به. بهذه البنية لا تعبر مادة التفويض السرية قناة BP نفسها، بينما لا يستطيع مسار ACME وحده إثبات استلام الـBundle المحدد.

يتحقق الخادم من صحة تحدي ACME، ومن تطابق token-chal، ومن أن token-bundle يعود إلى Challenge Bundle المحدد، ومن أن digest في Response Bundle يربط هذه العناصر. كما يتحقق من أن المعرّف الهدف هو singleton Bundle Protocol Endpoint ID، وليس non-singleton EID. لا تعني هذه الثنائية، في هذا السياق، «عقدة واحدة مقابل عدة عقد» بالمعنى العام؛ إنها تمييز دقيق في دلالة Endpoint ID ضمن Bundle Protocol.

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

صيغة هوية الشهادة

ينبغي نقل هوية الشهادة بصياغتها الدقيقة: SAN identity من النوع otherName، وبصيغة Other Name هي BundleEID، ومشفّرة في ACME بوصفها identifier type bundleEID. هذه ليست عبارة عامة من قبيل «BundleEID SAN»، بل بنية هوية محددة يجب مطابقتها مع Node ID موضع التحقق.

ما الذي لا يثبته ذلك؟

قد يثبت النجاح أن جهة تملك مادة حساب ACME استطاعت إنتاج الرد الصحيح وأن الرد ارتبط باستلام Challenge Bundle محدد. لكنه لا يحسم، بمفرده، من يملك سلطة تسمية DTN بين منظمات مختلفة، أو هل البوابة المستخدمة موثوقة وفق سياسة مشتركة، أو هل مسار DTN يطابق طوبولوجيا الشبكة الأساسية. يدرس RFC 9891 هجمات الطرف الموجود على المسار وقيمة التحقق من وجهات نظر متعددة، لكن فعالية التحقق متعدد المنظورات تظل تجريبية.

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

حدود النطاق وتجهيز تحقق قابل للتكرار

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

يمكن للمشغّل تسجيل حساب ACME والتحدي المحتوي على token-chal، وNode ID الهدف وحالته بوصفه singleton Endpoint ID. ثم يرسل Challenge Bundle مميزاً بمعرّف Bundle وقيمة token-bundle خاصة به. وعند العودة، يفحص أن Response Bundle مرتبط بالـBundle المحدد، وأن digest يربط token-chal وtoken-bundle والتحدي نفسه، وأن هوية الشهادة بصيغة SAN identity من النوع otherName وبـOther Name form BundleEID، والمشفّرة في ACME كـidentifier type bundleEID، تطابق Node ID المطلوب.

تُختبر حالات Bundle قديم، أو token-bundle تابع لـBundle آخر، أو استجابة من non-singleton EID. وإذا استُخدمت integrity gateway، تُختبر أيضاً استجابة مصدرها بوابة لا تعتمدها سياسة المشغّل. لا ينبغي قبول أي من هذه الحالات كإثبات كامل.

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

إذا تطابقت هوية Node ID، وتحقق الحساب، ووصلت الاستجابة الصحيحة للتحدي المحدد، فاعتبر نتيجة RFC 9891 ناجحة ضمن هذا الإثبات فقط. وإذا فشل أي رابط، فأعد التحقق من المسار والرموز وصيغة الهوية، ولا تستنتج تلقائياً فقدان السيطرة على الاسم. وإذا كانت integrity gateway مستخدمة ولم تثبت الثقة بها، فأوقف هذا المسار؛ أما إذا لم تُستخدم، فلا ينطبق شرط الإيقاف المتعلق بها. ويجب توثيق البوابة والتحقق متعدد المنظورات بوصفهما سياسة محلية تجريبية، لا ضماناً يفرضه RFC. ولا يُتخذ قرار إصدار أو تثبيت شهادة قبل فصل مسائل التزويد والمفتاح والتوجيه، فهي خارج النطاق.

المصادر

  • RFC 9891 — التحقق من DTN Node ID عبر ACME.
  • RFC 8555 — الأساس المعياري لـACME.
  • RFC 9171 — الأساس المعياري لـBundle Protocol.
  • RFC 9172 — أساس أمن Bundle Protocol.