Summary

  • RFC 9734 registers id-kp-imUri, OID 1.3.6.1.5.5.7.3.40, so an X.509 certificate can say its key was issued for signing instant-messaging identity credentials rather than for general TLS client or server authentication.
  • The EKU constrains purpose. The account identifier belongs in subjectAltName, while path validation, reference-identifier matching, account-control evidence, revocation freshness and application authorization remain separate decisions.
  • In MLS, the certificate key must match the member’s LeafNode signing key, but the application still chooses acceptable identifiers and the Authentication Service still validates them. A valid certificate is one receipt in a longer admission chain.

The security review begins with a green row: chain valid, signature valid, id-kp-imUri present. The product converts the row into a sentence a human can understand: “Verified messaging identity.”

The sentence is too large for the evidence.

RFC 9734 defines one highly useful thing. Published on the Standards Track in February 2025, it assigns an Extended Key Usage identifier for certificates used with instant-messaging identity credentials. The purpose is narrower than id-kp-clientAuth or id-kp-serverAuth, reducing the chance that a credential issued for messaging can be carried into another protocol and accepted there.

The new identifier is not an account name. It is not an enrollment ceremony, a revocation response, a group-admission rule or a delivery receipt. It answers “what kind of signing was this key certified for?” It does not, by itself, answer “whose account is this now?”

One certificate carries several different propositions

The distinction is visible in RFC 5280. Extended Key Usage states one or more purposes for which a certified public key may be used. Subject Alternative Name binds identities to the certificate subject. A URI identity is encoded as a uniformResourceIdentifier; it must be an absolute URI with a scheme and scheme-specific part.

These fields are designed to compose. They are not synonyms.

A certificate may therefore support propositions such as:

Certificate or runtime element Bounded proposition
id-kp-imUri the certified key is intended for the IM-identity-credential purpose
subjectAltName carrying the expected im: URI the issuer bound that presented URI to the certificate subject under its issuance process
certification path signatures, validity, constraints and policy processing reached an accepted trust anchor
proof of private-key possession the presenter controlled the corresponding signing key at the tested moment
account challenge a named process connected the requester to the service account
application admission this client was permitted to act in this group, tenant or role
message receipt a later system observed a bounded delivery or application result

The first row cannot manufacture the second. The second cannot manufacture the fifth. The fifth cannot manufacture the sixth.

RFC 3860 defines an im: URI as the identifier of an INSTANT INBOX. It says certificates used for S/MIME instant-messaging operations should carry the subject’s IM URI in subjectAltName for reference integrity. It also says its abstract service assumes reliable delivery and provides no application-layer delivery assurance of its own. Identity notation and service outcome are already separate in the older architecture.

RFC 9734 also names an XMPP URI as a possible subjectAltName form. RFC 6121 shows why the surrounding application matters: a Jabber Identifier names an account or resource in XMPP procedures, while roster changes and stanza processing have their own authorization rules. A syntactically recognizable identifier does not carry every permission associated with it.

The OID narrows a corridor; it does not choose the destination

The registered value is 1.3.6.1.5.5.7.3.40. The IANA SMI registry records decimal 40 as id-kp-imUri. That public assignment prevents two specifications from accidentally using the same number for different purposes. It is coordination evidence, not evidence that a named issuer has validated a named account.

RFC 9734 says the issuer may make the EKU critical or non-critical. Under RFC 5280, a critical EKU restricts the certificate to one of the indicated purposes, and applications may require a particular purpose to be present. The useful control is negative: a relying application can reject a certificate whose key was not issued for this job.

The RFC therefore advises issuers not to place id-kp-clientAuth or id-kp-serverAuth beside id-kp-imUri. A broad TLS purpose beside the narrow messaging purpose defeats the specificity the new OID was created to provide. A certificate inventory should not merely count adoption. It should report mixed-purpose issuance, anyExtendedKeyUsage, criticality, application enforcement and reuse of the same key in unrelated protocols.

That is the running-code test. An OID in a certificate does not narrow anything if the validator ignores it. A narrow profile does not prevent cross-protocol acceptance if another application trusts the same chain and broad EKU. A standards-compliant field can remain operationally decorative.

A valid path still needs an expected name

Certificate-path validation and application identity matching are frequently compressed into one green icon. They are different algorithms with different inputs.

Path validation processes issuer signatures, validity periods, trust anchors, Basic Constraints, Name Constraints, certificate policies, Key Usage and EKU. It can establish that a certificate is acceptable under a PKI path and a supplied validation policy. It cannot invent the IM identity the application intended to reach.

RFC 9525, written for service identities, gives useful vocabulary: a certificate offers presented identifiers; the client constructs a reference identifier from what it intended to contact. The two must be compared under the relevant rules. That same separation appears directly in MLS.

