يدفع JOSE خوارزميتين نحو الإهمال من دون مهلة للاستثناءات المحلية

الخلاصة

• في 6 سبتمبر أحالت مجموعة JOSE النسخة 05 من مسودة إهمال none وRSA1_5 إلى IESG طالبة نشرها. هذه إحالة في مسار المعايير، وليست موافقة من IESG أو RFC أو تعديلاً منفذاً في سجل IANA.
• تفرض المسودة تعطيل الخوارزميتين افتراضياً وتمنع المواصفات الجديدة من إجازتهما، لكنها تسمح لتطبيق قائم بتفعيل إحداهما لأغراض أو عمليات محددة. كي يبقى هذا القرار محلياً ومحدوداً، يحتاج إلى مالك ومراجعة وموعد انتهاء.

أربع قواعد لا حظر واحد

يسجل تاريخ Datatracker في 6 سبتمبر 2026 انتقال الوثيقة إلى “Submitted to IESG for Publication”، وانتقال حالة IESG إلى “Publication Requested”، وتعيين Deb Cooley مديرة المنطقة المسؤولة، وإضافة تقرير document shepherd.

لا تعني هذه الخطوات أن النص أصبح معياراً نافذاً. فالنسخة 05 مؤرخة في 23 يونيو وما زالت Internet-Draft قابلة للمراجعة أو الاستبدال. ولم يوافق عليها IESG ولم تنفذ IANA التغييرات المقترحة. عند إقفال الأدلة كان سجل JOSE يعرض none بصفة Optional وRSA1_5 بصفة Recommended-. هذا فرق طبيعي بين المقترح والحالة الحالية، وليس دليلاً على رفض أو تأخير.

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

والصفة المقصودة هي Deprecated لا Prohibited. تستطيع المواصفات والتطبيقات القائمة مواصلة الاستخدام، مع تشجيعها على اعتماد بدائل في تحديثاتها. كما توضح المسودة أن خوارزميات توقيع RSA المسماة RS256 وRS384 وRS512 لا تتغير؛ أما RSA1_5 هنا فهو معرف لإدارة المفاتيح RSAES-PKCS1-v1_5 في JWE.

لذلك لا تكفي عبارة «حظرت JOSE الخوارزمية». فحالة السجل، ووجود الشفرة في المكتبة، وضبط التطبيق، وقبول معاملة حية، أربع وقائع مستقلة.

سبب أمني قوي ودين توافق حقيقي

ينشئ none رسالة JWS غير مؤمنة، بلا توقيع أو MAC. وكانت RFC 7518 تمنع أصلاً قبولها افتراضياً، إلا أن المسودة تسرد ثغرات نتجت من تطبيقات قبلتها خطأ. ويستخدم RSA1_5 تشفير RSA مع حشو PKCS #1 v1.5، المعروف بمشكلاته منذ هجوم Bleichenbacher عام 1998. وتشير الوثيقة إلى OAEP وأساليب المنحنيات الإهليلجية بوصفها بدائل، وتستشهد بإرشاد NIST للانتقال في الأنظمة الفيدرالية الأمريكية.

لكن التوافق القديم ليس وهماً. تتضمن OpenID Connect Core استخدامات تاريخية لـID Tokens غير الموقعة والمحمي نقلها عبر TLS، وrequest objects غير موقعة. ويقول تقرير shepherd إن النقاش في IETF 124 تبعه نداء توافق لمدة أسبوعين في فبراير 2026. اعترف النص التوافقي بهذه الحالات من دون التخلي عن نتيجة الإهمال.

ويذكر التقرير أن Working Group Last Call، الذي مُدد لجمع مزيد من الآراء، تلقى تأييداً بلا معارضة. وسجل استطلاع في IETF 126 تأييد 27 شخصاً للنشر ومعارضة صفر وامتناع ثمانية عن إبداء الرأي. هذه قرينة على قرار المجموعة بالمضي، وليست إحصاء للتطبيقات أو المستخدمين أو الاعتمادات.

