Summary

  • RFC 5410 assigns a MIKEY General Extension Type 5 to OMA BCAST service and content-protection messages.
  • The extension can carry STKM, LTKM, an LTKM reporting message and a parental-control message.
  • Seeing or parsing a payload is not proof of key receipt, entitlement, cryptographic-context installation or playback.

One payload carries several governance questions

MIKEY already negotiates and transports keying material. OMA BCAST adds service-protection messages with different lifetimes and audiences. RFC 5410 gives those messages a common General Extension container. That is useful interoperability plumbing, but it creates a tempting dashboard shortcut: “Type 5 received” becomes “the viewer is protected.”

The extension type is only the first receipt. An STKM can name short-term material; an LTKM can carry longer-lived material; reporting and parental-control payloads describe management state. The receiver still has to validate the message, resolve the service context, obtain any required credentials, install the right key scope and decide whether the content may be rendered. Those steps can fail independently.

Transport is not custody

MIKEY delivery may use unicast or broadcast transport. A network receipt can therefore tell an operator that bytes arrived at an interface without proving which terminal processed them. Preserve message type, version, service identifier, sequence or lifetime fields, authentication result, key-store write and the media context that consumed the key. A retransmitted LTKM should not be counted as a second entitlement, and an accepted parental-control message should not be treated as proof that a user interface enforced it.

RFC 5410 also obsoletes RFC 4909 and is updated by RFC 6309. The standards relationship matters for registry and version review; it is not evidence that every implementation supports every OMA BCAST behavior. Record the negotiated extension, implementation version and fallback path when a receiver declines Type 5.

Make the terminal state observable

Track parse success, authentication, credential availability, key installation, cryptographic-context activation, entitlement decision, parental-control decision and first successful protected-media result separately. Trigger investigation when a report claims LTKM success but no key-store transaction exists, when a short-term key is used after its lifetime, or when a fallback path delivers media without the expected context.

Leadership should ask vendors for a replayable chain from General Extension type to rendered service state. RFC 5410 standardises a carrier for OMA BCAST control messages; it never turns a carried key message into proof that the audience can securely consume the programme.