The following is provided as general guidance for EE-RA messaging. For specific messaging, refer to the RA - Services View.
EE initiates all communication between EE and RA. All communications between EE and RA fall into one of two categories: 1) (Non-)Authenticated Download Requests 2) SCMS Protocol Messages.
A simplified version is displayed in the diagram below. Note that the diagram does not include the digitally signed time-stamp of Step 2 and the verification of Step 5.
An X.509 root CA certificate that EEs install during bootstrapping issues RA’s X.509 certificate. EE will perform the following check before Step 2 in above EE-RA mutual authentication:
In order to revoke an RA, the operator will modify the DNS entry for the RA (e.g. ra.ra-hoster.com) to point to the new RA (or RA's load-balancer/firewall, depending on RA's architecture). Attacks might be still possible; an attacker can compromise the RA X.509 certificate, implement DNS spoofing, and compromise the LOP. However, the adversary's gain is limited to learning enrollment certificates. Therefore, the RA may or may not support a revocation mechanism for RA's TLS certificate (e.g. the certificate status request extension, colloquially known as OCSP stapling and specified in RFC 6066, Section 8). The EE (both OBE and RSE) may or may not support the TLS revocation mechanism.
Download requests are used by the EE to download a file from the RA.
The EE uses HTTP GET to make download requests. There are two different kind of download requests: authenticated and non-authenticated:
The HTTP GET Range option may be used to request a partial download for the purposes of resuming a previously interrupted download.
SCMS protocol messages are used by the EE to send SCMS protocol APDU messages to RA. The EE uses HTTP POST to send the SCMS protocol APDU to RA. The EE ASN.1 serializes the APDU and sends it as the HTTP POST Message Body in binary form.