لا ينبغي أن تصبح IANA مراقباً لإعدادات التطبيقات

يستطيع سجل IANA أن يبين معنى المعرف ومرجعه والجهة المتحكمة ومستوى التوصية. وتقترح المسودة أيضاً معايير أمن أساسية للتسجيلات المقبلة: EUF-CMA لتوقيعات JWS وخوارزميات MAC، وIND-CCA2 لعملية تشفير JWE كلها عند تقييم إدارة المفاتيح، وAEAD لتشفير المحتوى. ولا تطبق هذه المعايير الجديدة على خوارزمية تسجل منذ البداية كـDeprecated أو Prohibited.

لكن IANA لا ترى أن خدمة ما أعادت تفعيل none لفئة قديمة من الأغراض، ولا أن شريكاً ما زال يرسل RSA1_5. ولا تنشئ المسودة قناة قياس أو قاعدة استثناءات أو بروتوكول انتقال. ويصرح shepherd بأنها لا تعرف آلية بروتوكول جديدة تحتاج إلى تنفيذ.

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

ينبغي أن يربط سجل الاستثناء الخوارزمية الدقيقة، واستخدام JWS أو JWE، والغرض أو العملية المسموحين، والخدمة والمسؤول، والاعتماد الذي يمنع الإزالة، والضوابط التعويضية، واختبار بقاء الضبط العام معطلاً، وأول وآخر استخدام مرصودين، ومسار الاستبدال، وتاريخ المراجعة، وموعد الانتهاء. هذا اقتراح تحريري، وليس مطلباً في المسودة أو RFC 7518 أو IANA أو NIST أو OpenID Connect.

ساعة عامة وأخرى محلية

تمر الساعة العامة بمراجعة Area Director، ثم IETF Last Call محتمل، وتقييم IESG، وربما نشر RFC، ثم تحديث IANA. ما زال ملخص Datatracker يعرض Internet Standard، بينما يطلب shepherd صفة Proposed Standard ويصف البيانات الأولى بأنها غير صحيحة. هذا اختلاف مفتوح في السجل، لا حالة نهائية ولا برهان خلل إجرائي.

وتبدأ الساعة المحلية عندما يعيد التطبيق فتح المسار عمداً. من دون انتهاء تبقى «الحاجة المحددة» بعد زوال الاعتماد. ومن دون دليل آخر استخدام لا يعرف الفريق إن كان يحمي توافقاً حياً أم مفتاحاً منسياً. ومن دون مسؤول تحول ترقية المكتبة الخلاف المتأخر إلى خيار بين انقطاع الخدمة وفتح واسع.

يضع طرح Heng Lu حول الحد الأدنى للمواصفة الأولية القاعدة الآمنة وحدود المواصفات الجديدة في الطبقة المشتركة، ويترك القرار اللاحق محلياً. وتفصل أولوية الشفرة العاملة بين نشر النص وتشغيله: الإعداد والمعاملات المرصودة هما دليل ما بقي مفتوحاً.

أصابت المسودة في توزيع السلطة. وما ينقص ليس إدارة مركزية أثقل، بل استثناء محلي مسمى ومحدود ومرصود وقابل للموت.

المصادر

1. IETF Datatracker — إهمال none وRSA1_5
2. تاريخ Datatracker وتقرير shepherd
3. Internet-Draft، النسخة 05
4. RFC 7518 — JSON Web Algorithms
5. IANA — سجل JOSE
6. RFC 5116 — التشفير الموثق
7. RFC 8017 — PKCS #1 الإصدار 2.2
8. NIST SP 800-131A، المراجعة 2
9. OpenID Connect Core 1.0
10. مستودع مصدر المسودة
11. Heng Lu — Minimum Initial Specification
12. Heng Lu — Running-Code Primacy