Summary

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

الشجرة الشفافة تقع خلف بوابة غير شفافة

تطلب Alice مفتاح Bob. يسمح التطبيق بالطلب ويمرره إلى خدمة KEYTRANS، فتتلقى Alice القيمة ومسار الإثبات في شجرة البادئات والارتباط بسجل الإضافة فقط. تتحقق من أن الإجابة منسجمة مع الجذر الموثق، ثم تتابع الحالة ذات الصلة. هذه هي الوظيفة التي صُممت الشفافية لأدائها.

يرسل Fred الطلب نفسه، لكن التطبيق لا يجد العلاقة المطلوبة ويوقفه في طبقة النقل. لم يحصل Fred على دليل مزور؛ لم تحدث أصلاً عملية بروتوكول يمكن التحقق منها. من يراجع جذور السجل وأدلة الإدراج والاتساق سيرى مسار Alice، لكنه لن يعرف هل رُفض Fred وفق قاعدة صحيحة أم وفق استثناء منتهي الصلاحية أم بسبب عطل.

هنا ينقسم السؤال إلى مستويين. سلامة البيانات تسأل إن كانت الإجابة الصادرة جزءاً من الحالة الملتزم بها. حوكمة الوصول تسأل إن كانت البوابة قد طبقت قاعدة ثابتة ومتناسبة وقابلة للتصحيح. نجاح الإثبات الأول لا يجيب تلقائياً عن السؤال الثاني.

ما الذي يثبته KEYTRANS بالفعل

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

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

لكن النصوص موضع البحث ليست معايير نهائية. صدرت draft-ietf-keytrans-architecture-09 في 30 يونيو 2026 بوصفها Internet-Draft لمجموعة العمل، والمقصود أن تكون Informational، ويظهر لها تاريخ انتهاء في 1 يناير 2027. أما draft-ietf-keytrans-protocol-05 فما زالت مسودة أيضاً. يحدد الميثاق المعتمد نطاق العمل ولا يثبت نشره في خدمة بعينها.

وتنص البنية على أن KEYTRANS ليس معياراً مستقلاً عن التطبيق. البروتوكول يوثق الروابط وحالة السجل، بينما يقرر التطبيق من يحق له تنفيذ Search أو Update أو Monitor. لذلك يثبت SearchResponse الصحيح ما حدث بعد قبول الطلب، ولا يثبت أن جميع الطلبات المتشابهة قوبلت بالقرار نفسه.

المنع قد يكون ضرورة لحماية الخصوصية

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

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

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

سحب الصلاحية انتقال زمني لا مفتاح تشغيل

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

لهذا الاستمرار غرض أمني. إذا توقف كل رصد لحظة سحب الإذن، فقد لا يكتشف العميل تغييراً غير مشروع في مفتاح يؤثر في اتصال قائم. وإذا استمر الوصول إلى بيانات جديدة بلا حد، يصبح سحب الإذن بلا معنى. كما تربط RFC 9420 وRFC 9458 وRFC 9614 أمن الرسائل بالحالة المتغيرة والعضوية وبيانات الاعتماد عبر الزمن.

ينبغي إذاً أن يسجل نظام المساءلة الانتقال: أي إصدار من السياسة أوقف Search، وأي واجب Monitor بقي، وما الدليل الذي سمح باستمراره، ومتى ينتهي. عبارة «مرفوض» وحدها تمحو فروقاً يعترف بها تصميم البروتوكول نفسه.

الطرف الثالث لا يرى تلقائياً كل البوابة

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

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

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

إيصال للسياسة لا ملف للبحث

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

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

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

بهذه الحدود يستطيع المدقق طرح أسئلة ضيقة: هل عوملت الطلبات من الفئة نفسها وفق إصدار السياسة نفسه بطريقة متسقة؟ هل استمرت استثناءات بعد انتهاء صلاحيتها؟ هل بقي Monitor الضروري بعد سحب Search؟ هل نُفذ تصحيح قُبل بعد اعتراض؟ لا تتطلب الإجابة نشر هوية Alice أو Fred أو Bob.

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

الحذف يؤكد فصل طبقة البيانات عن طبقة السياسة

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

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

ما لا تثبته المصادر

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

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

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

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-09
  5. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/
  6. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/history/
  7. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-protocol-05
  8. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/
  9. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/history/
  10. https://datatracker.ietf.org/doc/charter-ietf-keytrans/
  11. https://www.rfc-editor.org/rfc/rfc6962.html
  12. https://www.rfc-editor.org/rfc/rfc9162.html
  13. https://www.rfc-editor.org/rfc/rfc6973.html
  14. https://www.rfc-editor.org/rfc/rfc7258.html
  15. https://www.rfc-editor.org/rfc/rfc9420.html
  16. https://www.rfc-editor.org/rfc/rfc9458.html
  17. https://www.rfc-editor.org/rfc/rfc9614.html