Summary

  • RFC 5408 defines an identity-based encryption architecture in which an identity can be used to derive a public key from published parameters.
  • A trusted private-key generator (PKG) still holds a domain-wide secret and decides when a corresponding private key is released.
  • Decryption proves that the key service issued usable material; it does not prove that a person, tenant or application may perform the requested business action.

The shortcut changed distribution, not governance

Traditional public-key systems distribute a random public key. IBE lets a sender compute a key from an identity string and public mathematical parameters. That is operationally attractive for an address, account name or other stable identifier: a sender can encrypt before the recipient has enrolled a certificate. RFC 5408 then puts the missing secret behind the PKG, whose domain-wide secret can calculate the recipient's private key.

The design therefore creates three different observations. The sender can show which identity and parameter set produced the ciphertext. The PKG can show whether it released a private key. The application can still reject the decrypted request. Treating those observations as one green “authorised” state hides the control surface that matters most: who was allowed to obtain key material, under which identity format, at what time and for which domain.

Public derivation is not a permission check

The identity format is part of the security boundary. RFC 5408 describes structured identities, public-parameter lookup and the URI/IRI by which a recipient finds a PKG. A typo, alias, stale identifier or wrong parameter domain can produce a perfectly formed ciphertext for the wrong recipient. The mathematical derivation does not validate employment, tenancy, device posture or object policy.

For operations teams, retain the exact identity encoding, parameter fingerprint, lookup result and PKG decision. Do not infer that a message was intended for a person merely because a directory resolver returned a familiar display name. Normalisation rules, case handling and namespace ownership deserve the same review as certificate subject names.

The PKG is a concentrated control surface

The PKG's domain-wide secret can derive private keys for identities in its domain. That makes issuance, separation of duties, audit retention and compromise response more consequential than a routine certificate renewal. RFC 5408 describes the architecture; it does not claim that one PKG is appropriate for every organisational boundary or that revocation becomes automatic.

A recipient who decrypts a message has evidence about cryptographic availability, not a durable application outcome. A service may deny the operation after decryption, require a second factor, apply a tenant policy, or reject an expired role. Record key-release time, policy decision, decryption result, request identifier and business commit separately. A retry after a timeout must not be classified as safe or unsafe from the ciphertext alone.

Monitor the edges, not just the cipher

Track identity canonicalisation, parameter-set changes, PKG lookup and issuance, key lifetime, failed decryptions, policy denials and application commit identifiers. Trigger review on an identity resolving to multiple domains, a parameter rollover without a migration record, a private-key request outside expected geography, or a successful decryption with no authorisation decision.

Leadership should require vendors to export the whole chain from identity input to durable result. RFC 5408 gives a disciplined architecture for just-in-time private keys; it never turns a computable public key into a standing permission.