الخلاصة

  • تسجل RFC 9509 القيم id-kp-jwt وid-kp-httpContentEncrypt وid-kp-oauthAccessTokenSigning لثلاث مهام أمنية متميزة في نظام 5G.
  • تسمح مواصفة 3GPP الحالية بشهادة لكل غرض أو بشهادة متعددة الأغراض؛ ويغيّر الاختيار نطاق أثر اختراق المفتاح أو تجديده أو إبطاله.
  • لا يغني OID عن الثقة الأولية وهوية وظيفة الشبكة وKU ومعالجة JOSE والادعاءات وسياسة التفويض ودليل تنفيذ الخدمة.

يظهر معنى محفظة الشهادات عند أول حادث، لا عند إصدارها. إذا أبطل المشغّل شهادة بسبب خلل في توقيع Client Credentials Assertion، فهل تتوقف معها هوية TLS؟ وإذا كُشف مفتاح مخصص لـJWE، فهل تمتد الخسارة إلى توقيع رموز الوصول؟ تحدد بنية المحفظة الجواب قبل أن يبدأ التحقيق.

نشرت RFC 9509 في مارس 2024 كمعيار مقترح؛ وتثبت صفحة RFC Editor وسجل IETF Datatracker وضعها ومسارها. أما سجل SMI لدى IANA فيمنح الرقم 37 لـid-kp-jwt و38 لـid-kp-httpContentEncrypt و39 لـid-kp-oauthAccessTokenSigning.

يخص الأول التحقق من توقيع JWS على JWT، ومنه إقرار CCA. ويخص الثاني حماية JSON في HTTP بواسطة JWE، مثل معالجة مفتاح تشفير المحتوى بين SEPPs. ويخص الثالث توقيع رموز الوصول في OAuth 2.0. ولا تختفي بذلك أغراض TLS القائمة للعميل والخادم.

يمنع هذا الفصل انتقال السلطة بلا قرار. فامتلاك وظيفة مستهلكة لشهادة TLS لا يعطيها حق توقيع CCA، وقدرة المفتاح الرياضية على التوقيع ليست تفويضاً. لذلك تربط RFC الغرض بـKey Usage: مهام التوقيع تحتاج صلاحية توقيع، ومثال نقل المفتاح في JWE يحتاج keyEncipherment.

السجل يسمّي الغرض ولا يصمم المحفظة

تفرض RFC 5280 توافق KU وEKU معاً عند وجودهما. ولا تمنع RFC 9509 إضافة أغراض أخرى. ويستطيع الطرف المعتمد تطبيق نموذج الأغراض المسموحة والمستبعدة في RFC 9336، بما في ذلك رفض تركيبات محددة أو غياب EKU أو anyExtendedKeyUsage.

تجعل 3GPP TS 33.310 V19.5.0 القرار صريحاً: يمكن للتنفيذ استخدام شهادة مختلفة لكل غرض، أو شهادة واحدة تحمل أغراضاً متعددة، سواء في الثقة الأولية أو في شهادة NF النهائية.

تفصل الشهادات السلطة. إبطال شهادة CCA لا يلغي TLS بالضرورة، وانكشاف مفتاح JWE لا ينقل صلاحية توقيع رمز OAuth. لكن عدد المفاتيح وطلبات التسجيل والتوزيع والتجديد وتواريخ الانتهاء ومسارات الإبطال وإعدادات أدوات التحقق يزداد.

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

الغرض ليس هوية وظيفة الشبكة

تبدأ TS 33.310 بثقة أولية مبنية على شهادة OAM أو معلمات ملف NF موقعة أو مفتاح مصادقة أولي. تتحقق RA/CA التابعة للمشغّل من حيازة المفتاح وNF Instance ID، ومن NF type عند الحاجة. وإذا احتوت الثقة الأولية على EKU أمكن مطابقة الغرض في الطلب قبل إصدار الشهادة النهائية.

إذن لا يحدد id-kp-jwt هوية الوظيفة؛ بل يصف استخداماً مصدقاً للمفتاح. تبقى هوية المثيل في subjectAltName ومسار الشهادة وحالة الإبطال وسجل التسجيل أدلة مستقلة.

تضيف 3GPP TS 33.501 V19.5.0 طبقات التشغيل. فـCCA رمز JWT توقعه وظيفة مستهلكة، ويتحقق المستلم من JWS والهوية والزمن. وفي OAuth يكون NRF خادم التفويض، والمستهلك عميلاً، والمنتج خادم موارد. يفحص المنتج الجهة المصدرة المسموحة والتوقيع والموضوع والجمهور ومعرفات الشريحة أو مجموعة الخدمة عند وجودها والنطاق والموارد والأفعال الإضافية والانتهاء، وقد يطابق CCA بهوية TLS. ثم فقط ينفذ الخدمة.

تصف 3GPP TS 29.500 الواجهات القائمة على الخدمات، وتفصل TS 29.573 سياق الربط بين PLMN وSEPP. لا يثبت EKU الخاص بالتشفير أن كائن JSON بعينه كان مسموحاً أو وصل أو فُك أو نُفذ.

قد يتأخر الاكتشاف عن الإبطال

تذكر TS 33.310 أن NRF قد يعيد منتجاً أبطلت شهادته إذا لم تصل إليه المعلومة. حالة الشهادة وحالة الاكتشاف ليستا شيئاً واحداً. لذلك يحفظ السجل طريقة الثقة الأولية، وهوية NF ونوعها، والشهادة والمفتاح والمسار، وKU/EKU، والتركيبات، وخوارزمية JOSE ورؤوسها، والادعاءات، وإصدار السياسة، ودليل الإبطال، والطلب والرد والقياس التشغيلي.

وقد يكون الغرض مرئياً أيضاً. يمكن أن يكشف TLS 1.2 الشهادة، بينما يحمي TLS 1.3 رسائلها بعد ServerHello، وقد تنشر شفافية الشهادات شهادة موثوقة علناً. المرئي هو القدرة المعدة، لا حدوث العملية.

المنظور التحريري معلن: أولوية الشيفرة العاملة، وطبقات الواقع، والمواصفة الأولية الدنيا مع القرار المحلي. يوفر السجل لغة مشتركة، لكنه لا ينقل مسؤولية بنية المفاتيح أو نتيجة الخدمة من المشغّل.