Summary

  • RFC 9509 registers id-kp-jwt, id-kp-httpContentEncrypt and id-kp-oauthAccessTokenSigning for distinct 5G certificate jobs that previously lacked standard EKU names.
  • Current 3GPP guidance allows either one certificate per purpose or a certificate carrying several purposes; that portfolio choice changes compromise, revocation and operational blast radius.
  • A complete decision still joins initial trust, NF identity, KU/EKU policy, JOSE processing, token claims, authorization and executed service evidence. No OID substitutes for that chain.

The certificate can be perfectly valid and still be the wrong instrument for the job. In a 5G Core, that is not an edge case. A Network Function can act as a TLS client, present a signed Client Credentials Assertion, consume encrypted JSON at a Security Edge Protection Proxy, or depend on an OAuth token signed by the Network Repository Function. Before March 2024, the PKIX registry had familiar TLS purposes but no common identifiers for three of those application jobs.

RFC 9509 filled that vocabulary gap. The RFC Editor record identifies it as a Proposed Standard; the IETF Datatracker preserves its publication path. The live IANA SMI registry now assigns decimal 37 to id-kp-jwt, 38 to id-kp-httpContentEncrypt and 39 to id-kp-oauthAccessTokenSigning under the PKIX key-purpose arc.

Those identifiers separate three operations. The first covers validation of a JWS signature on a JWT, including a 5G Client Credentials Assertion. The second covers public-key handling for JSON protected with JWE, such as wrapping a content-encryption key for protected HTTP content between SEPPs. The third covers signing an access token in the OAuth 2.0 authorization chain.

The distinction matters because a TLS client certificate should not silently inherit the authority to sign a CCA, and a consumer should not impersonate a producer merely because both possess operator-issued keys. RFC 9509 describes that cross-protocol risk directly. It tells verifiers to require the corresponding purpose when policy expects it, tells requesters to include the required purpose, and requires Key Usage to fit the cryptographic operation. Signature jobs need a signature-capable KU; the JWE key-transport example needs keyEncipherment.

The consequential decision comes after the registry

RFC 5280 supplies the base rule: when KU and EKU both appear, each constrains the key. RFC 9509 does not say that its three purposes must live on three certificates. It also does not prohibit other EKUs. The relying party may narrow combinations using the permitted and excluded purpose model described in RFC 9336.

That discretion is no longer merely implicit. The current 3GPP TS 33.310 says implementations may deploy a different certificate for each purpose or one certificate with multiple purposes, both for initial trust and for the final Network Function certificate. This is the portfolio decision RFC 9509 makes visible without settling.

Separate credentials narrow the semantic reach of each private key. Revoking a CCA-signing certificate need not remove a function's TLS identity; compromise of a JWE decryption key need not confer token-signing capability. The price is more inventory: more key generation, enrollment, renewal, expiry, revocation, distribution and verifier configuration.

A multi-purpose certificate can reduce that operational count. It can also couple several services to one key, one validation path and one revocation event. A rushed rotation for one purpose may interrupt the others. An overly broad permitted-combination rule can turn convenience into privilege inheritance. These are operational inferences from the permitted designs, not a universal command to choose one of them.

Purpose, identity and authorization are three different checks

The certificate portfolio begins before issuance. TS 33.310 describes initial trust through an OAM certificate, signed NF profile information or an initial authentication key. The operator RA/CA validates the request, proof of possession and NF Instance ID; where supplied, it also checks NF type. If initial trust carries a purpose, the requested EKU can be required to correspond before the final certificate is issued.

That sequence prevents an OID from impersonating identity. id-kp-jwt says what the certified key may be used for. It does not say which NF instance owns the key, whether the requester still controls it, or whether that NF may call a particular service. The NF Instance ID in subjectAltName, the validated path, revocation state and operator enrollment evidence answer different questions.

The runtime chain is longer still. Current 3GPP TS 33.501 defines the CCA as a JWT signed by the NF service consumer. Its receiver verifies the JWS and checks identity and time claims. For service authorization, the NRF acts as the OAuth authorization server, the consumer as client and the producer as resource server. A producer examines the authorized issuer, signature, subject alignment, audience, slice or service-set identifiers where applicable, scope, additional resource and action scope, expiry, and sometimes the CCA subject. Only after those checks does the procedure reach service execution.

The service-based interface details are carried in 3GPP TS 29.500. Inter-PLMN protected exchange and the SEPP context are specified further in 3GPP TS 29.573. In neither case does an encryption-purpose OID prove that a specific JSON object was well formed, authorized, delivered, decrypted or acted upon.

Lifecycle is part of authority

Certificate validity can drift away from discovery state. TS 33.310 notes that an NRF may return a producer whose certificate was revoked without the NRF knowing, creating avoidable signalling until validity is checked. That observation turns lifecycle into a control surface: portfolio design determines whether one revocation disables one job or several.

A defensible receipt therefore records the initial-trust method; NF instance and type; exact certificate, chain and key identifier; KU/EKU set; allowed and forbidden combinations; JOSE algorithm and headers; relevant JWT or access-token claims; authorization-policy version; revocation evidence; request and response; and service telemetry. A dashboard that stores only “certificate valid” erases the decisions that mattered.

Purpose metadata also has a visibility cost. TLS 1.2 can expose certificates on the wire, whereas TLS 1.3 protects certificate messages after ServerHello. Publicly trusted certificates can also become observable through Certificate Transparency. An EKU can therefore reveal what a key was prepared to do. It still does not reveal that the operation occurred.

The disclosed editorial doctrine is narrower than the technical sources. Running-code primacy asks what enforcement actually ran. Reality layers separates a declared capability from an executed result. Minimum initial specification values a shared vocabulary while preserving local implementation choice. RFC 9509 fits that pattern: the registry names the jobs; the operator must still govern the portfolio.