BRSKI with Alternative Enrollment (BRSKI-AE)
Extracted elements (29)
BRSKI-AE is motivated by scenarios where EST is infeasible: when the RA is not co-located with the registrar and requires end-to-end authentication; when the CA mandates auditable proof of origin for CSRs; when KEM keys are used (which cannot sign a PKCS#10 CSR); when the pledge's TLS library lacks 'tls-unique' support; or when connectivity to backend PKI is intermittent.
BRSKI-AE requires the registrar to use the same enrollment protocol for communicating with the backend PKI as is used between pledge and registrar, because end-to-end authentication requires the pledge's signed certification request to be forwarded intact. Using a different protocol toward the backend would break the pledge-to-RA authentication chain.
CMP is chosen as the primary instantiation of BRSKI-AE over CMC and SCEP because CMP has broader industry adoption than CMC, and SCEP has unspecified issues. The Lightweight CMP Profile (LCMPP) provides a well-specified and sufficient subset for BRSKI-AE requirements.
EST is not used in BRSKI-AE because the binding of the pledge's TLS identity to the CSR (via 'tls-unique') is only valid within the registrar's TLS session and cannot be verified by backend RAs over multiple transport hops. SCEP, CMP, and CMC support authenticated self-contained objects and do not rely on transport-level security for origin authentication.
The service name 'brski-reg-cmp' uses the suffix 'cmp' rather than 'lcmpp' because BRSKI-CMP implies adherence to the LCMPP—compliance with the profile is necessary and sufficient—so 'cmp' is less verbose while still conveying the constraint.
BRSKI-AE with CMP can be combined with Constrained BRSKI (cBRSKI), using CoAP for enrollment message transport as described by CoAP Transfer for CMP [RFC9482]. In such scenarios, the EST-specific parts of cBRSKI do not apply.
New enrollment protocol URI components require both an RFC specifying the protocol and a registration in the 'Well-Known URIs' registry, exactly as EST was registered in RFC 7030. URI values for CMC, SCEP, and other protocols are outside the scope of RFC 9733.
The standard BRSKI discovery mechanism does not allow pledges to discover which enrollment protocols a registrar supports. A minimalist CMP-specific fallback is to use the DNS service name 'brski-reg-cmp' instead of 'brski-registrar'; this approach does not support join proxies.
A pledge SHOULD use the endpoints defined for the enrollment protocol(s) it can use. Using non-standardized endpoints risks rejection even if the registrar supports the intended protocol.
Adherence to the Lightweight CMP Profile (LCMPP) [RFC9483] is REQUIRED when using CMP in BRSKI-AE. The CMP client within the pledge MUST validate server responses based on the trust anchor established via the BRSKI voucher (the pinned-domain-cert).
After finishing the Imprint step (4), the Enroll step (5) MUST be performed with an enrollment protocol utilizing authenticated self-contained objects as described in Section 3. EST alone does not satisfy this requirement.
If the registrar answers a request directly without forwarding, it MUST authenticate its responses with the same credentials used for authenticating itself at the TLS level during the voucher exchange.
It is REQUIRED to use the (D)TLS channel established between the pledge and registrar to transport certificate enrollment request and response messages. The pledge does not need additional connections and the registrar retains full control over enrollment traffic.
The authorization of a certification request MUST be performed based on an authenticated self-contained object cryptographically bound to the pledge's IDevID credentials. The certification request MAY then be transferred using any mechanism or protocol.
The CA Certs Response (2) MUST contain any intermediate CA certificates that the pledge may need to validate certificates and MAY contain the LDevID trust anchor.
The Certification Request (5) MUST contain the authenticated self-contained object ensuring both the proof of possession of the corresponding private key and the proof of identity of the requester.
The Certification Response (6) on success MUST contain the requested certificate and MAY include further information such as intermediate CA certificates and additional trust anchors.
The '<enrollment-protocol>' URI component MUST reference the protocol being used (existing values: 'est', 'cmp'). If present, the '<request>' path component MUST describe the operation requested depending on the enrollment protocol.
The registrar MUST support at least one certificate enrollment protocol with authenticated self-contained objects for certification requests. The URI scheme for addressing endpoints at the registrar is generalized to accommodate this requirement.
When the registrar forwards a certification request to a backend RA/CA, it is RECOMMENDED to wrap the original request in a nested message signed with the registrar's own credentials (per RFC9483, Section 5.2.2.1), explicitly conveying the registrar's consent while retaining the pledge's proof of origin.
CMP messages themselves are not encrypted, which may allow eavesdroppers to learn which devices are being bootstrapped into the domain and potentially enable selective blocking of device enrollment. The TLS channel between pledge and registrar mitigates this on-site, but encryption must be added for onward exchange with backend systems.
An 'authenticated self-contained object' is a data structure cryptographically bound to the identity of its originator by an attached digital signature using a private key such as the IDevID secret. It provides proof of possession and proof of identity independently of the transport mechanism.
BRSKI-AE defines a certificate enrollment message flow with eight steps: (1) CA Certs Request, (2) CA Certs Response, (3) Attribute Request, (4) Attribute Response, (5) Certification Request, (6) Certification Response, (7) Certificate Confirm, (8) PKI/Registrar Confirm. Only steps 5 and 6 are REQUIRED; all others are OPTIONAL.
BRSKI-AE introduces a generalized well-known URI scheme: '/.well-known/<enrollment-protocol>/<request>', replacing the EST-specific '/.well-known/est/<request>' from BRSKI. CMP endpoints include '/.well-known/cmp/initialization', '/.well-known/cmp/getcacerts', and '/.well-known/cmp/getcertreqtemplate'.
BRSKI-AE protocol phases are: Discover, Identify, Voucher exchange, Voucher status telemetry, Certificate enrollment (using authenticated self-contained objects), and Enrollment status telemetry. The voucher exchange and status telemetry phases are unchanged from RFC 8995.
BRSKI-AE supports a Local Registration Authority (LRA) co-located with the registrar that delegates part of its enrollment authority to a backend RA. The registrar optionally checks certification requests and forwards them to the backend RA, which performs final validation and authorization, relaying responses back on the same channel.
For BRSKI-CMP, proof of possession SHALL be provided in a manner suitable for the key type, and proof of identity SHALL be provided by signature-based protection of the certification request using the IDevID secret, as specified in RFC9483, Section 3.2.
IANA has registered the service name 'brski-reg-cmp' over TCP in the Service Name and Transport Protocol Port Number Registry, identifying a BRSKI registrar with CMP capabilities according to the Lightweight CMP Profile (LCMPP) [RFC9483].
Even when the registrar delegates RA functions to a backend system, it must still participate in the decision to accept or decline a pledge joining the domain. A pledge must not be able to circumvent the registrar to obtain an LDevID certificate. Acceptable mechanisms include implicit consent, out-of-band signaling, in-channel consent messages, or the registrar co-signing the enrollment request.