Summary

  • BRSKI-AE binds a certification request to both the new private key and the pledge’s manufacturing identity, so a backend can verify the request after forwarding or delay.
  • The signed object supports an authorization decision; it does not make one. RFC 9733 requires the domain registrar to remain in the decision even when an off-site RA performs most checks.
  • Voucher acceptance, certificate issuance, certificate confirmation, enrollment telemetry, installation and operational admission are separate records. A trustworthy onboarding report must preserve them.

At an isolated industrial site, certificate enrollment may spend longer in a queue than on a wire. A controller has its manufacturer credential. The local registrar can reach the plant but not the central public-key infrastructure. A request is assembled, carried out when capacity returns, checked at a remote registration authority and answered much later. The original TLS session is gone. What evidence survives?

RFC 9733 answers with an authenticated self-contained object. The certification request carries proof that the pledge controls the new private key and proof that the request originated from the pledge identified by its Initial Device Identifier, or IDevID. Those proofs can be verified beyond the first transport hop. They can survive intermittent connectivity and asynchronous delivery.

That is a substantial improvement in evidence portability. It is not a transfer of institutional power to a signed blob. The request cannot appoint its own domain, approve its own attributes, compel a certificate authority, certify that the answer fits, or admit the device to a production network. RFC 9733 is most useful when each of those acts remains visible.

One request, two different proofs

Certificate onboarding often compresses several meanings into the word “identity.” RFC 9733 keeps two of them apart.

Proof of possession shows access to the private key corresponding to the public key in the request. A PKCS #10 request commonly demonstrates that by signing itself with the new key. CRMF can support other methods, including methods for keys that cannot sign. This answers a narrow question: does the requester control the key for which it is asking a certificate?

It does not answer who the requester is. A newly generated key has no established identity simply because it can sign its own request. Proof of identity, which the RFC also calls proof of origin, binds the request to an existing credential. In BRSKI-AE, that is normally a signature made with the pledge’s manufacturer-installed IDevID secret and covering a strong pledge identifier.

The distinction matters when the two tests produce different answers. A request can correctly prove possession of an attacker-chosen key while failing to establish an authorised pledge origin. It can carry a valid IDevID signature while asking for an unacceptable subject, role or key use. It can satisfy both cryptographic checks while local policy rejects the device, its ownership state or the requested domain attributes.

The signed request therefore supplies facts to a decision. It does not contain the whole decision.

Why the evidence must survive the first hop

Classic BRSKI uses Enrollment over Secure Transport. EST can bind a PKCS #10 request to the authenticated TLS connection between a pledge and a registrar. That is useful at the immediate peer. It becomes awkward when a second registration authority, located off-site, must see and evaluate the original pledge evidence. A transient session at the registrar is not itself a portable object the backend can verify.

BRSKI-AE replaces that dependency with enrollment protocols whose messages authenticate themselves. The standards-track instantiation uses the Certificate Management Protocol under the Lightweight CMP Profile. CMP can protect the certification message with the IDevID while the embedded CRMF or PKCS #10 request proves possession of the proposed LDevID key. Forwarding no longer has to erase the original proof.

This enables an important architectural choice. The domain registrar can remain the local gatekeeper while a backend RA performs deeper validation and authorization. The request can cross a join proxy, registrar, store-and-forward system or offline transfer process without asking each transport channel to recreate the pledge’s identity claim.

Transport independence does not mean transport irrelevance. RFC 9733 still requires pledge-to-registrar enrollment messages to use the established TLS or DTLS channel. It leaves the exchange between registrar and backend PKI outside its scope. CMP message protection supplies integrity and authenticity, not confidentiality. An operator that carries those messages beyond the registrar must still protect device identifiers and deployment patterns from observation and selective blocking.

The voucher opens trust; it does not issue the LDevID

The BRSKI sequence begins before the alternative enrollment request. A pledge uses its IDevID to work through the registrar and the Manufacturer Authorized Signing Authority. The voucher exchange gives the pledge a trust anchor for the target domain, commonly represented by the pinned-domain certificate. That lets the pledge authenticate the entities from which it will accept domain material.

A voucher is powerful, but its claim is bounded. It is not the pledge’s Locally Significant Device Identifier certificate. It does not prove that the later certification request was accepted, that the requested attributes were authorised or that the device was admitted to a service.

After imprinting, the pledge generates the LDevID private key and sends the self-contained certification request. In the CMP profile, it validates the response using the trust anchor established through the voucher. This joins two evidence chains without merging them: the voucher tells the pledge which domain trust to rely on; the certification exchange asks that domain’s PKI to issue a particular certificate for a particular key.

Operators should retain both records. If a dashboard shows only “voucher accepted,” a later enrollment rejection can look like an unexplained system fault. If it shows only “certificate returned,” an investigator may lose the proof of which domain the pledge had been authorised to trust.

