Résumé
- La RFC 9509 enregistre
id-kp-jwt,id-kp-httpContentEncryptetid-kp-oauthAccessTokenSigningpour distinguer trois tâches de sécurité dans l’architecture 5G. - La spécification 3GPP actuelle autorise un certificat par usage ou un certificat portant plusieurs usages ; ce choix modifie le rayon d’impact d’une compromission, d’une rotation ou d’une révocation.
- L’identifiant d’usage ne remplace ni la confiance initiale, ni l’identité de la fonction réseau, ni les contrôles JOSE, les claims, l’autorisation ou la preuve que le service a été exécuté.
Le premier choix n’est pas cryptographique, mais architectural : combien de certificats une fonction réseau doit-elle porter ? Un seul peut être plus simple à renouveler. Plusieurs peuvent empêcher qu’une clé destinée à l’authentification TLS serve aussi à signer une Client Credentials Assertion ou un jeton d’accès. Dans les deux cas, le nombre de lignes d’inventaire dit quelque chose du pouvoir accordé aux clés.
La RFC 9509, publiée comme Proposed Standard selon sa fiche RFC Editor et son dossier Datatracker, apporte les noms communs. Le registre SMI de l’IANA attribue désormais 37 à id-kp-jwt, 38 à id-kp-httpContentEncrypt et 39 à id-kp-oauthAccessTokenSigning.
Le premier usage vise la validation d’une signature JWS sur un JWT, notamment l’attestation CCA d’un consommateur de service. Le deuxième identifie la protection de contenu JSON avec JWE, par exemple entre Security Edge Protection Proxies. Le troisième concerne la signature des jetons dans la chaîne OAuth 2.0. Les usages TLS client et serveur existaient déjà ; ils ne sont pas remplacés.
Cette séparation répond à un risque précis. Une fonction consommatrice ne doit pas devenir productrice par héritage de certificat. Une clé autorisée à établir TLS ne doit pas être admise automatiquement pour signer une CCA. La RFC demande donc au vérificateur d’exiger l’EKU correspondant lorsque la politique le prévoit, et au demandeur d’aligner Key Usage sur l’opération : capacité de signature pour JWS, keyEncipherment pour l’exemple de transport de clé JWE.
Un certificat ou plusieurs : le registre ne tranche pas
La RFC 5280 impose de respecter simultanément KU et EKU lorsqu’ils figurent tous deux dans le certificat. Mais la RFC 9509 permet d’ajouter d’autres usages. Le modèle d’usages permis et exclus de la RFC 9336 laisse au logiciel dépendant le soin d’interdire une combinaison, l’absence d’EKU ou anyExtendedKeyUsage.
La TS 33.310 V19.5.0 rend le dilemme explicite : une implémentation peut déployer un certificat différent pour chaque finalité ou un certificat contenant plusieurs finalités, aussi bien pour la confiance initiale que pour le certificat final de la fonction réseau.
La séparation réduit la portée sémantique d’une clé. La révocation du certificat CCA peut laisser fonctionner TLS ; la compromission d’une clé de déchiffrement JWE ne donne pas mécaniquement la capacité de signer des jetons. En contrepartie, il faut gérer davantage d’enrôlements, de délais d’expiration, de rotations, de listes de révocation, de chemins et de dépendances.
Le certificat multi-usages réduit ce nombre. Il réunit aussi plusieurs services derrière une même clé et un même événement de révocation. Une rotation urgente peut alors interrompre des fonctions sans rapport immédiat. Ce sont des conséquences opérationnelles des deux modèles, pas une préférence universelle attribuée à l’IETF ou au 3GPP.
L’identité ne se déduit pas de l’usage
La chaîne commence avant l’émission. TS 33.310 prévoit une confiance initiale fondée sur un certificat OAM, des paramètres de profil signés ou une clé d’authentification initiale. L’autorité vérifie la preuve de possession, l’identifiant de l’instance NF et, le cas échéant, le type NF. Si l’EKU est présent dans la confiance initiale, elle peut contrôler sa correspondance avec la demande avant de produire le certificat final.
Ainsi, id-kp-jwt décrit une finalité certifiée ; il ne nomme pas l’instance, ne prouve pas que le demandeur conserve la clé et n’accorde aucun service. Le subjectAltName, le chemin validé, l’état de révocation et la preuve d’enrôlement restent des reçus distincts.
À l’exécution, la TS 33.501 V19.5.0 allonge encore la chaîne. Une CCA est un JWT signé par le consommateur ; le destinataire valide JWS, l’identité et le temps. Pour OAuth, le NRF est serveur d’autorisation, le consommateur est client et le producteur est serveur de ressources. Le producteur vérifie l’émetteur admis, la signature, le sujet, l’audience, les identifiants de tranche ou de service lorsqu’ils existent, le scope, les actions supplémentaires et l’expiration. Le service n’est exécuté qu’après ces contrôles.
La TS 29.500 décrit la réalisation des interfaces de service ; la TS 29.573 précise le contexte inter-PLMN et SEPP. Un EKU de chiffrement ne prouve donc ni la conformité d’un objet JSON, ni son autorisation, ni sa livraison ou son traitement.
La révocation révèle l’architecture réelle
TS 33.310 observe qu’un NRF peut retourner une instance productrice dont le certificat a déjà été révoqué si cette information ne lui est pas encore parvenue. Le portefeuille détermine alors si l’incident affecte une seule tâche ou plusieurs. Le journal d’audit doit conserver l’origine de la confiance, l’instance et le type NF, le certificat exact, KU/EKU, les combinaisons autorisées, les paramètres JOSE, les claims, la version de politique, la preuve de révocation, la requête, la réponse et la télémétrie de service.
La finalité peut aussi être visible. TLS 1.2 peut exposer le certificat sur le réseau, tandis que TLS 1.3 protège les messages de certificat après ServerHello. La Certificate Transparency peut publier des certificats de confiance publique. Cela révèle une capacité prévue, jamais la preuve qu’elle a été exercée.
La grille éditoriale est déclarée : la primauté du code exécuté demande quelle règle a réellement fonctionné ; les couches de réalité séparent l’intention du résultat ; la spécification initiale minimale conserve un vocabulaire commun sans confisquer le choix local. Ici, l’IANA nomme les métiers ; l’opérateur gouverne encore les clés.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

