الخلاصة

  • في 28 سبتمبر نقلت IETF وثيقة Key Transparency Architecture إلى حالة AD Evaluation::Revised I-D Needed بعد أن طلبت مديرة مجال الأمن الفصل بين مالك الوسم والطرف الذي يعتمد عليه.
  • قد تكون نتيجة البحث وتوقيع رأس الشجرة صحيحين تشفيرياً، من دون أن يبيّنا من أجاز الكشف أو من كان يملك تغيير الربط أو من بقيت عليه مهمة المراقبة.
  • يحتاج التشغيل إلى إيصال تحقق مقيّد بالأدوار يضم المالك، وصفة الطالب، وقرار الوصول، ونمط النشر، والموقّع، والحدود الزمنية، والحالة السابقة، والواجب اللاحق.

تنتهي مكتبة التشفير إلى نتيجة ناجحة: الدليل متماسك، والتوقيع صحيح، والرؤية الجديدة تمتد من الرؤية التي احتفظ بها العميل. لكن هذا النجاح لا يجيب عن السؤال المؤسسي: نجاح قرار مَن؟

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

في 28 سبتمبر 2026 نشرت Deb Cooley، بصفتها مديرة مجال الأمن في IETF، ملاحظاتها على النسخة 09 من Key Transparency Architecture. ويسجل تاريخ Datatracker الانتقال إلى AD Evaluation::Revised I-D Needed. تظل الوثيقة مسودة إنترنت تستهدف RFC معلوماتياً، وليست معياراً منشوراً ولا دليلاً على تطبيق فعلي.

أهم الملاحظات تبدو لغوية. تعرّف المسودة User / Account، ثم تسند مهام مختلفة إلى «مالك الوسم» وإلى مستخدم يبحث عن وسم شخص آخر. تقترح Cooley تسمية الثاني بالطرف المعتمد. المالك هو موضوع الربط، أما الطرف المعتمد فيتخذ قرار ثقة استناداً إليه؛ ولذلك لا تتطابق حقوقهما ولا التزاماتهما اللاحقة.

تعالج شفافية المفاتيح نقطة حساسة في التشفير بين الطرفين. غالباً ما توزع الخدمة المفاتيح العامة اللازمة للاتصال. فإذا نسبت إلى حساب ما مفتاحاً يسيطر عليه مهاجم، قد ينجح التشفير تقنياً وهو يحمي العلاقة الخطأ. لذلك تضع البنية روابط الهوية والمفتاح في سجل محمي تشفيرياً لا يقبل إلا الإضافة. وتنتج عمليات Search وUpdate وMonitor أدلة، فيما يجب أن تبقى الردود اللاحقة متسقة مع الرؤية السابقة للعميل.

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

توزع أنماط النشر الثلاثة هذه المراقبة بطرق مختلفة.

في Contact Monitoring يراجع المالك بانتظام أحدث قيمة لوسمه، ويعود الطرف الذي شاهد نسخة جديدة ليتأكد من أنها بقيت مرئية مدة تكفي لاكتشافها. وتشترط المسودة السماح بطلب Monitor اللازم حتى لو لم يعد Search أو Update الأصلي مسموحاً. فسحب الوصول الحالي لا يمحو واجباً إثباتياً نشأ عن مشاهدة سابقة مشروعة.

في Third-Party Auditing يحتفظ السجل بمعظم التخزين والتشغيل، ويوقّع مدقق خارجي رؤيته دورياً. تعتمد قيمة التوقيع على موضع بدء التدقيق والحد الأقصى للتأخر. وقد يكون التوقيع أصيلاً لكنه أقدم من أن يصلح للقرار الجاري.

في Third-Party Management يتولى مدير خارجي معظم التخزين والتشغيل، بينما يبقى مشغل الخدمة مسؤولاً عن التحكم في الوصول والمصادقة على النسخ الجديدة قبل تمرير الطلب. يفترض النموذج عدم التواطؤ بين الطرفين. وتطلب المراجعة إضافة بحث صالح إلى الرسم، لأن إظهار Alice وهي تتعامل مع مدخلها فقط يحجب مسار الطرف الذي يحتاج إلى مفتاح شخص آخر.

تحول النسخة 05 من Key Transparency Protocol هذه الفروق إلى معلمات: نمط النشر، ومفاتيح التوقيع وVRF، ونافذة المراقبة المعقولة، وعند وجود مدقق مفتاحه وموضع بدايته وأقصى تأخره. إن عبارة «التوقيع صحيح» بلا هذه العناصر تزيل السياق الذي يحدد معنى التوقيع.

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

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

للخصوصية والحذف توقيت آخر. يمكن إزالة بيانات المستخدم بعد انتهاء صلاحيتها أو انقطاع الوصول إليها نهائياً، بينما قد تبقى مادة تشفيرية لازمة حتى انقضاء العمر الأقصى. وتخفي دالة عشوائية قابلة للتحقق الوسوم. وتقترح المراجعة جعل RFC 9381 مرجعاً معيارياً إذا كان فهم VRF ضرورياً، ودمج نقاش الخصوصية.

كما تظهر تبعية بين الوثائق. يصف تقرير المشرف البنية بأنها أساس البروتوكول؛ فإذا نُشرت البنية أولاً، يجب أن تبقى إحالات البروتوكول أمثلة. وتطلب المراجعة شرح الاستناد إلى النسخة المطبقة من Certificate Transparency، أي RFC 6962، إلى جانب RFC 9162. ويوفر MLS سياقاً للاعتمادات في الرسائل المشفرة، لا دليلاً على نشر KT.

المعالجة التشغيلية ليست تجزئة جديدة، بل إيصال تحقق مقيّد بالأدوار. ينبغي أن يسجل مع الدليل ونسخة الوسم: صفة الطالب، والمالك، وسياسة الوصول وإصدارها، والنمط، وهوية الموقّع، وحجم الشجرة ووقتها، والتأخر المقبول، وحالة العميل السابقة، وأي Monitor لم يُنجز بعد. وبذلك يمكن فصل دليل فاسد، وكشف غير مأذون لكنه مثبت، ورؤية مدقق قديمة، ومراقبة لم تُنفذ، وفقدان للاستمرارية.

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

المصادر