Page tree
Skip to end of metadata
Go to start of metadata
Target releaseRelease 1.0
Document owner
Reviewer

Goals

Revoke a Policy Generator certificate from the SCMS System.

Background and Strategic Fit

The Technical Component of the SCMS Manager (TCotSCMSM) determines that a Policy Generator (PG) needs to be revoked. The TCotSCMSM access the CRL generator for CRL series 256 (either the root CA or a central CRLG) and causes the PG to be added to the composite CRL, which is made available to all SCMS components and EEs. On receipt of the new CRL, all SCMS components and EEs shall mark the affected Policy Generator as untrusted. Components and EEs must request a new policy file signed by a new PG as soon as it is available.

Procedure

  1. The TCotSCMSM contacts the series 256 CRL generator (see the CRL Series Diagram for details) and instructs it to add the current PG certificate to the CRL. The CRLG assembles and signs an updated CRL, which is made available to all components and EEs through the CRL store or via collaborative distribution.
  2. The TCotSCMSM shall configure a new PG and issue a new GPF as described in the Add PG use case. The GPF will be made available to all RAs and back-end components. On receipt of the new GPF, each RA will assemble an updated LPF and submit the custom portion of the local policy to be signed by the new PG.
  3. Upon receipt of the updated CRL, all SCMS components and EEs shall cease to trust the current policy or any new policy files signed by the revoked PG. They shall all resort to a set of pre-configured "default" policy values and attempt to download an updated policy file signed by a new PG as soon as it is available.
  4. EEs shall contact their RA to download a new policy file signed by a replacement PG. They shall switch to a pre-defined set of "default" policy values until the new file is available.
  5. SCMS components shall attempt to download a new policy file signed by a replacement PG. They will use a pre-defined set of "default" policy values until the new file is available. 

Assumptions

  • Backend components and EEs will be pre-programmed with a set of "default" policy values that can maintain some level of system operation while the new PG is established and new policy files are distributed.
  • Each RA will need to receive the new GPF when it is available, assemble their own custom section of their LPF and submit it to the PG to be signed. Local ICA Managers will implement a manual process to push the new GPF out to their RAs. The TCotSCMSM may implement network management practices to limit traffic to the replacement PG.
  • There may be a time delay before a new policy file is available from an RA for EEs to download. OEMs shall define an implementation specific mechanism to manage EE messaging to the RA. OEMs that have alternate mechanisms to push content out to their EEs may use these mechanisms to distribute a new signed policy file as soon as it is available.

Requirements

Key Status Summary Description justification notes Component/s
Loading...
Refresh

Use Case 11.2.1 Revoke PG - Requirements