الخلاصة

  • تقترح مسودة Internet-Draft فردية بتاريخ 28 سبتمبر أن يحتفظ سجل تفويض الوكيل، حين يُراد استخدامه دليلاً، بمسار ربط مفتاح التوقيع بمرساة الثقة وبإثبات زمني مستقل.
  • شروط الانتقال إلى مقاومة الحوسبة الكمية اقتراح من مؤلف المسودة، لا قاعدة اعتمدها IETF. ولا تسجل المسودة هجوماً كمياً أو فشلاً قائماً في التحقق المباشر عبر OAuth.

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

تضع مسودة V. K. Uppalapati، المعنونة Post-Quantum Requirements for Software and AI Agent Identity في إصدارها الأول -00، هذه الفجوة في صلب النقاش. نُشرت في 28 سبتمبر، وتعرضها منصة Datatracker بالحالة I-D Exists. إنها تقديم فردي مقصود به أن يكون معلوماتياً، وليست وثيقة تبناها فريق WIMSE ولا RFC نافذاً. يرى المؤلف، بناءً على مسحه للمواصفات، أن حفظ الصلة بين مجموعة مفاتيح جُلبت بواسطة TLS ومرساة ثقة لا يُفرض عموماً على سجلات التفويض. ينبغي نسبة هذا التقييم إليه؛ فلا توجد هنا دراسة تثبت أن كل تشغيل لـOAuth يهمل هذه الصلة.

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

حتى حفظ سلسلة المفتاح لا يجيب عن سؤال الوقت. يحدد التوقيع، وفق مسار تحقق مقبول، المفتاح الذي صدر به التصريح؛ ولا يثبت بنفسه لحظة صدوره. يتيح RFC 3161 ختم وقت يؤكد وجود بصمة بيانات قبل وقت معين، ويصف RFC 4998 تجديد حماية سجل الأدلة قبل أن تضعف خوارزمياته أو تنقضي أهلية شهاداته. لكن ختم الوقت نفسه يحمل توقيعاً ويعتمد على قوة مساره. لذلك تدعو المسودة إلى تثبيت مبكر للوقت، وإلى مرساة مقاومة للكم بحلول تاريخ انتقال لم يُحدد بعد، ثم إلى التجديد المستمر. هذا تحليل لمخاطرة مستقبلية محتملة، وليس إعلاناً عن وجود حاسوب كمّي قادر على كسر التواقيع المستخدمة الآن.

لا يكفي كذلك تبديل الخوارزمية عند آخر حلقة في السلسلة. فشهادة وكيل ذات توقيع مقاوم للكم لا تمنح السلسلة كلها هذه الصفة إذا كانت الجذور التي تسندها ما زالت تعتمد حصراً على توقيع تقليدي. وينطبق سؤال مشابه على مفتاح OAuth الذي أُخذ عبر بنية شهادات الويب التقليدية. قد يكون تحديث الطرف النهائي خطوة إعداد سليمة، لكنه لا يعيد إنشاء سلسلة اتصال لم تحفظ أصلاً. يقترح المؤلف إظهار خوارزميات كل حلقة للمتحقق وصونها مع السجل؛ ولم يقرر IETF بعد آلية موحدة أو موعداً ملزماً لذلك.

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

المصادر