الخلاصة

  • تقترح المراجعة 06 تصنيف JWS none وJWE RSA1_5 بأنهما Deprecated لا Prohibited؛ وعلى التطبيقات تعطيلهما افتراضياً مع السماح باستثناء يخص كائناً أو عملية محددة فقط.
  • لم يكن سجل JOSE الحي لدى IANA قد طبّق التغيير في 29 سبتمبر 2026، وحتى إذا تغير الوسم لاحقاً فلن يثبت أن المكتبة فقدت القدرة أو أن طلباً بعينه رُفض.
  • ينبغي أن يصل إيصال الإخراج من الخدمة بين نوع الكائن والعملية وalg وenc، وقائمة السماح بعد حل السياسة، وقدرات البناء الفعلية، ومالك الاستثناء ونطاقه وانتهائه، والنتيجة، والسلطة التي منحتها.

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

نُشرت المراجعة 06 من «JOSE: Deprecate 'none' and 'RSA1_5'» في 25 سبتمبر 2026. وتبين صفحة Datatracker أنها Internet-Draft في مرحلة النداء الأخير لدى IETF حتى 9 أكتوبر، مع حاجة إلى مراجعة IANA. أما سجل التاريخ فيثبت حركة الوثيقة، لا تغيير أي خدمة عاملة.

الخياران لا يؤديان الوظيفة نفسها. ففي JWS، يعني none كائناً بلا توقيع وبلا رمز مصادقة للرسالة. يحدد RFC 7515 إطار JWS، وكان RFC 7518 قد اشترط بالفعل ألا تقبل التطبيقات JWS غير المحمي افتراضياً. وحين تسمح البرمجية لقيمة alg القادمة من المدخل باختيار مسار التحقق، قد يتحول تصريح الخصم إلى مفتاح يعطل المصادقة.

أما RSA1_5 فهو خوارزمية إدارة مفاتيح تستخدم RSAES-PKCS1-v1_5 في نموذج JWE الموصوف في RFC 7516. وهو ليس RS256 أو RS384 أو RS512؛ فتلك خوارزميات توقيع JWS، بينما RSA1_5 معرّف لتشفير المفتاح. لذلك فإن حظر كل اسم يحوي RSA قد يعطل عمليات سليمة من دون أن يغلق المسار الضعيف. يصف RFC 8017 مخططات RSA الأساسية، وتوضح إرشادات CFRG الحالية أن توحيد الإخفاق ومقاومة أوراكل فك التشفير خصائص تنفيذية.

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

هذه خطة انتقال لا إعلان محو. فالطلب إلى IANA هو Deprecated لا Prohibited، ما يترك للتطبيقات والمواصفات القائمة وقتاً للهجرة. وعند جمع الأدلة لهذه المقالة، كان سجل JOSE لدى IANA ما يزال يعرض none بوصفه Optional وRSA1_5 بوصفه Recommended-. وإذا تغير السجل لاحقاً فسيتغير الوصف المشترك، لكن بوابات API وحزم SDK ووحدات التشفير وملفات الاستثناء وإعدادات المستأجرين لن تتغير تلقائياً.

لذلك تبدأ الحجة التشغيلية بعد الوسم. يجب تسجيل فئة كائن JOSE وعملية العمل، ثم alg المحمي وenc في حالة JWE؛ والمُصدر والجمهور والمستأجر والمسار؛ وقائمة السماح الفعلية بعد حل هذه المحددات؛ وإصدار المكتبة والقدرات المترجمة داخل البناء؛ ومصدر أي استثناء وصاحبه ونطاقه وتاريخ انتهائه؛ ونوع المفتاح؛ وقرار القبول أو الرفض؛ وأي هوية أو إجراء اكتسب السلطة بسببه.

وفي JWE، يجب أن يشمل الدليل شكل الإخفاق. فالاختلاف في الرسالة أو الحجم أو الزمن قد يحول نقطة فك التشفير إلى أوراكل، حتى إن وصفتها لوحة الإدارة بأنها استثناء محدود. يقدم NIST SP 800-131A Revision 2 سياقاً للانتقال، لكنه لا يثبت أن خدمة محلية جعلت كل مسارات الخطأ متماثلة.

يطالب RFC 8725 تطبيقات JWT بالتحقق من الخوارزمية وعدم الاعتماد على خيار يتحكم فيه المهاجم. عملياً، يعلن رأس الرسالة طريقة المعالجة المطلوبة، لكنه لا يملك سلطة اختيار المتحقق. تلك السلطة تعود إلى قائمة السماح الفعلية في التطبيق.

وتضع المسودة أيضاً عتبات للمستقبل: ينبغي لخوارزميات توقيع وMAC الجديدة في JWS تحقيق EUF-CMA، ولعملية تشفير JWE الكاملة تحقيق IND-CCA2، ولتشفير المحتوى توفير AEAD كما في RFC 5116. هذه قواعد مراجعة نافعة، لا نتائج اختبار لبناء بعينه، ولا علاج لأخطاء تركيب المفاتيح والتحليل والسياسة.

تضع فكرة Heng Lu عن أولوية الشيفرة العاملة حدث القبول فوق تسمية الجرد. وتفصل طبقات الواقع بين رمز التقادم وحقيقة أن رسالة اكتسبت سلطة. وتبين المواصفة الأولية الدنيا كيف يضع النظام المشترك افتراضاً آمناً، فيما يبقى النظام المحلي مسؤولاً عن كل استثناء ضيق.

لا يكتمل الإخراج من الخدمة إلا عندما ترفض كل المسارات المعنية افتراضياً، ويكون كل قبول باقٍ محدداً ومنسوباً وقابلاً للقياس ومؤقتاً. وحتى ذلك الحين، تكون كلمة Deprecated لافتة عند المدخل، لا إيصالاً صادراً من نقطة القرار.

المصادر