الخلاصة

  • قدّمت مجموعة HPKE النسخة 05 من مشروع الخليفة في 25 سبتمبر، ثم أصدر IESG في اليوم التالي ورقة تصويت للموافقة ووضعها على جدول اجتماع 8 أكتوبر. ما زال النص قيد التقييم، واستبدال RFC 9180 مشروط بالموافقة والنشر.
  • تحدد المسودة وضع Base بالقيمة 0x00 ووضع PSK بالقيمة 0x01، بينما تصف 0x02 و0x03، اللتين خُصصتا لوضعي Auth وAuthPSK في RFC 9180، بأنهما محجوزتان. كان هذا الترتيب موجوداً في النسخة 04 أيضاً.
  • يبقى حقل Auth في سجل خوارزميات KEM للتوافق مع واجهة RFC 9180، لكن النص المقترح لا يستخدمه. لا يكشف السجل وحده أي تطبيق يحتاج تلك الواجهة أو ما إذا كان تغيّر المرجع قد حافظ على ضمان هوية المرسل.

لا يختبر مستلم الرسالة شيئاً واحداً حين يقال له إن نظامه «يستخدم HPKE». فقد يكون المقصود تشفير البيانات إلى مفتاحه العام، وقد يكون المطلوب أيضاً إثبات امتلاك المرسل مفتاحاً خاصاً معيناً. تسير المسودة الجديدة إلى مراجعة IESG بصفتها خلفاً لـRFC 9180، إلا أن مسار التوثيق الثاني لا ينتقل معها كله. وهنا تختلف سلطة هيئة المعايير على مرجع الوثيقة عن مسؤولية التطبيق عما يعد به المستخدم.

توضح الأرقام القصيرة المسألة من دون مبالغة. يضم RFC 9180 أربعة أوضاع: Base وPSK وAuth وAuthPSK. يحدد مشروع الخليفة أول وضعين فقط ويترك القيمتين المرتبطتين بالآخرين محجوزتين. يقول ملحق الفروق إن العمل أزال Auth وAuthPSK، ويقول كذلك إن السلوكيات المشتركة بين الوثيقتين ينبغي أن تتطابق. لا يشمل وعد التوافق ميزة لم تعد موصوفة في النص الجديد. وفي المقابل، لا يصح القول إن التوثيق اختفى تماماً: وضع PSK يثبت حيازة سر مشترك مسبقاً. غير أن هذه الحيازة ليست بذاتها إثبات حيازة المفتاح الخاص غير المتماثل للمرسل في وضع Auth القديم.

لم يقع هذا التمييز لأول مرة مع النسخة 05. جدول النسخة 04 وضع القيمتين القديمتين في خانة الحجز بالفعل. الخبر المؤرخ في نهاية سبتمبر هو انتقال المشروع إلى مرحلة أخرى: إيداع نسخة جديدة في الخامس والعشرين، ثم إصدار بطاقة الموافقة وتحويل الحالة إلى تقييم IESG وإدراجه لاجتماع الثامن من أكتوبر في السادس والعشرين. عند الفحص، ما زالت هناك مواقف تصويت لازمة، ومراجعة جديدة لدى IANA بسبب تغير النسخة. وصف المسودة بأنها ستُبطل RFC 9180 يتضمن شرط الموافقة؛ لا يعني أن ذلك حدث الآن.

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

تضيف أحكام IANA دليلاً على بقاء أثر النص السابق من غير أن تضفي عليه حكماً تشغيلياً جديداً. تقترح المسودة تحديث مراجع التسجيل إذا اعتمدت، وتُبقي معرفات KEM القائمة كما هي. وتحتفظ خانات تسجيل KEM بقيمة منطقية اسمها Auth للدلالة على واجهتي AuthEncap() وAuthDecap() الواردتين في RFC 9180، موضحةً أن الخلف المقترح لا يستخدم هذه الخانة. يستطيع القارئ إذن رؤية قابلية الواجهة القديمة في السجل، لكنه لا يستطيع منه استنتاج ما تستدعيه خدمة بعينها أو ما يقبله الطرف الآخر أو أي ضمان لهوية المرسل توفره طبقة التطبيق.

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

المصادر