يمكن لـ OCM إزالة عضو من دون تدوير مفتاح الملف

الخلاصة

• أصبحت draft-ietf-ocm-mls-federated-groups-00 في 11 سبتمبر 2026 بند عمل لمجموعة Open Cloud Mesh. وهي Internet-Draft قابلة للتغيير، لا RFC ولا دليلاً على تشغيل فعلي.
• يستبعد Remove Commit العضو من حقبة MLS الجديدة. لكن وضع إعادة استخدام المفتاح الاختياري يسمح للخادم المرسل بالإبقاء على مفتاح الملف والنص المشفر، فتقوم فعالية الإبطال على ثقة المشاركين في حذف المواد القديمة.
• يبقى اعتماد النقل الذي يتيح لخادم عضو جلب النص المشفر مساراً ثالثاً. يقترح Daniel Kade إيصالاً محمياً يفصل نتائج العضوية والمفتاح والنقل؛ وليس هذا الإيصال مطلباً من IETF أو OCM.

التبني ينقل مسؤولية التطوير ولا ينهيها

يسجل تاريخ Datatracker ظهور نسخة مجموعة العمل 00 في 11 سبتمبر وربطها بالسلسلة الفردية السابقة. وتصف رسالة إعلان النتيجة الوثيقتين بأنهما نقطتا بداية ستتغيران مع استمرار النقاش. أصبحت مجموعة OCM مسؤولة عن العمل، لكن ذلك لا يثبت إجماع IETF النهائي على اختياراته.

تعرض صفحة الوثيقة الحالية نية Standards Track وانتهاءً في مارس 2027. وما زالت النسخة تضم مسائل مفتوحة، منها فك التشفير المتدفق، وتجميع رسائل توزيع المفاتيح، وإعادة إرسال Commits المفقودة. ولا يحتوي سجل IANA الخاص بـMLS عند القطع على الاسمين الدقيقين ocm-group-key وocm_federated_group، فيما تظل قيمة الامتداد TBD في المسودة. الطلب المستقبلي ليس تخصيصاً حياً.

تجعل نسخة مجموعة العمل 00 مجموعة موزعة على خوادم OCM متعددة جهة مستقبلة للمشاركة. لكل مستخدم ورقة واحدة في شجرة MLS. تنشئ عملاء المشرفين Commits، ويفصل Group Owner Server في Commit واحد لكل حقبة، ويتحقق كل Member Server من أن الموقع كان مشرفاً في الحالة المعنية. وكانت النسخة الفردية 02 تتضمن بالفعل المفاضلة الأساسية بين تدوير مفتاح الملف وإعادة استخدامه. الاسم الجديد يضعها في مسار المراجعة الجماعية، ولا يحسمها.

النتيجة الأولى تقع في حالة المجموعة

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

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

أما المورد فيستخدم مفتاحاً مستقلاً. يشفّر File Key عشوائي، أو FK، الملف نفسه. ويُستخدم Group Key المشتق من MLS لتغليف FK عند توزيعه. يتطلب تغير الحقبة غلافاً جديداً، لكنه لا يفرض دائماً مفتاح ملف جديداً.

تجديد الغلاف ليس تدوير المفتاح

إعادة التغليف تبقي FK كما هو وتضعه تحت Group Key الجديدة. أما التدوير فيولّد FK جديداً، ويعيد تشفير المورد، وينشئ غلافاً لكل مجموعة لا تزال مخولة، ثم يوزع تلك الأغلفة. لذلك يمكن أن تنجح إزالة العضو بينما لا يتغير النص المشفر.

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

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

في وضع إعادة الاستخدام تصبح الحوكمة آلية التنفيذ

قد تكون إعادة تشفير ملفات ضخمة كثيرة التعديل غير عملية. لذلك تستطيع اتحادية رسمية ذات حوكمة واضحة وثقة متبادلة اختيار key-reuse mode. تتقدم الحقبة ويحصل الأعضاء الباقون على غلاف جديد لـFK القديم، لكن FK والنص المشفر يظلان كما هما.

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

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

لا يبرر هذا اتهام خادم سابق بأنه سيخالف اتفاقه. بل يحدد نوع الضمان بدقة. المشكلة تنشأ عندما تعرض لوحة واحدة «تمت الإزالة» وكأنها دليل على عملية تشفير لم تراقبها.

اعتماد النقل يعمل بساعة منفصلة

للمشاركة المشفرة حاجزان. يسمح اعتماد خاص بكل Member Server بجلب النص المشفر، بينما تحكم مفاتيح MLS وFK فك التشفير. إذا أزيل آخر عضو موجود على خادم ما، توصي المسودة بأن يلغي الخادم المرسل اعتماد النقل لذلك الخادم ويرسل SHARE_UNSHARED. لا ينفذ Remove Commit ذلك وحده.

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

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

لا يمكن استرجاع نسخة وصلت بالفعل

يوضح قسم الأمن حداً يتجاوز وضع إعادة الاستخدام. لا يستطيع MLS منع عضو مخول من الاحتفاظ بنص واضح أو Group Key أو FK استلمه بصورة مشروعة أو من كشفه. يضمن تدوير مكتمل أن المفتاح القديم لا يفتح النص الحالي بعد إعادة تشفيره. لكنه لا يمحو تصديراً قديماً ولا زوجاً من نص مشفر ومفتاح مخزنين بلا اتصال.

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

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

إيصال لثلاث عواقب

يقترح Daniel Kade إيصال عواقب الإزالة داخل مساحة محكومة الوصول. يربط رأس الإيصال عنوان المجموعة والحقبتين القديمة والجديدة وعنوان OCM للمستخدم المحذوف وموافقة المشرف وCommit المقبول ووقت النفاذ. ثم يحصي الموارد المتأثرة وكل مجموعة لا تزال تملك الوصول.

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

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

هذا اقتراح تحريري من Daniel Kade، وليس مطلباً من IETF أو MLS أو OCM. يساعد Policy Mirror لهينغ لو على إبقاء الفاعل والقاعدة والدليل في أدوار منفصلة. وتسمح Minimum Initial Specification بنواة مشتركة صغيرة مع أدلة محلية أغنى. أما Why BTW Media Exists فيفرض وصف المفاضلة كما هي، لا تحويلها إلى حملة مع المسودة أو ضدها.

المصادر

1. مجموعات OCM الاتحادية باستخدام MLS، نسخة WG 00
2. سجل Datatracker الحالي
3. تاريخ الوثيقة
4. السلف الفردي، النسخة 02
5. رسالة نتيجة التبني
6. مجموعة عمل Open Cloud Mesh
7. RFC 9420 — Messaging Layer Security
8. RFC 9750 — بنية MLS
9. MLS Virtual Clients، النسخة 01
10. بروتوكول Open Cloud Mesh الأساسي، نسخة WG 06
11. سجلات IANA لـMessaging Layer Security
12. Heng Lu — The Policy Mirror
13. Heng Lu — Minimum Initial Specification
14. Heng Lu — Why BTW Media Exists