الخلاصة

  • يصنّف RFC 9955 أهداف تصميم التواقيع الهجينة؛ وصول مكونات متعددة لا يثبت أن كل مستقبل تحقّق منها جميعاً.
  • قد تسمح التوافقية الخلفية بالتحقق من مكوّن واحد، بينما تحتاج عدم القابلية القوية للفصل والتحقق المتزامن إلى خصائص وتنفيذ أوضح.

أن يسجل النظام «توقيع هجين مستلم» حقيقة عن المدخل، لا عن حكم القبول. هل أوجب المستقبل المكوّنين؟ هل استخدم مساراً قديماً يتحقق من التقليدي وحده؟ هل توقف بعد نجاح أول؟ هذه أسئلة سياسة وتنفيذ ومسؤولية منفصلة.

RFC 9955 وثيقة IETF معلوماتية من يوليو 2026، ولا تختار مجمّعاً أو نشراً بعينه. تعرض أهدافاً مثل المصادقة الهجينة وقابلية تركيب البرهان وعدم القابلية للفصل والتوافق والتحقق المتزامن، وتبيّن أن هذه الأهداف قد تتعارض. كلمة «هجين» لا تحسم المقايضة.

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

RFC 9954 خاص بتبادل المفاتيح الهجين في TLS 1.3، وRFC 9794 مصطلحات؛ لا يثبت أي منهما سياسة جهة بعينها. يستخدم Daniel Kade docs/heng-lu-note.md كمنظور تحريري: احفظ المدخل والقاعدة والنتائج والاستثناء والقبول منفصلة.

المصادر