الخلاصة

  • في draft-ietf-keytrans-architecture-09 توجّه علامة الحذف البحث من السجل القديم إلى الجديد، وتمنع اعتبار القيمة السابقة حالية لمجرد تعذر الوصول إلى الجديد.
  • يشترط المشروع نفسه مراقبة السجلين كلٍّ على حدة، وإبقاء القديم عاملاً زمناً يكفي المستخدمين، بمن فيهم من ظلوا بلا اتصال مدة طويلة، لإكمال المراقبة.
  • لذلك يلزم إيصال لتقاعد السجل يربط الرأس النهائي، وقنوات توزيعه، وفئات العملاء، وأدلة الإكمال، والاستثناءات، وصاحب القرار، وشرط الاستعادة. هذا الإيصال اقتراح تحليلي وليس نصاً معيارياً في KEYTRANS.

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

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

علامة الحذف تضبط أولوية البحث؛ وليست محضر إغلاق.

ما الذي تحمي منه العلامة فعلاً

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

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

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

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

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

سجلان يعنيان التزامين لم يُغلقا بعد

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

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

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

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

الرأس النهائي لا ينفذ القرار بنفسه

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

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

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

مكونات إيصال التقاعد

لا يحتاج الإيصال إلى نشر هوية المستخدم أو مفتاحه أو حالته الخاصة.

حد السجل القديم. التهيئة، وهوية التوقيع، وآخر وقت للتعديل، والحجم والجذر النهائيان، والنمط، وإثبات الاتساق مع الرأس السابق.

قاعدة الانتقال. هوية السجلين، وتوجيه Search وUpdate وMonitor، ومعنى علامة الحذف، وإصدارات العميل التي تطبقها. تحويل البحث لا يعني إسقاط واجب التاريخ.

التوزيع. القنوات الموثقة للرأس النهائي ونتيجة الوصول بحسب الإصدار والمنصة والأجهزة المدارة والحساب الخامل والنسخة المستعادة. العدد الإجمالي للتنزيلات غير كافٍ.

الإكمال. الاتصال بالجديد، والتحقق من التسمية المنقولة، وMonitor النهائي للقديم، واختبار الاستعادة، أربع حالات منفصلة.

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

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

حالة الوثيقة جزء من الحقيقة

الإصدار 09 ما زال Internet-Draft مقصوداً له وضع Informational، وقد طُلب نشره من IESG. يسجل تقرير المسؤول إجماعاً من دون اعتراضات كبيرة داخل مجتمع متخصص صغير نسبياً. هذا دليل نضج إجرائي، لا RFC منشور ولا برهان تشغيل تجاري.

أما البروتوكول المرافق فما زال يتغير. تسجل محاضر IETF 126 اقتراح صيغة جديدة لـUpdateRequest لأن السابقة لم تكن قابلة للتنفيذ، وتحذيراً من عدم التشغيل البيني إذا بقيت صيغ النقل مفتوحة. النقاش ليس قراراً معيارياً، لكنه يوضح ضرورة فصل هدف البنية، وإصدار البروتوكول، والشفرة العاملة، وقرار التقاعد المحلي.

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

المصادر

  1. بنية KEYTRANS، الإصدار 09
  2. تاريخ الوثيقة ومراجعة المسؤول
  3. بروتوكول KEYTRANS، الإصدار 05
  4. ميثاق مجموعة KEYTRANS
  5. محاضر KEYTRANS في IETF 126
  6. Lu Heng، «Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption»
  7. Lu Heng، «Running Code Primary»