نجح التوقيع، لكن من فوّض المفتاح لتمثيل الشريك؟

Summary

• حقلا AS2-From وAS2-To اسمان نصيان حساسان لحالة الأحرف ويتفق عليهما الشريكان؛ وليسا هوية عالمية تستخرج تلقائياً من الشهادة.
• يوجب draft-ietf-ediint-rfc4130bis-04 فصل شهادة TLS عن شهادة AS2 المستخدمة لتوقيع الرسالة أو تشفيرها، ويشترط حماية جلب الشهادات وتفعيلها.
• يثبت التوقيع الصحيح وانعكاس الأسماء وتطابق Message-ID وMIC حلقات محددة. أما تفويض المفتاح للاسم والاتجاه والعلاقة فيبقى قراراً محلياً.

حين يكون كل مؤشر أخضر

في نافذة تدوير هادئة، قد يقدم خادم HTTPS شهادة TLS سليمة، ثم يعود MDN موقّعاً بالمفتاح الجديد. يعكس الاسمين كما ينبغي، ويرتبط بالرسالة الأصلية، ويطابق MIC المحفوظ. إن لم يوجد سجل موافقة، فقد تحققت كل الاختبارات حول فرضية لم تُوثق: أن هذا هو مفتاح الشريك المخوّل.

يوضح نص المراجعة 04 الفواصل اللازمة. تعرض صفحة Datatracker مشروعاً نشطاً لمجموعة EDIINT، وتسجل واجهة الوثيقة حالة I-D Exists، ويؤرخ السجل المراجعة في 24 سبتمبر 2026. المقصد Proposed Standard، لكنه ليس RFC معتمداً، ولن يحل محل RFC 4130 إلا بعد الموافقة.

الاسم اتفاق ثنائي

تسمح الفقرة 6.3 برقم DUNS أو سلسلة يتفق عليها الشريكان. يتراوح الاسم بين 1 و128 محرفاً ASCII قابلاً للطباعة، ويميز حالة الأحرف، ويلزم في الرسائل وMDN. في الرد يطابق AS2-To قيمة AS2-From في الطلب، والعكس صحيح.

يثبت ذلك اتساق النص، لا الشخصية القانونية أو اسم DNS أو موضوع الشهادة. قد يعيد المستقبل unknown-trading-relationship أو unknown-trading-partner عند عدم المعرفة. ولا يمكنه فعل ذلك إلا بالرجوع إلى جدول محلي؛ فالمشروع لا ينشئ سجلاً عالمياً يربط كل اسم بمفتاح واحد.

مجالان أمنيان لا شهادة واحدة

تحمي شهادة TLS نقطة HTTPS. يحدد RFC 8446 TLS 1.3، ويقدم RFC 9110 دلالات HTTP. ويوفر RFC 9525 سياقاً حديثاً لهوية الخدمة، لكنه ليس قاعدة ربط تبناها مشروع AS2.

تحمي شهادة AS2 الرسالة وMDN. يقدم RFC 8551 S/MIME، وRFC 5652 CMS، وRFC 5280 إطار PKIX. ويمنع المشروع استخدام الشهادة نفسها لـTLS وAS2، حتى تبقى دورات التدوير وحدود الاختراق منفصلة.

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

نقل الشهادة لا يمنحها الدور

توصي الفقرة 9.2 بـCertificate Exchange Messaging وتحيل إلى مشروع CEM. عند التبادل اليدوي يجب ضمان سلامة المفتاح وأصالته قبل التفعيل. ويمكن استخدام Well-Known URI للجلب الأولي، شريطة مصادقة الطالب وتفويض وصول الشركاء الشرعيين.

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

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

لا يستطيع MDN اختيار سلطة مفتاحه

يحتفظ المرسل بالرسالة وMessage-ID وMIC. ثم يتحقق من توقيع MDN وOriginal-Message-ID وMIC المعاد. يوفر RFC 8098 الإطار الحالي لإشعارات التصرف.

يسمي المشروع النتيجة بعد التحقق “non-repudiation of receipt”. لا نحول المصطلح إلى حكم قانوني عام. كما أن الفرق بين التسليم والقبول التجاري موضوع سبق نشره. السؤال هنا أسبق: لماذا كان المفتاح المستخدم للتحقق مخولاً لاسم الشريك؟

السلم هو: HTTP/TLS؛ أسماء AS2؛ صلاحية الشهادة؛ التفويض المحلي؛ التوقيع؛ ربط Message-ID/MIC؛ نتيجة MDN؛ قبول EDI؛ النتيجة التجارية. لا تمنح طبقة نفسها سلطة الطبقة التالية.

تحتوي المراجعة 03 بالفعل على ضوابط الشهادات الأساسية؛ لذلك نقول إن المراجعة الحالية تقننها، لا إنها اخترعتها كلها. تساعد نسختا HTML وXML في فحص البنية، ولا تثبتان تطبيقاً فعلياً.

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

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

المصادر والحدود

تضم الحزمة نص وHTML وXML للمراجعة 04، وصفحة Datatracker وواجهتها وسجلها، والمراجعة 03، وRFC 4130 وRFC 8098 وRFC 8551 وRFC 8615 وRFC 5652 وRFC 5280 ومشروع CEM وRFC 9110 وRFC 9525 وRFC 8446. ويستخدم تحليل القيادة منفصلاً مقالات Lu Heng عن أولوية الشيفرة العاملة وطبقات الواقع والمواصفة الأولية الدنيا. لا تثبت المصادر منتجاً أو حادثة أو هجوماً أو حكماً قضائياً بعينه.