الخلاصة

  • نُشرت المراجعة -01 في 28 سبتمبر بوصفها مسودة إنترنت فردية نشطة؛ ليست معياراً أقرّته مجموعة WIMSE ولا وثيقة RFC.
  • تكشف بصمات ما استقبله كل طرف وما أرسله حذف طرف غيّر الرسالة، لكنها قد لا تكشف حذف طرف وقّع عليها ثم مرّرها بلا تغيير.
  • تقترح المسودة توقيعاً مجمّعاً لإثبات مشاركة هذا الطرف؛ ولا يمنح ذلك وحده صلاحية للعمل أو دليلاً على ترتيب الوسطاء المتتالين الذين لم يغيّروا شيئاً.

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

عنوان الوثيقة المنقحة هو Authenticated Provenance for WIMSE Delegation Chains. يصنفها سجل IETF في نسختها المؤرخة 28 سبتمبر مسودة إنترنت فردية نشطة، من دون مسار RFC وبحالة IESG هي I-D Exists. ويحذّر السجل من اعتبار إيداع مسودة فردية تبنياً من IETF. كانت فكرة جمع التوقيعات موجودة في النسخة -00 الصادرة في 8 سبتمبر؛ الجديد في -01 توضيح الحدود بين أثر التعديل وإثبات المشاركة، وتفصيل معالجة المسار والاستعلام والردود. عبارة النية للوصول إلى مسار المعايير لا تغيّر الوضع الحالي للوثيقة.

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

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

للمقترح قيود عملية لا تختفي خلف صغر حجم التوقيع المجمّع. رموز الهوية ومدخلات التوقيع والبصمات تنمو مع طول السلسلة. يلزم اعتماد خوارزمية متوافقة قابلة للتجميع عند جميع الأطراف؛ وتذكر المسودة أن ML-DSA لا يتيح هذا التجميع وأن الرجوع إلى توقيعات منفصلة لا يحمي الوسيط الذي لم يغيّر شيئاً من الحذف. مساهمة غير صحيحة واحدة تُفشل الفحص كله من دون تعيين صاحب الخلل مباشرة. كما لا تثبت سلسلة المحتوى، وحدها، ترتيب عدة وسطاء متتالين مرّروا الرسالة كما هي. أسماء الحقول الواردة في قسم IANA طلبات تسجيل، وليست تسجيلات منجزة.

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

المصادر