Suppose the certificate presents two messaging URIs. The group invitation expected one. The chain validator can accept both as issuer-bound names. The application must still decide whether the intended URI is among them, whether aliases are allowed, whether tenant boundaries matter and what happens when an account has been renamed. “The certificate has an IM URI” is not a comparison result.

The evidence record should retain at least the expected identifier, presented identifiers, normalization rule, issuer and trust anchor, policy inputs, validation time, result and reason. Without the expected side of the comparison, an audit has a credential but no question it was asked to answer.

MLS adds a key binding, not a universal identity verdict

RFC 9420 makes the composition explicit. Each group member presents a credential that provides one or more identities and associates them with the member’s signing key. In an X509Credential, the public key in the end-entity certificate must be identical to the signature_key in the LeafNode.

That is a strong and precise binding. It prevents the protocol object from presenting one certificate while signing as an unrelated key. It does not decide which identifiers the application accepts.

RFC 9420 assigns that work to the application and its Authentication Service. The application supplies reference identifiers for the member. The credential supplies presented identifiers. The Authentication Service validates that the credential legitimately represents those presented identifiers and that they authenticate the expected reference identifiers. New and replacement credentials must be validated at defined admission and update events.

This chain contains at least four distinct receipts:

  1. the certificate key matches the MLS LeafNode signing key;
  2. the certificate path and extensions are acceptable;
  3. a presented IM or XMPP identifier matches the expected identifier;
  4. application policy admits this client into this group and epoch.

The EKU contributes to the second receipt. It cannot silently supply the other three.

The device problem makes the gap concrete. Several clients belonging to one user may present the same application-level account identifier. RFC 9420 warns that credentials need not uniquely identify clients, and a leaf index is meaningful only inside a particular group epoch. If policy distinguishes a corporate laptop, a personal phone and an automation bot, the account URI cannot carry that distinction alone. Device enrollment, client identity and group state need separate coordinates.

Time changes the answer after issuance

A certificate can be correct at issuance and wrong for today’s decision. The account may be suspended. A device may be lost. Employment or contractor status may end. A tenant may move. An administrator may remove the client from a group. The private key may remain technically usable through all of those changes.

RFC 9420 discusses expiry and revocation as operational conditions. Members may update credentials, and applications may remove members whose credentials are revoked. It also recognizes history: a signature on an old message may have been valid when sent even if the credential has since expired. “Valid now” and “valid at event time” require different evidence.

RFC 6960 makes status limits visible. OCSP returns good, revoked or unknown. “Good” minimally says that no certificate with the requested serial number currently within its validity interval is revoked. It does not necessarily prove that the certificate was issued or that the response time falls inside the certificate’s validity period. thisUpdate, nextUpdate and producedAt locate the assertion in time.

A status light without responder authority, freshness policy and failure behavior is not a status decision. “Unknown” is not “good”. A cached “good” response is not timeless. A certificate with the right EKU and URI can still fail a current-use decision because the available status evidence is stale or because local account state has changed faster than PKI revocation.

The February 2025 identity architecture cited by RFC 9734, draft-barnes-mimi-identity-arch-02, treats revocation as a separate information flow because the credential cannot rewrite itself after issuance. It surveys short-lived credentials, OCSP and CRL approaches and warns that communications providers may themselves be untrusted actors in distribution. The draft is work in progress, not a production claim, but the architectural boundary is useful: current status must arrive from somewhere beyond the static certificate.

The useful dossier is a chain, not a badge

For issuance, retain the requester, key fingerprint, proof-of-possession result, requested URI, account-proof method, authority, policy version, decision time, certificate serial, subjectAltName values, EKUs and validity interval. Do not convert “challenge succeeded” into a permanent declaration of account control.

For validation, retain the trust anchor, chain, policies, expected identifier, presented identifiers, match rule, EKU evaluation, Key Usage, validation time, revocation source, freshness window and fail-open or fail-closed result.

For MLS, retain the LeafNode key, credential fingerprint, Authentication Service decision, reference identifier, group ID, epoch, member or device coordinate, proposal or commit, admission rule and successor-credential decision.

For outcome, retain only what a later layer observed: accepted proposal, authenticated message, delivery-service handoff, device acknowledgement or human response. None should be inferred from certificate validity alone.

The canonical text, XML, RFC Editor record, errata index and IETF history establish the public document and its provenance. They do not establish implementation, deployment or adoption.

Heng Lu’s Running-Code Primacy asks which checks the issuer and relying client actually execute. The minimum-initial-specification principle supports a narrow shared OID while leaving account proof and local admission decisions visible. The reality-layer discipline prevents an assigned number, an encoded extension, a matched URI and an authorized human action from being compressed into one institutional fact.

RFC 9734 improves the certificate vocabulary by making one claim smaller. A trustworthy implementation should preserve that achievement rather than inflate the new field into a universal identity badge.

Sources