الخلاصة

  • وافقت IESG في 24 سبتمبر 2026 على draft-ietf-jose-hpke-encrypt-22 للنشر بصفة Proposed Standard. ما زال النص Internet-Draft، وليس RFC منشوراً ولا دليلاً على تشغيل فعلي.
  • يشفر Integrated Encryption النص مباشرة عبر HPKE لمستلم واحد بالضبط. أما Key Encryption فيحمي مفتاح تشفير محتوى مشتركاً، ويسمح بوجود مستلمي HPKE وECDH وRSA في كائن JWE JSON واحد.
  • يفرض المشروع نجاح مستلم واحد على الأقل، لكن التطبيق هو الذي يقرر إن كان ذلك كافياً أم يجب نجاح الجميع. كما تقيد أضعف خوارزمية مستخدمة لحماية CEK سرية المحتوى كله.

وصول النص لا يعني اكتمال التوزيع

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

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

لهذا كانت موافقة 24 سبتمبر حدثاً مهماً لكن محدوداً. وافقت IESG على الإصدار 22 من عمل JOSE حول HPKE مع JWE للنشر كمعيار مقترح. تثبت الموافقة مرحلة في مسار المعايير، ولا تصادق على منتج أو إعداد أو حفظ مفاتيح أو توافق بين تنفيذين أو تطبيق سياسة داخلية. كما أن مرحلة RFC Editor لم تنته بعد.

نمطان وبنيتان مختلفتان للإثبات

في Integrated Encryption، يشفر HPKE النص نفسه. لا يوجد CEK منفصل، ولذلك يجب ألا يظهر enc. يحتوي الرأس المحمي على alg يحدد حزمة HPKE كاملة، ويُحظر ek، ويلزم وجود مستلم واحد. يحمل JWE Encrypted Key السر المغلف الخاص بـ HPKE، بينما تبقى خانات IV وAuthentication Tag في JWE فارغة لأن AEAD جزء من العملية المدمجة.

أما Key Encryption فيفصل طبقة المحتوى عن طبقة الوصول إلى المفتاح. يُولَّد CEK عشوائي ويشفر المحتوى مرة واحدة وفق enc، ثم يشفر HPKE ذلك المفتاح لكل مستلم HPKE. يحتوي JWE Encrypted Key لذلك المستلم على ciphertext الخاص بـ CEK، ويحمل ek السر المغلف. وتربط Recipient_structure سياق JOSE وخوارزمية تشفير المحتوى ومعلومة تطبيقية اختيارية بجدول اشتقاق مفاتيح HPKE.

تسمح هذه الوساطة بتعدد المستلمين. يمكن في JWE JSON وضع مستلم HPKE إلى جانب ECDH-ES+A128KW أو RSA-OAEP-256. لكل مستلم مسار محمي مختلف إلى CEK واحدة، ولا يُشفر جسم الرسالة مرة أخرى.

هذه مرونة مفيدة للانتقال التدريجي وللاحتفاظ بمفتاح تعافٍ. لكنها تجعل الظرف كله، لا أحدث فرع فيه، وحدة القرار الأمني.

«واحد على الأقل» حد بروتوكولي أدنى

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

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

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

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

أضعف فرع يصل إلى المفتاح نفسه

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

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

وتبين قصة الإصدار 22 أهمية تسجيل النمط بدقة. تناولت جولة ثانية من Working Group Last Call في JOSE حذف HPKE-4-KE وHPKE-6-KE تحديداً. غاب معرفا Key Encryption عن الإصدار 22، بينما بقي HPKE-4 وHPKE-6 في Integrated Encryption. عبارة «يدعم HPKE» لا تسجل الفرق الذي تغير فعلاً.

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

تساعد عدسة Heng Lu حول طبقات الواقع هنا. موافقة IESG حقيقة مؤسسية. alg حقيقة في صيغة الرسالة. نجاح مستلم حقيقة تشفيرية. قائمة المستلمين واختيار «واحد أم الجميع» حقيقتان في طبقة التحكم. أما قرار التطبيق المشاهد فهو حقيقة تشغيلية مستقلة، ولا يمكن افتراضه من الطبقات السابقة.

المصادر