The registrar cannot be routed around

The most consequential sentence in RFC 9733 is not about a signature algorithm. Even if the registrar delegates part or all of its registration-authority work, it must still participate in deciding whether the pledge joins the domain. A pledge must not be able to bypass that gatekeeper and obtain an LDevID directly from the CA.

The design permits several forms of registrar consent. Consent can be implicit in a tightly governed arrangement, recorded out of band, carried as an extra message, or expressed cryptographically. For CMP, the RFC recommends wrapping the pledge’s original signed request in a nested message signed by the registrar. The backend can then see two distinct statements: the pledge originated this request, and the registrar consents to its consideration.

That nesting is better evidence than replacing one signature with another. It avoids forcing the backend to trust a paraphrase of what the pledge asked for. It also avoids pretending that pledge authenticity is the same as domain admission. The original object remains available for comparison, while the registrar adds its own accountable act.

The backend RA may still reject the request. It can apply certificate profile, ownership, naming, key, revocation, inventory and operational policy that the local registrar does not hold. The CA can issue only after the required authentication and authorization have been satisfied. A valid pledge signature is evidence the RA evaluates; it is not an instruction the CA must obey.

Asynchrony lengthens the decision, not the permission

RFC 9733 is built for places where the off-site PKI is intermittent or offline. Messages should move when sufficient transfer capacity becomes available. CMP’s protected objects allow that delay without making proof of origin depend on one still-live connection.

Time creates a new control surface. Ownership may change after the voucher was produced. Registrar consent may be withdrawn. A certificate profile or trust anchor may rotate. A queued request may be duplicated, replayed or delivered after its business context has expired. The RFC supplies the structure for authenticated enrollment, but it does not make all local freshness and reconciliation choices for the operator.

A production workflow therefore needs a durable transaction record. It should connect the voucher identity, request key fingerprint, IDevID proof, requested attributes, registrar consent, backend transaction identifier, RA decision, CA response and final certificate fingerprint. Retry logic must distinguish a lost response from a request that was never authorised. Queue age must be visible as policy-relevant state, not treated as transport trivia.

The value of a self-contained object is that a reviewer can recheck what was signed. The danger is assuming that an old valid signature proves a current mandate. Cryptographic validity and decision freshness are different predicates.

Three receipts after the certificate response

A successful certification response contains the requested certificate and may carry intermediate certificates or further trust anchors. Even then, the exchange is not finished in only one sense.

CMP can use an optional Certificate Confirm. The pledge sends it after receiving and validating the certificate, and can report a positive or negative result according to whether the certificate was successfully enrolled and fits its needs. The PKI or registrar acknowledges that confirmation. This gives the issuer evidence about the pledge’s evaluation; the acknowledgement only proves that the confirmation was received and handled at that layer.

BRSKI also retains mandatory enrollment-status telemetry between the pledge and registrar. RFC 9733 explicitly treats that as a separate final phase. CMP certificate confirmation and BRSKI status telemetry must not be flattened into one green event merely because both occur after a response.

There is then a third boundary outside the enrollment exchange. The device must install and use the credential, satisfy network access policy, receive configuration and perform its intended work. A correctly issued certificate can remain unused. A pledge can report enrollment success while an access controller rejects it. A network can admit it while the industrial process it was meant to support remains unavailable.

The responsible status line is longer: voucher accepted; request origin and possession verified; registrar consent recorded; RA authorised; CA issued; pledge confirmed; enrollment telemetry received; operational admission not yet tested. The extra words prevent automated onboarding from fabricating completion.

Discovery names a door, not its authority

RFC 9733 generalises enrollment endpoints as /.well-known/<enrollment-protocol>/<request>. It also registers the brski-reg-cmp service name for a minimalist CMP-capable registrar discovery method. A pledge can try the selected endpoint and interpret the HTTP status to learn whether that operation is supported.

That is protocol discovery, not domain authorization. An endpoint can exist without being the correct registrar for this pledge. A service name can be registered without any particular deployment being conformant. An HTTP success can acknowledge receipt while the inner certification operation waits or fails. The article on RFC 9811 owns that HTTP-versus-CMP status boundary; here it is one rung inside the wider BRSKI-AE authority chain.

Good onboarding logs preserve the resolved endpoint, TLS peer, pinned-domain trust, enrollment protocol, operation, inner transaction and policy owner. “CMP endpoint found” is useful evidence. It is not a certificate, consent or service result.

No source in this packet establishes that a named manufacturer, railway, substation, building system or charging network has deployed RFC 9733. The examples motivate the architecture; they are not deployment claims. The standard’s durable contribution is narrower and more valuable: it lets origin evidence travel without letting organisational authority disappear into the transport.

Sources