الخلاصة

  • ترد النسخة 22 من مشروع JOSE HPKE في جدول اجتماع IESG يوم 24 سبتمبر للنظر فيها معياراً مقترحاً. حالتها العلنية ما زالت «قيد التقييم»، ولم يكتمل قرار الاعتماد أو عمل IANA.
  • أزالت جولة التعليقات الثانية HPKE-4-KE وHPKE-6-KE لأن JOSE لا يسجل ChaCha20/Poly1305 خوارزميةً لتشفير المحتوى، بينما أبقت HPKE-4 وHPKE-6 في نمط التشفير المتكامل.
  • لا تكفي عبارة «يدعم HPKE» لإثبات أي نمط JWE أو اقتران بين alg وenc أو عدد مستلمين تدعمه منظومة معينة.

للبدء من المسار الأبسط: في التشفير المتكامل يعالج HPKE النص نفسه، وليس مفتاحاً وسيطاً. تحدد المسودة مستلماً واحداً بالضبط، وتمنع وجود الحقل enc في ترويسة JWE لأنه لا يوجد تشفير محتوى منفصل. وتظل في قائمة هذا المسار ثمانية معرّفات مقترحة، منها HPKE-4 وHPKE-6 اللذان يستخدمان ChaCha20Poly1305 داخل HPKE. بقاؤهما ينفي تفسير الحذف بأنه حكم عام بعدم أمان تلك الخوارزمية.

أما المسار الذي يحمل اللاحقة -KE فله تقسيم آخر للعمل. يشفّر HPKE مفتاح تشفير المحتوى CEK، ثم تحدد قيمة enc الخوارزمية التي تشفّر محتوى JWE. ويمكن لصيغة JSON أن تخدم أكثر من مستلم، بما في ذلك مستلمون يستعملون طرائق أخرى لإدارة المفاتيح. يحمل ek السر المُغلّف، وتربط بنية سياق المستلم قيمة enc باشتقاق مفتاح HPKE. بقيت في جدول -KE ستة أرقام فقط: 0 و1 و2 و3 و5 و7.

يكشف سجل الإجراءات سبب الفراغ عند الرقمين 4 و6. فقد طلبت جولة Last Call ثانية، انتهت في 3 أغسطس، توافقاً على سحبهما من تشفير المفتاح لأن JOSE لا يملك تسجيلاً لـChaCha20/Poly1305 بوصفها خوارزمية تشفير المحتوى. وفي تعليق التصويت المؤرخ 15 سبتمبر، وصفت مسؤولة المجال هذا السحب بأنه التغيير الوحيد في الجولة الثانية. وظيفة AEAD داخل HPKE ليست خانة التسجيل نفسها التي يشغلها تشفير المحتوى في JWE؛ لا يجوز استعارة الإذن من إحداهما للأخرى.

يظهر متتبع IETF عدداً كافياً من المواقف المؤيدة للمرور، كما يدرج النص في جدول اليوم. لكنه لم يسجّل بذلك قراراً نهائياً. وحالة IANA هي «OK – Actions Needed»، لا اكتمال تسجيل المعرّفات. ولا تقدم هذه الوثائق دليلاً على نشر تجاري أو حادثة أمنية. الخبر هنا أن حدود التوافق أصبحت أوضح قبل تثبيت الوعد الذي سيقدمه منفذو البرمجيات.

المصادر