Design Guide for Intel® SGX and Intel® TDX Provisioning Certificate Caching Service (PCCS)

Introduction¶

This document describes software architecture for the Intel® SGX and Intel® TDX Provisioning Certificate Caching Service (PCCS) delivered as part of Intel® SGX and Intel® TDX Data Center Attestation Primitives (DCAP) in order to support third party attestation model in a data center environment.

Terminology¶

Term	Description
PCCS	Intel® SGX and Intel® TDX Provisioning Certificate Caching Service.
PCS	Intel® SGX and Intel® TDX Provisioning Certification Service.
Intel® SGX Quote	Data structure used to provide proof to an off-platform entity that the application's enclave is running with SGX protections on a trusted SGX-enabled platform.
Quoting Enclave (QE)	An enclave generally signed by Intel, which is used sign and issue Quotes/attestations about other enclaves.
Elliptic Curve Digital Signature Algorithm (ECDSA)	Signing cryptographic algorithm as described in FIPS 186-4.
Provisioning Certification Enclave (PCE)	An architectural enclave that has to be signed by Intel, because only Intel-signed enclaves can access the Provisioning Certification Key (PCK). This enclave uses the PCK to sign QE Report structures for Provisioning or Quoting Enclaves. These signed REPORTS contain ReportData that indicates that attestation keys or provisioning protocol messages were created on genuine hardware.
Provisioning Certification Key (PCK)	Signing key available to the Provisioning Certification Enclave for signing certificate-like QE Report structures. The key is unique to the processor package or the platform instance, the HW TCB, and the PCE version (PSVN).
Provisioning Certification Key Certificate (PCK Certificate)	The x.509 Certificate chain signed and distributed by Intel for every SGX-enabled platform. Quote verifiers use this cert to verify that the QE-generated quotes are valid and running on a trusted SGX platform at a particular PSVN. It matches the private key generated by the PCE.
Platform Provisioning ID (PPID)	Provisioning ID for the processor package or the platform instance. PPID is not TCB-dependent.
Security Version Number (SVN)	Version number that indicates when the relevant security updates have occurred. New versions can have increased functional versions without incrementing the SVN.
Intel® SGX Provisioning TCB	Trusted Computing Base of Intel® SGX provisioning that includes the platform HW TCB and the PCE SVN.
PCEID	Identifies the version of the PCE used to generate the PPID and the PCK signing key. The length of PCEID is 2 bytes.
QEID	The unique ID of an SGX platform which is generated by ID Enlave. The size of QEID is 16 bytes.
CPUSVN	CPU security version number. The size of CPUSVN is 16 bytes.
PCESVN	The security version number of PCE enclave. The size of PCESVN is 2 bytes.
Encrypted_PPID	PPID encrypted with PPIDEK. The size of Encrypted_PPID is 384 bytes.
FMSPC	Description of the processor package or platform instance including its. Family, Model, Stepping, Platform Type, and Customized SKU. The size of FMSPC is 6 bytes.

Table 1. Terminology

Overview¶

Intel provides a reference Quote Provider Library (QPL) and a reference Intel® SGX and Intel® TDX Provisioning Certificate Caching Service (PCCS) to enable SGX-based attestation of Intel SGX enclaves and Intel TDX TDs without a dependence on the Intel® services. Intel® SGX and Intel® TDX Data Center Attestation Primitives (DCAP) also provides the network interface layer called PCK Certificate Collateral Network Library (QCNL). The libraries and the PCCS interaction with the Intel® SGX and Intel® TDX Provisioning Certification Service (PCS) can be configured in a number of ways to fit the customer's attestation infrastructure.

This document covers the high-level design details for the PCCS.

Architecture Overview – ECDSA-Based Data Center Attestation¶

The proposed architecture centers around a caching service that maintains the Intel® SGX attestation collateral for all servers at a CSP or in any other data center. The services provides that collateral to servers for quote generation and quote verification. This document describes the PCCS RESTful APIs and the tools needed to get the attestation collateral into the PCCS for Intel® SGX-enabled server platforms. It also describes the RESTful APIs exposed to platforms to retrieve that collateral during runtime.

placeholder — Figure 1. Intel® SGX and Intel® TDX DCAP Architecture Diagram

Intel® SGX ECDSA Public Key and Data Structure Hierarchy¶

The figure below shows the relationship between the SGX Attestation collateral (keys and data structures) used for Intel® SGX ECDSA Quote Generation and Quote Verification. This collateral is generated and signed by Intel and stored in the PCS.

placeholder

Figure 2. Intel® SGX ECDSA Public Key and Data Structure Hierarchy

API Specification for PCCS¶

Get PCK Certificate¶

Retrieve the X.509 SGX Provisioning Certification Key (PCK) certificate for an SGX-enabled platform at a specified TCB level.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/pckcert
GET https://pccs-server-url:8081/sgx/certification/v4/pckcert

Request¶

Name	Type	Request Type	Required	Pattern	Description
`encrypted_ppid`	String	Query	False	`^[0-9a-fA-F]{512}$`	Base16-encoded Encrypted_PPID
`cpusvn`	String	Query	True	`^[0-9a-fA-F]{32}$`	Base16-encoded CPUSVN value
`pcesvn`	String	Query	True	`^[0-9a-fA-F]{4}$`	Base16-encoded PCESVN value
`pceid`	String	Query	True	`^[0-9a-fA-F]{4}$`	Base16-encoded PCEID value
`qeid`	String	Query	True	`^[0-9a-fA-F]{32}$`	Base16-encoded QEID value

Table 1.

Response¶

PckCert (x-pem-file) - PEM-encoded representation of Intel® SGX PCK Certificate in case of success (200 HTTP status code)

Status codes¶

Code	Model	Headers	Description
200	`PckCert`	`SGX-PCK-Certificate-Issuer-Chain` (String): URL-encoded Issuer Certificate chain for SGX PCK Certificate in PEM format. It consists of SGX Intermediate CA Certificate (Processor CA) followed by SGX Root CA Certificate `SGX-TCBm` (String): Hex-encoded string representation of concatenation of CPUSVN (16 bytes) and PCESVN (2 bytes) as returned in corresponding SGX PCK Certificate	Successfully completed
400	-	-	Invalid request parameters
404	-	-	No cache data for this platform
461	-	-	The platform was not found in the cache.
462	-	-	Certificates are not available for certain TCBs.
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS.

Table 2.

Process¶

Checks request parameters upon client request and returns the 400 error if any parameter is invalid.
Gets the platform object from platforms table with the input {qeid, pceid} as key (see platformsDao.getPlatform).
If the platform was found, which means the platform was already cached:
1. Queries PCK Certificate for this platform and PCK Certificate issuer chain from cache db with the input {qeid, cpusvn, pcesvn, pceid} as key (see pckcertDao.getCert).
2. Goes to step 4.
If collateral was not retrieved in step 3:
1. If platform is not cached
  1. If cache fill mode is LAZY:
    1. Gets all PCK Certificates for this platform from PCS v4 API with {encrypted_ppid, pceid} for single-package platform, or {platform_manifest, pceid} for multi-package platform.
    2. Parses the first cert (X.509) in the array to get FMSPC and ca type (processor or platform).
    3. Contacts PCS again to get SGX TCB Info as well as TDX TCB Info (if available) with the above FMSPC value.
    4. Gets the best cert with PCKCertSelectionTool using {cpusvn, pcesvn, pceid, SGX TCB Info, PCK Certificates}.
    5. Updates the cache tables:
      - platforms table: calls platformsDao.upsertPlatform to update the platforms table;
      - pck_cert table: first calls pckcertDao.deleteCerts to delete old records associated with the {qeid, pceid}, then for each certificate fetched in i., calls pckcertDao.upsertPckCert to insert the certificate;
      - platform_tcbs table: for the new raw TCB in the request and all old cached raw TCBs, inserts/updates the new TCB mapping by calling platformTcbsDao.upsertPlatformTcbs;
      - fmspc_tcbs table: calls fmspcTcbDao.upsertFmspcTcb to update fmspc_tcbs table for both SGX TCB Info and TDX TCB Info (if available);
      - pck_certchain table: calls pckCertchainDao.upsertPckCertchain to update pck_certchain table with the ca type in step ii.;
      - pcs_certificates table: calls pcsCertificatesDao.upsertPckCertificateIssuerChain to update PCK Certificate issuer chain with the ca type in step ii.
    6. Returns the PCK Certificate in the response body and PCK Certificate issuer chain in the response header.
    7. Responds with the 200 status code.
    8. Else return 461 (not found) error
  2. Else
    1. Gets PCK Certificates from cache DB with {qeid, pceid} (see pckcertDao.getCerts).
    2. Gets TCB Info from cache DB with the FMSPC of the platform (see fmspcTcbDao.getTcbInfo).
    3. Runs PCK Certificate selection tool with the raw TCB, PCK Certificates, and SGX TCB Info.
    4. Gets PCK Certificate issuer chain from cache DB (see pckCertchainDao.getPckCertChain).
    5. If success, returns the "best" certificate and certificate chain, else returns the 404 error.
    6. Updates platform_tcbs table for this raw TCB (see platformTcbsDao.upsertPlatformTcbs).
2. Else
  1. Returns the PCK Certificate in the response body and PCK Certificate issuer chain in the response header.

Get PCK Certificate CRL¶

Retrieve the X.509 Certificate Revocation List with the revoked Intel® SGX PCK Certificates. The CRL is issued either by Intel® SGX Platform CA or by Intel® SGX Processor CA.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/pckcrl
GET https://pccs-server-url:8081/sgx/certification/v4/pckcrl

Request¶

Name	Type	Request Type	Required	Pattern	Description
`ca`	String	Query	True	Enum: `processor`, `platform`	Identifier of the CA that issued the requested CRL
`encoding`	String	Query	True	Enum: `der`	Optional identifier of the encoding for the requested CRL. If the parameter is not provided, HEX-encoded DER is assumed. If `der` is provided, raw DER format CRL will be returned.

Table 3.

Response¶

PckCrl (PKIX-CRL) – DER or HEX-encoded DER representation of SGX Platform CA CRL or SGX Processor CA CRL in case of success.

Status codes¶

Code	Model	Headers	Description
200	`PckCrl`	`SGX-PCK-CRL-Issuer-Chain`: Issuer Certificate chain for SGX PCK CRL. It consists of SGX Intermediate CA Certificate (Processor CA) followed by SGX Root CA Certificate	Successfully completed
400	-	-	Invalid request parameters
404	-	-	PCK CRL cannot be found
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS.

Table 4.

Process¶

Checks request parameters and returns the 400 error if any input parameter is invalid
Queries PCK CRL along with CRL issuer chain with the key {ca} (see pckcrlDao.GetPckCrl).
1. If record exists:
  1. Returns pck_crl in the response body and the PCK CRL certificate chain in the response header.
  2. Responds with the 200 status code.
2. Else:
  1. If cache fill mode is not LAZY, returns the 404 (No cache data) error to client.
  2. If cache fill mode is LAZY
    1. Gets PCK CRL and PCK CRL certificate chain from PCS v4 API with {ca}. If failed, returns the 404 error.
    2. Updates pck_crl and pcs_certificates table:
      1. Calls pckcrlDao.upsertPckCrl(ca, crl), crl is a response body.
      2. Calls pcsCertificatesDao.upsertPckCrlCertchain with {ca} and retrieved PCK CRL certificate chain.
    3. Returns PCK CRL in the response body and PCK CRL certificate chain in the response header.
    4. Responds with the 200 status code.

Get TCB Info¶

Retrieve Intel® SGX or TDX TCB Information for the given FMSPC

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/tcb
GET https://pccs-server-url:8081/sgx/certification/v4/tcb
GET https://pccs-server-url:8081/tdx/certification/v4/tcb

Request¶

Name	Type	Request Type	Required	Pattern	Description
`fmspc`	String	Query	True	`^[0-9a-fA-F]{12}`	Base16-encoded FMSPC value
`update`	String	Query	False	Enum: `early`, `standard`	Type of update to TCB Info. If not provided `standard` is assumed. `early` indicates an early access to updated TCB Info provided as part of a TCB recovery event (commonly the day of public disclosure of the items in scope) `standard` indicates standard access to updated TCB Info provided as part of a TCB recovery event (commonly approximately 6 weeks after public disclosure of the items in scope)

Table 5.

Response¶

TcbInfo (JSON) - Intel® SGX TCB Info encoded as JSON string in case of success

Status codes¶

Code	Model	Headers	Description
200	`TcbInfo`	`SGX-TCB-Info-Issuer-Chain` (v3) or `TCB-Info-Issuer-Chain` (v4): Issuer Certificate chain for Intel® SGX TCB Info. It consists of Intel® TCB Signing Certificate followed by Root CA Certificate	Successfully completed
400	-	-	Invalid request parameters
404	-	-	TCB Information for provided `{fmspc}` cannot be found
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS

Table 6.

Process¶

Checks request parameters and returns the 400 error if any parameter is invalid.
Queries TCB Info along with Intel® TCB Info issuer chain with key {type, fmspc, version, update_type} (see fmspcTcbDao. getTcbInfo). Type can be 0:SGX or 1:TDX.
1. If record exists:
  1. Returns tcb_info in the response body and the issuer chain in the response header.
  2. Responds with the 200 status code.
2. Else:
  1. If cache fill mode is not LAZY, returns the 404 (No cache data) error to client.
  2. If cache fill mode is LAZY
    1. Gets TCB Info from PCS with {type, fmspc, version}. If failed, return the 404 error.
      
      If type is 0:SGX, send request to /sgx/ url, else if type is 1:TDX, send request to /tdx/ url. Version will be translated to either /v3/ or /v4/. 2. Updates fmspc_tcbs and pcs_certificates: - fmspc_tcbs table: calls fmspcTcbDao.upsertFmspcTcb; - pcs_certificates table: calls pcsCertificatesDao.upsertTcbInfoIssuerChain. 3. Returns TCB Info in the response body and TCB Info certificate chain in the response header. 4. Responds with the 200 status code.

Get Intel's QE Identity¶

Retrieve the Quote Identity information for the Quoting Enclave issued by Intel.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/qe/identity
GET https://pccs-server-url:8081/sgx/certification/v4/qe/identity

Request¶

Name	Type	Request Type	Required	Pattern	Description
`update`	String	Query	False	Enum: `early`, `standard`	Type of update to QE Identity. If not provided `standard` is assumed. `early` indicates an early access to updated QE Identity provided as part of a TCB recovery event (commonly the day of public disclosure of the items in scope) `standard` indicates standard access to updated QE Identity provided as part of a TCB recovery event (commonly approximately 6 weeks after public disclosure of the items in scope)

Table 7.

Response¶

QEIdentity (JSON) - QE Identity data structure encoded as JSON string in case of success

Status codes¶

Code	Model	Headers	Description
200	`QEIdentity`	`SGX-Enclave-Identity-Issuer-Chain`: Issuer Certificate chain for Intel® SGX QE Identity. It consists of Intel® SGX TCB Signing Certificate followed by Intel® SGX Root CA Certificate	Successfully completed
404	-	-	QE identity information cannot be found
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS

Table 8.

Process¶

Queries QE identity along with SGX Enclave identity issuer chain (see identityDao. getIdentity).
1. If record exists:
  1. Returns qe_identity in the response body and the QE certificate chain in the response header.
  2. Returns the 200 status code.
2. Else:
  1. If cache fill mode is not LAZY, returns the 404 (No cache data) error to client.
  2. If cache fill mode is LAZY:
    1. Gets QE identity from the corresponding API version of PCS. If failed, returns the 404 error.
    2. Updates identities and pcs_certificates table:
      - identities table: calls identityDao.upsertIdentity.
      - pcs_certificates table: calls pcsCertificatesDao.upsertIdentityIssuerChain.
    3. Returns qe_identity in the response body and the QE certificate chain in the response header.
    4. Returns the 200 status code.

Get Intel's QvE Identity¶

Retrieve Identity information for Quote Verification Enclave issued by Intel.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/qve/identity
GET https://pccs-server-url:8081/sgx/certification/v4/qve/identity

Request¶

Name	Type	Request Type	Required	Pattern	Description
`update`	String	Query	False	Enum: `early`, `standard`	Type of update to QVE Identity. If not provided `standard` is assumed. `early` indicates an early access to updated QVE Identity provided as part of a TCB recovery event (commonly the day of public disclosure of the items in scope) `standard` indicates standard access to updated QVE Identity provided as part of a TCB recovery event (commonly approximately 6 weeks after public disclosure of the items in scope)

Table 9.

Response¶

QvEIdentity (JSON) - QvE Identity data structure encoded as JSON string in case of success

Status codes¶

Code	Model	Headers	Description
200	`QvEIdentity`	`SGX-Enclave-Identity-Issuer-Chain`: Issuer Certificate chain for Intel® SGX QvE Identity. It consists of Intel® SGX TCB Signing Certificate followed by Intel® SGX Root CA Certificate	Successfully completed
404	-	-	QvE identity information cannot be found
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS

Table 10.

Process¶

Queries QvE identity along with Intel® SGX Enclave identity issuer chain (see identityDao.getEnclaveIdentity).
1. If record exists:
  1. Returns qve_identity in the response body and QVE certificate chain in the response header.
  2. Returns the 200 status code.
2. Else:
  1. If cache fill mode is not LAZY, returns the 404 (No cache data) error to client.
  2. If cache fill mode is LAZY:
    1. Gets QvE identity from the corresponding API version of PCS . If failed, returns the 404 error.
    2. Updates identities and pcs_certificates table:
      - identities table: calls identityDao.upsertIdentity;
      - pcs_certificates table: calls pcsCertificatesDao.upsertIdentityIssuerChain.
    3. Returns qve_identity in the response body and QVE certificate chain in the response header.
    4. Returns the 200 status code.

Get Intel's TD QE Identity¶

Retrieve Identity information for TD Quote Enclave issued by Intel.

Endpoint(s)¶

GET https://pccs-server-url:8081/tdx/certification/v4/qe/identity

Request¶

Name	Type	Request Type	Required	Pattern	Description
`update`	String	Query	False	Enum: `early`, `standard`	Type of update to QE Identity. If not provided `standard` is assumed. `early` indicates an early access to updated QE Identity provided as part of a TCB recovery event (commonly the day of public disclosure of the items in scope) `standard` indicates standard access to updated QE Identity provided as part of a TCB recovery event (commonly approximately 6 weeks after public disclosure of the items in scope)

Table 11.

Response¶

TDQEIdentity (JSON) - TDQE Identity data structure encoded as JSON string in case of success

Status codes¶

Code	Model	Headers	Description
200	`TDQEIdentity`	`SGX-Enclave-Identity-Issuer-Chain`: Issuer Certificate chain for Intel® SGX TDQE Identity. It consists of Intel® SGX TCB Signing Certificate followed by Intel® SGX Root CA Certificate	Successfully completed
404	-	-	TDQE identity information cannot be found
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS

Table 12.

Process¶

Queries TDQE identity along with Intel® SGX Enclave identity issuer chain (see identityDao.getIdentity).
1. If record exists:
  1. Returns tdqe_identity in the response body and TDQE certificate chain in the response header.
  2. Returns the 200 status code.
2. Else:
  1. If cache fill mode is not LAZY, returns the 404 (No cache data) error to client.
  2. If cache fill mode is LAZY:
    1. Gets TDQE identity from PCS v4 API. If failed, returns the 404 error.
    2. Updates identities and pcs_certificates table:
      - identities table: calls identityDao.upsertEnclaveIdentity;
      - pcs_certificates table: calls pcsCertificatesDao.upsertIdentityIssuerChain.
    3. Returns tdqe_identity in the response body and TDQE certificate chain in the response header.
    4. Returns the 200 status code.

Get Root CA CRL¶

Retrieve Root CA CRL.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/rootcacrl
GET https://pccs-server-url:8081/sgx/certification/v4/rootcacrl

Request¶

No parameters

Response¶

RootCACRL – The HEX-encoded DER representation of Root CA CRL in case of success

Status codes¶

Code	Model	Headers	Description
200	`RootCACRL`	-	Successfully completed
404	-	-	Root CA CRL cannot be found
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS

Table 13.

Process¶

Queries root CA record(id=1) from pcs_certificates table (see pcsCertificatesDao.getCertificateById)
1. If the root CA record exists and the CRL field is not empty:
  1. Returns the CRL in the response body.
  2. Returns the 200 status code.
2. Else:
  1. If cache fill mode is not LAZY, return the 404 error to client
  2. If cache fill mode is LAZY:
    1. Calls PCS v4 API to get QE identity and extracts the root CA from the certificate chain in response header. If failed, returns empty body.
    2. Parses the root CA to get cdp uri
    3. Contacts the cdp uri to get root CA CRL. If failed, returns the 500 error.
    4. Updates pcs_certificates table with root CA and CRL(see pcsCertificatesDao.upsertPcsCertificates)
    5. Returns the root CA CRL in the response body (hex-encoded)
    6. Returns the 200 status code.

Post Platforms IDs¶

This API stores platform identity information provided in the request. This API is restricted to users with the access to the user-token.

Endpoint(s)¶

POST https://pccs-server-url:8081/sgx/certification/v3/platforms
POST https://pccs-server-url:8081/sgx/certification/v4/platforms

Request¶

Parameters¶

Name	Type	Request Type	Required	Pattern	Description
`user-token`	String	Header	True	String	PCCS user token which provides access to this API.

Table 14.

Body¶

{
    "qe_id": "Base16-encoded QE-ID value",
    "pce_id": "Base16-encoded PCE-ID value",
    "cpu_svn": "Base16-encoded CPUSVN value",
    "pce_svn": "Base16-encoded PCESVN value",
    "enc_ppid": "Base16-encoded PPID encrypted with PPIDEK",
    "platform_manifest": "Base16-encoded platform manifest value"
}

Response¶

Status codes¶

Code	Model	Headers	Description
200	-	-	Successfully completed (entry updated)
201	-	-	Successfully completed (entry created)
400	-	-	Invalid request parameters
401	-	-	Authentication failed
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS

Table 15.

Process¶

Validates the user token(calculate sha-512 hash of the token and compare the hash value with UserTokenHash in the configuration file). If validation fails, returns the 401 error.
Validates the request body with pre-defined JSON schema. If the validation fails, returns the 400 error to client.
Checks cache status for this platform.
1. Gets the platform object from platforms table based on the provided {qeid, pceid} (see platformsDao.getPlatform) .
2. If the platform_manifest in the request does not match the one in the cache (Note: Treat the absence of the platform_manifest in the request while there is a PLATFORM_MANIFEST in the cache as a match):
  1. Updates platforms table of the cache with the new manifest.
  2. Sets cache status to FALSE.
3. Else if platform_manifest matches:
  1. Queries PCK Certificate from cache db with {qeid, cpusvn, pcesvn, pceid} to check whether PCK Certificate for this platform is cached (see pckcertDao.getCert).
  2. If found, sets cache status to TRUE.
  3. Else: sets cache status to FALSE.
If cache fill mode is OFFLINE:
1. If cache status is FALSE:
  1. Adds the platform registration data to platforms_registered table and returns SUCCESS (call platformsRegDao.registerPlatform with state=NEW).
Else:
1. If cache status is FALSE:
  1. If cache fill mode is REQ, adds the platform registration data to platforms_registered table (calls platformsRegDao.registerPlatform with state=NEW)
  2. Uses the same logic in section Get PCK Certificate to get PCK Certificate from PCS.
  3. If cache fill mode is REQ, deletes the platform registration data from platforms_registered table (calls platformsRegDao.registerPlatform with state=DELETED).
2. Checks quote verification collateral (PCK CRL, QE identity, QvE identity, Root CA CRL). If not cached, retrieves them from PCS and fills the cache

Get Platform IDs¶

Administrators use this API to retrieve the platform ID information for registered platforms or cached platforms. This API is restricted to users with the access to the admin-token.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/platforms
GET https://pccs-server-url:8081/sgx/certification/v4/platforms

Request¶

Name	Type	Request Type	Required	Pattern	Description
`admin-token`	String	Header	True	String	The administrator token required to perform the request.
`fmspc`	String	Query	False	[fmspc1,fmspc2, …]	FMSPC array.

Table 16.

Response¶

An array of data structures defined below encoded as JSON in case of success (200 HTTP status code). When the Queue Status is 0, information for all registered platforms is retrieved.

Response format:

[
    {
        "qe_id": "xxxx",
        "pce_id": "xxxx",
        "cpu_svn": "xxxx",
        "pce_svn": "xxxx",
        "enc_ppid": "xxxx",
        "platform_manifest": "xxxx"
    },
    {}
]

Empty body otherwise.

Status codes¶

Code	Model	Headers	Description
200	See "response format" above	-	Successfully completed
400	-	-	Invalid request parameters
401	-	-	Authentication failed
500	-	-	Internal server error occurred

Table 17.

Process¶

Checks if request parameters include fmspc.
1. If fmspc is not included (will return platforms in registration queue):
  1. Gets the registration platforms list from cache db (see platformsRegDao.findRegisteredPlatforms).
2. If fmspc is provided ():
  1. The format should be [fmspc1, fmspc2, …]. If not, returns the 400 error.
  2. Gets cached platforms, whose fmspc is in the list (see platformsDao.getCachedPlatformsByFmspc).
Returns the JSON list in response body and platforms count in response header.

Put Platform Collateral to Cache¶

Administrators use this API to push the platform collateral for collected platforms from the PCS into the caching service. This API is restricted to users with the access to the admin-token.

Endpoint(s)¶

PUT https://pccs-server-url:8081/sgx/certification/v3/platformcollateral
PUT https://pccs-server-url:8081/sgx/certification/v4/platformcollateral

Request¶

Parameters¶

Name	Type	Request Type	Required	Pattern	Description
`Content-Type`	String	Header	True	`application/json`	MIME type of the request body.
`admin-token`	String	Header	True	String	The administrator token required to perform the request.
`platform_count`	Integer	Query	True	`^[1-9][0-9]*$`	Number of platforms in the PCK Certificate array.

Table 18.

Body¶

A JSON object includes all the collaterals for the registered platforms.

Body format:

{
    "platforms": [
        {
            "qe_id": "xxxx",
            "pce_id": "xxxx",
            "cpu_svn": "xxxx",
            "pce_svn": "xxxx",
            "enc_ppid": "xxxx",
            "platform_manifest": "xxxx"
        },
        {}
    ],
    "collaterals": {
        "version": "4",
        "pck_certs": [
            {
                "qe_id": "string",
                "pce_id": "string",
                "enc_ppid": "string",
                "platform_manifest": "string",
                "certs": []
            },
            {}
        ],
        "tcbinfos": [
            {
                "fmspc": "string",
                "sgx_tcbinfo": {},
                "tdx_tcbinfo": {}
            },
            {}
        ],
        "pckcacrl": "string",
        "qeidentity": "string",
        "tdqeidentity": "string",
        "qveidentity": "string",
        "certificates": {
            "SGX-PCK-Certificate-Issuer-Chain": "string",
            "TCB-Info-Issuer-Chain": "string",
            "SGX-Enclave-Identity-Issuer-Chain": "string"
        },
        "rootcacrl": "string"
    }
}

Response¶

Status codes¶

Code	Model	Headers	Description
200	-	-	Successfully completed
400	-	-	Invalid request parameters
401	-	-	Authentication failed
500	-	-	Internal server error occurred

Table 19.

Process¶

Validates the admin token(calculate sha-512 hash of the token and compare the hash value with AdminTokenHash in the configuration file). If the validation fails, returns the 401 error to client.
Validates the request body with pre-defined collateral schema. If the validation fails, returns the 400 error to client.
For each platform in the list:
1. Deletes old PCK Certificates for this platform (pckcertDao.deleteCerts).
2. Inserts all PCK Certificates for this platform to pck_cert table(pckcertDao.upsertPckCert).
3. Merges the raw TCBs in the request and cached platform_tcbs table to get a full raw tcb list.
4. Extracts fmspc and ca value from any leaf cert (use the first cert for convenience).
5. Finds the TCB Info for this fmspc from the TCBInfos in the request.
6. For each raw TCB in the raw tcb list:
  1. Gets the best cert with PCKCertSelectionTool using {cpusvn, pcesvn, pceid, TCB Info, PCK Certificates}.
  2. Updates platform_tcbs tables.
7. Updates platforms table.
For each TCB Info in the list:
1. Updates fmspc_tcbs table.
Updates pck_crl, qe_identities, qve_identities, pck_certchain if present.
Updates pcs_certificates and root CA CRL if present.

Cache Data Refresh¶

Refresh through HTTP Request¶

This API is for maintenance only. Refresh expired {TCB Info, PCK CRLs, QE Identity, QvE Identity, Root CA CRL} or {PCK Certificates} in cache DB. This API is restricted to users with the access to the admin-token.

Note

This API can be used when configured for with REQ or LAZY cache fill mode. It is not supported for OFFLINE cache fill mode.

Endpoint(s)¶

[Deprecated] GET https://pccs-server-url:8081/sgx/certification/v3/refresh
POST https://pccs-server-url:8081/sgx/certification/v3/refresh
POST https://pccs-server-url:8081/sgx/certification/v4/refresh

Request¶

Name	Type	Request Type	Required	Pattern	Description
`type`	String	Query	False	`certs`	Refresh type. If not provided, TCB Info, PCK CRLs, QE Identity, TDQE identity (v4 only) and QVE Identity will be refreshed. If `type = certs` and no fmspc is specified, all cached PCK Certificates will be refreshed.
`admin-token`	String	Header	True	String	The administrator token required to perform the request.
`fmspc`	String	Query	False	FMSPc1, FMSPC2, …, FMSPcn	Used with "type=certs". If fmspc is provided, refresh only certs for those FMSPCs.

Table 20.

Response¶

Based on the result, returns one of the following status codes.

Status codes¶

Code	Model	Headers	Description
200	-	-	Successfully completed
401	-	-	Operation failed
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS
503	-	-	Server is currently unable to process the request

Table 21.

Process¶

Default (type is not specified)¶

For each record in pck_crls table, contacts PCS service to get the latest PCK CRL and PCK CRL certificate chain, then updates the pck_crls table if necessary.

For each record in fmspc_tcbs table, contacts PCS service to get the latest TCB Info, then updates the fmspc_tcbs table if necessary.

For each record in identities table, contacts PCS service to get the latest QE Identity, QvE Identity and TDQE identity (v4 only) then updates the identities table if necessary.

Refresh root CA CRL: Get the root CA from pcs_certificates table, and parse it to get the CRL cdp uri, then contacts PCS service to get the CRL and update the pcs_certificates table.

Refresh cached CRLs: Get all cached CRLs from crl_cache table, for each of them, download the CRL with the cdp_url as target url, and update the crl_cache table.

Type is `certs`¶

Gets all records for all the FMSPCs in the platform_tcbs table (see platformTcbsDao.getPlatformTcbs(fmspc)). If the FMSPCs are not provided, updates all platforms that are already cached.
Sorts the records by {qeid, pceid} so that the TCB mapping records of the same platform are put together.
For each platform:
1. Gets all PCK Certificates for this platform from Intel SGX/TDX with {encrypted_ppid, pceid} or {PLATFORM_MANIFEST, pceid}.
2. Parses the first cert (X.509) in the array to get FMSPC value.
3. Contacts PCS again to get TCB Info with the above FMSPC value.
  
  Note: This does not update the TCB Info in the cache. The TCB Info is only used with the PCK Cert Selection library to update the platform_tcbs table.
4. Deletes old certificates and inserts new certificates for the platform.
5. For each raw TCB in the list of step 2, runs the PCK Cert Selection Tool to get the best certificate and update the cache.

Scheduled Cache Data Refresh¶

The PCCS can also be configured to refresh the cache data regularly, for example, once a day or once a week, etc. The scheduled task does not refresh PCK Certificates because the network traffic overhead is large.

This refresh method is only supported in the LAZY cache fill mode.

It supports Cron-style Scheduling:

* * * * * *
┬ ┬ ┬ ┬ ┬ ┬
│ │ │ │ │ │
│ │ │ │ │ └ day of week (0 - 7) (0 or 7 is Sun)
│ │ │ │ └───── month (1 - 12)
│ │ │ └────────── day of month (1 - 31)
│ │ └─────────────── hour (0 - 23)
│ └──────────────────── minute (0 - 59)
└───────────────────────── second (0 - 59, OPTIONAL)

Get CRL by endpoint¶

Retrieve the X.509 Certificate Revocation List by the CRL endpoint.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/crl
GET https://pccs-server-url:8081/sgx/certification/v4/crl

Request¶

Name	Type	Request Type	Required	Pattern	Description
`uri`	String	Query	True	Example: https://certificates.trustedservices.intel.com/IntelSGXRootCA.der	URL to DER-encoded CRL (Root CA CRL, Platform/Package CA PCK CRL)

Table 22.

Response¶

Crl - DER-encoded representation of specified CRL.

Status codes¶

Code	Model	Headers	Description
200	`Crl`	-	Successfully completed
400	-	-	Invalid request parameters
500	-	-	Internal server error occurred
502	-	-	Unable to retrieve the collateral from the PCS
503	-	-	Server is currently unable to process the request

Table 23.

Process¶

Checks request parameters and returns the 400 error if the input parameter is invalid
Queries CRL with the uri as the key (see crlCacheDao.getCrl).
1. If record exists:
  1. Returns the crl buffer.
  2. Responds with the 200 status code.
2. Else:
  1. If cache fill mode is not LAZY, returns the 404 (No cache data) error to client.
  2. If cache fill mode is LAZY
    1. Download the CRL with the uri address as target. If failed, returns the 404 error.
    2. Updates crl_cache table:
      1. Calls crlCacheDao.upsertCrl(uri, crl), crl is response body.
    3. Returns CRL in the response body.
    4. Responds with the 200 status code.

Get default platform policy¶

Retrieve the default platform policy provided by the platform owner.

Endpoint(s)¶

GET https://pccs-server-url:8081/sgx/certification/v3/appraisalpolicy
GET https://pccs-server-url:8081/sgx/certification/v4/appraisalpolicy

Request¶

Name	Type	Request Type	Required	Pattern	Description
`fmspc`	String	Query	True	`^[0-9a-fA-F]{12}`	Base16-encoded FMSPC value

Table 24.

Response¶

The default platform policy for this fmspc in jwt format.

Status codes¶

Code	Model	Headers	Description
200	-	-	Successfully completed
400	-	-	Invalid request parameters
404	-	-	The default platform policy can't be found.
500	-	-	Internal server error occurred

Table 25.

Process¶

Checks request parameters and returns the 400 error if the input parameter is invalid
Queries the policy whose default flag is true for the specified fmspc (see appraisalPolicyDao. getDefaultAppraisalPolicies).
1. If record exists:
  1. Returns the policy buffer.
  2. Responds with the 200 status code.
2. Else:
  1. Returns the 404 error.

Put appraisal policy¶

Upload an appraisal policy to the PCCS.

Endpoint(s)¶

PUT https://pccs-server-url:8081/sgx/certification/v3/appraisalpolicy
PUT https://pccs-server-url:8081/sgx/certification/v4/appraisalpolicy

Request¶

Parameters¶

N/A

Body¶

{
    "policy": policy string,
    "is_default": default flag,
    "fmspc": fmspc value
}

Response¶

Status codes¶

Code	Model	Headers	Description
200	-	-	Successfully completed
400	-	-	Invalid request parameters
401	-	-	Authentication failed
500	-	-	Internal server error occurred

Table 26.

Process¶

Validates the admin token(calculate sha-512 hash of the token and compare the hash value with AdminTokenHash in the configuration file). If the validation fails, returns the 401 error to client.
Validates the request body with pre-defined policy schema. If the validation fails, returns the 400 error to client.
Calculate sha384 hash of the policy data, which will be used as the ID of the policy.
Parse the policy file to get policy type based on the class id. Currently only 3 types are supported: 0 – SGX; 1 – TDX 1.0; 2 – TDX 1.5;
Insert or update the appraisal_policies table (see appraisalPolicyDao).

Database¶

Schema Definition¶

`pck_cert`¶

Cache table for all PCK Certificates of platforms. A {qe_id, pce_id} pair uniquely identifies a platform. There should be only one valid PCK Certificate for certain TCBm of the platform.

`platform_tcbs`¶

Stores the raw TCB to TCBm mapping.

`platforms`¶

Stores information of a specific platform identified by {qe_id, pce_id}.

`pck_crl`¶

Cache table for PCK CRL.

`fmspc_tcbs`¶

Cache table for TCB Info.

`identities`¶

Cache table for Enclave and TD Identities – QE, QVE, and TD QE.

ID(PK)	Description
1	QE Identity
2	QVE Identity
3	TD QE Identity

Table 1.

`pcs_certificates`¶

ID(PK)	CERT	CRL	Description
1	BLOB	BLOB	Processor Root CA
2	BLOB	BLOB	Processor Intermediate CA
3	BLOB	BLOB	TCB Signing CA
4	BLOB	BLOB	Platform Intermediate CA

Table 2.

`platforms_registered`¶

Registration table for platforms.

`pck_certchain`¶

Cache table for PCK certificate chain IDs.

ca(PK)	root_cert_id	intmd_cert_id	Description
PROCESSOR	1	2
PLATFORM	1	4

Table 3.

Data Access Objects¶

platformsDao¶

upsertPlatform(qe_id, pce_id, platform_manifest, enc_ppid, fmspc,ca)

Inserts into or updates platforms table with {qe_id, pce_id, platform_manifest, enc_ppid, fmspc,ca}.

getPlatform(qe_id, pce_id)

Searches for a single platform instance by the {qe_id, pce_id} key pair.

updatePlatform(qe_id, pce_id, platform_manifest, enc_ppid)

Updates a single record of platforms table identified by the {qe_id, pce_id} key pair with new platform_manifest and enc_ppid values.

getCachedPlatformsByFmspc(fmspc_arr)

The input fmspc_arr is an array of fmspc values. This function queries all cached platforms based on the fmspc array.

select a.qe_id, a.pce_id, b.cpu_svn, b.pce_svn,
    a.enc_ppid, a.platform_manifest
from platforms a, platform_tcbs b where a.qe_id=b.qe_id
    and a.pce_id = b.pce_id and a.fmspc in (:fmspc_arr)

pckcertDao¶

getCert(qe_id, cpu_svn, pce_svn, pce_id)

Queries PCK Certificate and PCK certificate chain based on the input keys.

select b.*,
    (select cert from pcs_certificates e where e.id=d.root_cert_id)
        as root_cert,
    (select cert from pcs_certificates e where e.id=d.intmd_cert_id)
        as intmd_cert
from platform_tcbs a, pck_cert b, platforms c left join pck_certchain d on c.ca=d.ca
where a.qe_id=$qe_id and a.pce_id=$pce_id and a.cpu_svn=$cpu_svn
    and a.pce_svn=$pce_svn and a.qe_id=b.qe_id and a.pce_id=b.pce_id
    and a.tcbm=b.tcbm and a.qe_id=c.qe_id and a.pce_id=c.pce_id

getCerts(qe_id, pce_id)

Queries all PCK Certificates associated with the input qe_id and pce_id.

upsertPckCert(qe_id, pce_id, tcbm, cert)

Inserts into or updates pck_cert table with the input parameters.

deleteCerts(qe_id, pce_id)

Deletes all records associated with {qe_id, pce_id} from pck_cert table.

fmspcTcbDao¶

upsertFmspcTcb(tcbinfoJson, update_type): Inserts into or updates fmspc_tcbs table with the input tcbinfoJson:

Target Field	Value
type	tcbinfoJson.type
fmspc	tcbinfoJson.fmspc
update_type	update_type
version	tcbinfoJson.version
tcbinfo	tcbinfoJson.tcbinfo
root_cert_id	1
signing_cert_id	3

Table 4.

getTcbInfo(type, fmspc, version, update_type)

Queries TCB Info and TCB Info issuer chain for given fmspc

select a.*,
    (select cert from pcs_certificates where id=a.root_cert_id)
        as root_cert,
    (select cert from pcs_certificates where id=a.signing_cert_id)
        as signing_cert
from fmspc_tcbs a where a.type=$type and a.fmspc=$fmspc
    and a.update_type=$update_type and a.version=$version

getAllTcbs()

Queries all TCB Info records from fmspc_tcbs table.

pckCertchainDao¶

upsertPckCertchain(ca)

Inserts into or updates pck_certchain table with the below record:

{id:1, root_cert_id:1, intmd_cert_id:2 for processor CA and 4 for platform CA}

getPckCertchain (ca)

Queries PCK Certificate issuer chain for the input ca:

select a.*,
    (select cert from pcs_certificates where id=a.root_cert_id)
        as root_cert,
    (select cert from pcs_certificates where id=a.intmd_cert_id)
        as intmd_cert
from pck_certchain a
where a.ca=$ca

pckcrlDao¶

getPckCrl(ca)

Queries PCK CRL and PCK CRL certificate chain for given ca.

select a.*,
    (select cert from pcs_certificates where id=a.root_cert_id)
        as root_cert,
    (select cert from pcs_certificates where id=a.intmd_cert_id)
        as intmd_cert
from pck_crl a
where a.ca=$ca

upsertPckCrl(ca, crl)

Inserts into or updates pck_crl table with the input ca and crl:

Target Field	Value
ca	The input ca value
pck_crl	The input crl value
root_cert_id	1
intmd_cert_id	2 for processor CA and 4 for platform CA

Table 5.

pcsCertificatesDao¶

upsertPcsCertificates(pcsCertJson): Inserts into or updates pcs_certificates table with the pcsCertJson object, which can be mapped to one record of the table.
upsertPcsCertificates(id, cert): Inserts into or updates pcs_certificates table with the input id and cert values.
upsertPckCertificateIssuerChain(ca, pck_certchain): Splits the input pck_certchain into SGX Intermediate CA Certificate and SGX Root CA Certificate, then updates/inserts them into pcs_certificates table. When ca is processor, use 2 for pcs_certificates.id, when ca is platform, use 4 for pcs_certificates.id.
upsertPckCrlCertchain(ca, pck_crl_certchain): Splits the input pck_crl_certchain into SGX Intermediate CA Certificate and SGX Root CA Certificate, then updates/inserts them into pcs_certificates table. When ca is processor, use 2 for pcs_certificates.id, when ca is platform, use 4 for pcs_certificates.id.
upsertTcbInfoIssuerChain(tcbinfo_certchain): Splits the input tcbinfo_certchain into SGX TCB Signing Certificate and SGX Root CA Certificate, then updates/inserts them into pcs_certificates table.
upsertIdentityIssuerChain(identity_certchain): Splits the input enclave_identity_certchain into SGX Enclave Signing Certificate and SGX Root CA Certificate, then updates/inserts them into pcs_certificates table.
getCertificateById(ca_id): Finds a single instance identified by the ca_id from pcs_certificates table.
upsertRootCACrl(rootcacrl): Updates the root certificate CRL(id=1) in pcs_certificates table.

platformsRegDao¶

findRegisteredPlatform(regDataJson): Searches a single instance from platforms_registered table by {regDataJson}.
findRegisteredPlatform(): Finds all records whose status are NEW from platforms_registered table.
registerPlatform(regDataJson, state): Adds a new record to platforms_registered table with the values in regDataJson and the state parameter.
deleteRegisteredPlatforms(): Updates all records with NEW state to DELETED state.

platformTcbsDao¶

upsertPlatformTcbs(qe_id, pce_id, cpu_svn, pce_svn, tcbm)

Inserts into or updates platform_tcbs table with the input parameters.

getPlatformTcbs(fmspc)

Gets all cached platform_tcbs for the input fmspc. It also needs to return the enc_ppid value. If fmspc is null, then all cached platform_tcbs are returned.

select a.*,b.enc_ppid as enc_ppid
from platform_tcbs a, platforms b where a.qe_id=b.qe_id
    and a.pce_id=b.pce_id and b.fmspc=$fmspc

getPlatformTcbsById (qe_id, pce_id)

Gets all records associated with the input qe_id and pce_id from platform_tcbs table.

identityDao¶

upsertIdentity(id, identity, update_type, version): Updates or inserts into identities table.

Target Field	Value
id	The input id parameter
update_type	update_type
version	The input version parameter
identity	The input identity parameter
root_cert_id	1
signing_cert_id	3

Table 6.

getIdentity(id, version)

Gets the identity and identity issuer chain from identities and pcs_certificates table.

select a.*,
    (select cert from pcs_certificates where id=a.root_cert_id)
        as root_cert,
    (select cert from pcs_certificates where id=a.signing_cert_id)
        as signing_cert
from identities a
where a.id=$id and a.update_type=$update_type and a.version=$version

crlCacheDao¶

upsertCrl (cdp_url, crl): Updates or inserts into crl_cache table.

Target Field	Value
cdp_url	cdp_url
crl	crl

Table 7.

getCrl(cdp_url): Gets the CRL for the specified cdp_url.
getAllCrls(): Get all cached CRLs.

appraisalPolicyDao¶

upsertAppraisalPolicy(apJson): Updates or inserts into appraisal_policies table.

Target Field	Value
id	Sha384(apJson.policy)
type	Type of the policy
policy	apJson.policy
Is_default	apJson.is_default
fmspc	apJson.fmspc

Table 8.

getDefaultAppraisalPolicies(fmspc)

Gets the default policy for the fmspc from appraisal_policies table.

AppraisalPolicy.findAll({
    where: {
        is_default: true,
        fmspc: fmspc
    },
    attributes: ['policy']
})

Cache Fill Modes¶

When Intel SGX-based attestation should be used on any server, Intel® SGX attestation collateral is required for quote generation and quote verification. The attestation collateral can be retrieved from PCS and it should be cached in a collateral caching service, e.g., PCCS.

Currently, the PCCS supports the three cache fill modes described in the next sub-sections.

`LAZY` Cache Fill Mode¶

In this cache fill mode, when the PCCS gets a collateral retrieval request at runtime (for, e.g., PCK Certificate or TCB Info), it looks for the collateral in its database to see if it is already in the cache.

If the collateral is present in the cache and it is still valid it will be returned. If the collateral is not present in the cache or it is invalid, PCCS contacts the PCS to retrieve the collateral.

Note

This mode expects continuos Internet connection to request attestation collateral from PCS whenever required.

`REQ` Cache Fill Mode¶

In this cache fill mode, the PCCS creates a platform database entry when the PCCS receives a platform registration requests during platform deployment/provisioning using the Post Platforms IDs API. The PCK Cert ID Retrieval Tool can be used to send platform registration information to the PCCS.

Even if the collateral is present in the cache, nothing will be returned to the caller. If the collateral is not present in the cache, PCCS retrieves the collateral from PCS. PCCS saves the retrieved collateral in cache database for use during runtime.

Note

During deployment/provisioning, this mode requires the PCCS to have an Internet connection.
During runtime, the PCCS uses cache data only and does not contact PCS.

`OFFLINE` Cache Fill Mode¶

In this cache fill mode, the PCCS does not have access to the PCS on the Internet. Instead, the PCCS has to be filled manually.

At first, platform registration information must be retrieved from the target platforms and must be sent to PCCS using the Post Platforms IDs API. The PCK Cert ID Retrieval Tool can be used for these tasks.

Later, the registration information can be collected from the PCCS using the Get Platforms IDs. The get operation of the PCCS Admin Tool can be used for this request. The tool saves the result to a JSON file.

If the platform that created the JSON file does not have Internet, the JSON file must be transferred out-of-band to a platform with Internet access. On a platform with Internet access, the Web API of PCS must used to retrieve the collateral. The PCS Client Tool can be used for the request and it expects the JSON file from the PCCS Admin Tool as input.

The collateral has to be transferred out-of-band to a platform with PCCS access. On this machine, the collateral has to be pushed to the PCCS using the Put Platform Collateral to Cache API. The put operation of the PCCS Admin Tool can be used for this operation.

Note

This mode is especially suitable in an air-gap environment because it does not require any Internet connectivity from the PCCS.

Configuration File¶

The PCCS can be configured using a configuration file, default.json, located in the config sub-directory under the PCCS installation directory.

Settings in the Configuration File¶

HTTPS_PORT

The port you want the PCCS to listen on. The default listening port is 8081.

hosts

The hosts that will be accepted for connections. Default is localhost only. To accept all connections, use 0.0.0.0

uri

The URL of Intel Provisioning Certificate Service. The current URL is https://api.trustedservices.intel.com/sgx/certification/v4/

ApiKey

The PCCS use the API key to request collateral from Intel Provisioning Certificate Service. You need to subscribe first to obtain an API key. For how to subscribe to the Intel Provisioning Certificate Service and receive an API key, go to PCS API Portal and click 'Subscribe' (Note: You need an Intel® Developer Zone (IDZ) account to register).

Proxy

Specify the proxy server for Internet connection, for example, http://192.168.1.1:80>. Leave it blank for no proxy or system proxy.

RefreshSchedule

cron-style refresh schedule for the PCCS to refresh cached artifacts including CRL/TCB Info/QE Identity/QVE Identity. The default setting is 0 0 1 \* \* \*, which means refresh at 1:00 am every day.

UserTokenHash

Sha512 hash of the user token for the PCCS client user to register a platform. For example, PCK Cert ID Retrieval Tool uses the user token to send platform information to PCCS. Required by the Post Platforms IDs.

AdminTokenHash

Sha512 hash of the administrator token for the PCCS administrator to perform a manual refresh of cached artifacts. It is required by these APIs: Get registered platforms, Put platform collateral to cache and Cache data refresh.

Note

For Windows you need to set the UserTokenHash and the AdminTokenHash manually. You can calculate SHA512 hash in PowerShell using the following command:

Powershell

[BitConverter]::ToString(
    [System.Security.Cryptography.SHA512]::Create().ComputeHash(
        [System.Text.Encoding]::UTF8.GetBytes((Read-Host 'Enter token'))
    )
).Replace('-', '').ToLower()

CachingFillMode

The method used to fill the cache DB. Can be one of the following: REQ/LAZY/OFFLINE. See page Cache Fill Modes

LogLevel

Log level. Use the same levels as npm: error, warn, info, http, verbose, debug, silly. Default is info. Log messages are written to <PCCS Install Directory>/logs/pccs server.log.

DB_CONFIG

You can choose Sqlite or Mysql and many other DBMSes. For Sqlite, you do not need to change anything. For other DBMSes, you need to set database connection options correctly. Normally you need to change database, username, password, host, and dialect to connect to your DBMS.

Configuration File Example¶

{
    "HTTPS_PORT": 8081,
    "hosts": "127.0.0.1",
    "uri": "https://api.trustedservices.intel.com/sgx/certification/v3/",
    "ApiKey": "<Your API key>",
    "proxy": "",
    "RefreshSchedule": "0 0 1 \* \* \*",
    "UserTokenHash": "",
    "AdminTokenHash": "",
    "CachingFillMode": "",
    "LogLevel": "info",
    "DB_CONFIG": "sqlite",
    "sqlite": {
        "database": "database",
        "username": "<Your sqlite username>",
        "password": "<Your sqlite password>",
        "options": {
            "host": "localhost",
            "dialect": "sqlite",
            "storage": "pckcache.db"
        }
    }
}

PCCS Admin Tool¶

The PCCS Admin Tool is a Python* script that contains a set of commands to allow an administrator to manage the data cached inside PCCS. The tool's primary function is to help administer a PCCS setup in an environment without a direct connection to the Internet (i.e., PCCS configured in OFFLINE cache fill mode). The tool can also be used to trigger PCCS to refresh the collateral before they expire as well as refresh the data for a TCB Recovery.

Note

The PCCS Admin Tool input/output file formats are compatible with the PCS Client Tool so that both tools can be used together in order to complete an end-to-end platform registration flow in an air-gapped environment. Refer to Platform Registration for a flow description.

Supported Operations¶

The following operations are supported by the tool:

`get`¶

Retrieves queued platform registration from the PCCS using the Get Platform IDs API.

`put`¶

Imports the quote generation collateral (i.e. PCK Certificates) and quote verification collateral into the PCCS using the Put Platform Collateral to Cache API.

`refresh`¶

Request PCCS to refresh certificates and collateral in cache database using the Refresh through HTTP Request API of the PCCS. This operation only supported in LAZY or REQ cache fill mode – not in OFFLINE cache fill mode.

Download information¶

The PCCS Admin Tool can be found in the PCCS repository on GitHub*. The tool's command-line syntax and latest usage information are available in the README located in the same directory.

Cache Management Flows¶

Platform Registration¶

The PCCS maintains a queue of platform information called the platforms_registered table. Datacenter and CSP owners add new Intel® SGX platforms to this queue using the Post Platforms IDs API. Platform registration is expected to happen before runtime workloads are executed by tenants. The queue contains all of the platform information provided in the Post Platforms IDs API.

The PCCS adds the platform ID to the queue if any of the following are true:

An entry for that platform is not already in the PCCS's caching database.
1. The platform is already in the database if the EncPPID and the PLATFORM_MANIFEST in the Post Platforms IDs request is the same as the platform ID already in PCCS's caching database.
The PLATFORM_MANIFEST in the registration request is different than the platform's PLATFORM_MANIFEST in the database.
Any of the collaterals (PCK Certificates + verification collateral) for that platform entry is not already in the database.

Cache Fill Mode is `LAZY` or `REQ`¶

When the PCCS gets the Post Platforms IDs request and adds a platform to the queue, it contacts the PCS to retrieve the platform's PCK Certificates.

If the request contains the PLATFORM_MANIFEST, it uses the PCS API to retrieve multiple PCK Certificates using the {PLATFORM_MANIFEST,PCEID} tuple.
If the PLATFORM_MANIFEST is not present, it uses the PCS API to retrieve multiple PCK Certificates using the {EncPPID,PCEID} tuple.

Once the PCCS retrieves the PCK Certificates, the corresponding verification collateral is also retrieved in the following way:

TCB Info:
1. Extract the FMSPC from the PCK Leaf Cert.
2. If the TCB Info for that FMSPC is not already in the database, the PCCS retrieves the TCB Info from the PCS.
Intel PCK Certificate CA CRL:
1. Extract the FMSPC from the PCK Leaf Cert.
2. If the TCB Info for that FMSPC is not already in the database, the PCCS retrieves the TCB Info from the PCS.
QE Identity – If not already in the database.
QvE Identity – If not already in the database.
Intel SGX Root CA CRL:
1. The URL for the Intel SGX Root CA CRL needs to be extracted from the CDP field of one of the intermediate certs or the Intel SGX Root Cert.

If all the PCK Certificates and their associated collaterals are successfully retrieved (or already in the database), the PCCS creates the platform entry in the database. Otherwise, the PCCS' Post Platforms IDs API returns "Unable to retrieve the collateral from the PCS." in response to the request.

Note

When the caching server is configured for the LAZY cache fill mode, this registration step is not required. When in LAZY cache fill mode, the PCCS retrieves the respective platform collateral in response to the runtime request APIs:

Get PCK Certificate
Get PCK Certificate CRL
Get TCB Info
Get Intel's QE Identity
Get Intel's QvE Identity
Get Root CA CRL

This requires that the PCCS have access to the Internet during runtime workloads initiated by a tenant VM without requiring access to the PCCS admin token.

Cache Fill Mode is `OFFLINE`¶

In this cache fill mode, the following steps make up the registration flow:

Registration information (i.e., the Platform Manifest and other platform-related information) must be retrieved from the target platforms and this registration information must be sent to PCCS using the Post Platforms IDs API. The PCK Cert ID Retrieval Tool can be used for these tasks.
The platform registration information enqueued in the PCCS must be retrieved using the Get Platform IDs API. The enqueued registration information can be collected from the PCCS using the Get Platforms IDs. The get operation of the PCCS Admin Tool can be used for this request. The tool saves the result to a JSON file.
The retrieved registration collateral must be submitted to PCS to obtain attestation collateral. This step requires Internet connectivity, which might require manually transferring the JSON file from step 2 to another machine. The fetch operation of the PCS Client Tool can consume the JSON file from step 2 and retrieve the quote generation collateral (i.e., PCK Certificates). Additionally, the tool retrieves quote verification collateral (e.g., TCB Info, QE Identity, and QvE Identity). The tool saves both types of collateral to a new JSON file.
Finally, the resulting collateral must be imported back into the PCCS using its Put Platform Collateral to Cache API. This operation can be performed via the PCCS Admin Tool's put operation, which reads the JSON file from step 3. If the machine that was used to retrieve the collateral from PCS does not have access to PCCS, it is necessary to manually transfer the resulting JSON file to a machine with access.

Handling TCB Recoveries¶

When a security vulnerability is found and it affects one of the components in the Intel® SGX TCB or Intel® TDX TCB, a TCB-R process starts. As soon as a TCB-R is publicly announced, new PCK Certificates (for affected platforms) and updated verification collateral (e.g., TCB Info, QE Identity, and QVE Identity) is retrievable from PCS. As a result, the PCCS must be updated with new PCK Certificates - for all platforms affected by the TCB-R - and with all verification collaterals - regardless of affected platforms.

Cache Fill Mode is `LAZY` or `REQ`¶

In these cache fill modes, the PCCS has an Internet connection. An administrator can request an update in two ways:

List of affected FMSPC's is not known:
1. Re-register all platforms in the CSP or database using the Post Platforms IDs request. This ensures all platforms that can generate a new PLATFORM_MANIFEST on TCB Recoveries get the PCK Certificates associated with this TCB Recovery.
  (Re-)registration: Tool information
  
  PCK Cert ID Retrieval Tool tool may be used for registration data collateral retrieval and direct upload into the PCCS using the Post Platforms IDs API.
  By default, the PCKCIDRT attempts automated upload of collected registration data to the PCCS set in its configuration file, but PCCS invocation can also be triggered explicitly by providing the URL in the CLI, for example via:
  - sudo PCKIDRetrievalTool -defaulturl
  - sudo PCKIDRetrievalTool -url https://YOUR_PCCS_URL:YOUR_PCCS_PORT -user_token YOUR_USER_TOKEN -proxy_type YOUR_PROXY_TYPE -use_secure_cert true
  Alternative: PCCS not directly reachable by PCKCIDRT tool
  
  In a rare scenario when the PCKCIDRT on the target platform does not have direct connectivity to the PCCS³, the updated registration data may be stored in a CSV file instead.
  
  For example, by using the following command:
  - sudo PCKIDRetrievalTool -f host_$(hostnamectl --static).csv
  Subsequently, the registration data may be directly submitted to the PCS service, using the PCS Client Tool's collect operation, followed by a fetch operation. The resulting quote generation collateral can then be uploaded to the PCCS, using PCCS Admin Tool's put operation.
  
  For example:¹
  Option 1: Packaged toolsOption 2: Tools installed from source
  
  pcs-client-tool collect -d DIRECTORY_CONTAINING_CSV_FILES -o platform_list.json # Note Internet connectivity is required for next command pcs-client-tool fetch -i platform_list.json -o platform_collaterals.json # Note PCCS connectivity is required for next command pccs-admin-tool put -i platform_collaterals.json
  
  ./pcsclient.py collect -d DIRECTORY_CONTAINING_CSV_FILES -o platform_list.json # Note Internet connectivity is required for next command ./pcsclient.py fetch -i platform_list.json -o platform_collaterals.json # Note PCCS connectivity is required for next command ./pccsadmin.py put -i platform_collaterals.json
2. Send the Refresh through HTTP Request with the optional type field certs option and without the optional fmspc field. This will refresh all the PCK Certificates in the cache for all registered platforms.
  - The PCCS Admin Tool's refresh operation can be used to trigger the aforementioned API via the CLI.¹
    Option 1: Packaged toolsOption 2: Tools installed from source
    pccs-admin-tool refresh -f all
    
    python pccsadmin.py refresh -f all
3. Send the Refresh through HTTP Request without the optional type field option and without the optional fmspc field. This will refresh all the verification collateral in the cache.
  - The PCCS Admin Tool's refresh operation can be used for this API request¹
    Option 1: Packaged toolsOption 2: Tools installed from source
    pccs-admin-tool refresh
    
    python pccsadmin.py refresh
List of affected FMSPC's is known:
1. Send the Refresh through HTTP Request with the optional type field certs option and the optional fmspc to the list of FMSPCs affected by the TCB Recovery. This will refresh all the PCK Certificates in the cache for all registered platforms.
  - The PCCS Admin Tool's refresh operation can be used for this API request¹
    Option 1: Packaged toolsOption 2: Tools installed from source
    pccs-admin-tool refresh -f [FMSPC1, FMSPC2, ...]
    
    python pccsadmin.py refresh -f [FMSPC1, FMSPC2, ...]
2. Send the Refresh through HTTP Request without the optional type field option and without the optional fmspc field. This will refresh all the verification collateral in the cache.
  - The PCCS Admin Tool's refresh operation can be used for this API request¹
    Option 1: Packaged toolsOption 2: Tools installed from source
    pccs-admin-tool refresh
    
    python pccsadmin.py refresh

Cache Fill Mode is `OFFLINE`¶

In this cache fill mode, the PCCS will not request any data from PCS by itself. Instead, all collateral must be pushed to the PCCS manually, which can be done using the PCCS Admin Tool.

Re-register all platforms in the CSP or database using the Post Platforms IDs request. This ensures all platforms that can generate a new PLATFORM_MANIFEST on TCB Recoveries get the PCK Certificates associated with this TCB Recovery.
On a machine that has a PCCS connection, use the PCCS Admin Tool to retrieve the registered platform IDs from the cache¹:
Option 1: Packaged toolsOption 2: Tools installed from source
pccs-admin-tool get -s [FMSPC1,FMSPC2, …] -t YOUR_PCCS_ADMIN_TOKEN
python pccsadmin.py get -s [FMSPC1,FMSPC2, …] -t YOUR_PCCS_ADMIN_TOKEN
Note

Use empty brackets [] to get the platform IDs for all FMSPCs.
Use the PCS Client Tool to fetch collateral from the PCS.² The tool must run on a machine that has an Internet connection.
Option 1: Packaged toolsOption 2: Tools installed from source
pcs-client-tool fetch -k YOUR_INTEL_PCS_API_KEY
python pcsclient.py fetch -k YOUR_INTEL_PCS_API_KEY
Use the PCCS Admin Tool to put the collateral into the cache.¹
Option 1: Packaged toolsOption 2: Tools installed from source
pccs-admin-tool put -t YOUR_PCCS_ADMIN_TOKEN
python pccsadmin.py put -t YOUR_PCCS_ADMIN_TOKEN

Special handling of Multi-Package TCB Recovery¶

There may be cases where a TCB Recovery requires a microcode patch. There is no guarantee that a given platform will be patched with the new microcode patch before Intel announces the TCB Recovery. In this case, the PCS will not be able to generate all PCK Certificates required for this TCB Recovery. When this happens, the Get PCK Certificates API of the PCS will return a Not available string instead of the PEM encoded PCK Certificate for the affected TCB Levels. Until the missing PCK Certificates exist in the PCCS database, the PCCS will return the PCK Certificate with the highest TCB for the requesting platform.

The PCCS and the PCCS Admin Tool will provide information to the PCCS administrator when this occurs. This allows the administrator to retry the TCB Recovery related collateral refresh for the affected platforms. The method of indication depends on the cache fill mode.

Cache Fill Mode is `LAZY`¶

The PCCS will automatically handle this case. The PCCS will continue to request PCK Certificates from the PCS for each affected platform when requested by that platform until it receives a complete set of PCK Certificates.

PCCS should provide the requester with the 'best' PCK Certificate it can use by running the PCK Cert Selection Library with the available PCK Certificates for the platform. It should only fail to provide a PCK Certificate to the requester if the PCK Cert Selection logic fails.

Cache Fill Mode is `REQ`¶

The PCCS will store the affected Platform IDs in the database's cached platform table. The administrator retrieves the PCK Certificates from the database using the PCCS Admin Tool's get operation with the source parameter set to -reg_na.

The administrator can then request the PCK Certificates for these platforms from the PCS, using the PCS Client Tool's fetch operation and import them to the PCCS using PCCS Admin Tool's put operation.

Cache Fill Mode is `OFFLINE`¶

The PCS Client Tool's fetch operation will output a warning that some platform's PCK Certificates were not available from the PCS. It will prompt the administrator to store the platform IDs in a file. The administrator can then retry the fetch operation for these files once the platforms have been patched.

Refreshing Expiring Collateral¶

Some of the cached verification collateral have short lifetimes whereas PCK Certificates are long-lived. The CSP or infrastructure owner needs to set up a policy for refreshing this collateral. It is possible to retrieve all the collaterals including PCK Certificates (similar to the process described in Handling TCB Recoveries), but every platform has a unique set of PCK Certificates, and refreshing PCK Certificates can incur a lot of overhead. To refresh expiring verification collateral without refreshing PCK Certificates, the following flows can be used.

Cache Fill Mode is `LAZY`¶

In this mode, the PCCS can directly retrieve collateral from PCS. An administrator can request an update of only the verification collateral in two ways:

Set up a timed refresh using the method described in Scheduled Cache Data Refresh.
Use the method described in the next sub-section for the REQ cache fill mode.

Cache Fill Mode is `REQ`¶

In this mode, the PCCS can directly retrieve collateral from PCS. An administrator can request an update of only the verification collateral as follows:

Send the Refresh through HTTP Request without the optional type filed option and without the optional fmspc field.
The PCCS Admin Tool's refresh operation can be used to trigger the aforementioned API.¹
Option 1: Packaged toolsOption 2: Tools installed from source
pccs-admin-tool refresh
python pccsadmin.py refresh

Cache Fill Mode is `OFFLINE`¶

In this mode, the PCCS cannot retrieve collateral from PCS by itself. An administrator can request an update of collateral as follows:

Create a platform_list.json file simply put a pair of brackets in it, i.e., [].
Use PCS Client Tool to fetch collateral from the PCS.²
Option 1: Packaged toolsOption 2: Tools installed from source
pcs-client-tool fetch -k YOUR_INTEL_PCS_API_KEY
python pcsclient.py fetch -k YOUR_INTEL_PCS_API_KEY
Use PCCS Admin Tool to put the collateral into the cache.
Option 1: Packaged toolsOption 2: Tools installed from source
pccs-admin-tool put -t YOUR_PCCS_ADMIN_TOKEN
python pccsadmin.py put -t YOUR_PCCS_ADMIN_TOKEN

Database migration¶

Migrating from v2 caching database (DCAP v1.8 and before) to v3 caching database (DCAP v1.9 and after)¶

Versions of PCCS from v1.8 and earlier do not support automatic database migration. The following steps describe how to import platform data from a v2 PCCS to a v3 PCCS.

An administrator may want to import platform data from a v2 PCCS after he/she has set up a v3 PCCS. To ensure the certificate and collateral data is up to date, we suggest the administrator first retrieves the cached platforms list from v2 PCCS using the PCCS Admin Tool. Then, the administrator should use the fetch operation of the PCS Client Tool to retrieve platform collateral from PCS service. and finally use put operation to upload the data to V3 PCCS service.

Use the PCCS Admin Tool to retrieve the cached platform IDs from the v2 PCCS.¹

Option 1: Packaged toolsOption 2: Tools installed from source

pccs-admin-tool get \
    -s [] -u V2_PCCS_SERVICE_URL -t YOUR_PCCS_ADMIN_TOKEN

python pccsadmin.py get \
    -s [] -u V2_PCCS_SERVICE_URL -t YOUR_PCCS_ADMIN_TOKEN

Use the PCS Client Tool to fetch collateral from the v3 PCS.²

Option 1: Packaged toolsOption 2: Tools installed from source

pcs-client-tool fetch \
    -k YOUR_INTEL_PCS_API_KEY

python pcsclient.py fetch \
    -k YOUR_INTEL_PCS_API_KEY

Use the PCCS Admin Tool to put the collateral into v3 PCCS.¹

Option 1: Packaged toolsOption 2: Tools installed from source

pccs-admin-tool put \
    -u V3_PCCS_SERVICE_URL -t YOUR_PCCS_ADMIN_TOKEN

python pccsadmin.py put \
    -u **V3**_PCCS_SERVICE_URL -t YOUR_PCCS_ADMIN_TOKEN

Migrating database from DCAP v1.9 to newer versions of DCAP¶

The PCCS installation supports automatic database migration starting from DCAP v1.9. Database backup is recommended before performing the upgrade and the installer will provide a warning before automatic migration occurs.

The name of the tool depends on the installation method. While pccsadmin.py is the script name, the intel-tee-pccs-admin-tool package additionally provides a convenience wrapper around its invocation in Python virtualenv, invocable system-wide, via pccs-admin-tool. ↩↩↩↩↩↩↩↩↩↩
The name of the tool depends on the installation method. While pcsclient.py is the script name, the intel-tee-pcs-client-tool package additionally provides a convenience wrapper around its invocation in Python virtualenv, invocable system-wide, via pcs-client-tool. ↩↩↩
This is a niche scenario. In most deployments, the PCCS is directly reachable from the target systems, including at the time of (re-)registration. ↩

Appendix A: PCS Client Tool¶

The PCS Client Tool is a Python* script that contains a set of commands to allow users to download and save data from PCS. Given platform information as input, the tool retrieves quote generation and quote verification collateral from the PCS. This data can then be saved to cache files (in which case PCCS is not needed) or used by PCCS Admin Tool to save that data in PCCS.

The PCS Client Tool is particularly useful in scenarios when the PCCS has no connection to the Internet on its own. In such scenarios, the PCCS would typically have its cache filling mode set to OFFLINE and file-based data transfer mechanisms would be used to move the platform registration requests (as well as the resulting quote generation and quote verification collateral) into and out of the air-gapped perimeter. The PCS Client Tool aids in these scenarios, particularly when used together with the PCCS Admin Tool as the file formats of both tools are compatible.

Supported Operations¶

The following operations of the PCS Client Tool are relevant to PCCS flows:

`fetch`¶

Based on a list of platforms provided as an input, fetch quote generation collateral (i.e., PCK Certificates) as well as quote verification collateral data from PCS.

Input: A JSON file containing a list of platforms. The PCCS Admin Tool is able to produce such a list with the get operation. Alternatively, the collect operation of the PCS Client tool can be used.
Output: Quote generation and quote verification collaterals, which are aggregated and saved into a single JSON file. The data from this file can be imported into the PCCS. The PCCS Admin Tool is able to perform this operation with the put operation.

`collect`¶

Combine individual CSV files containing platform information, which are generated by the PCK ID Retrieval Tool, into a single JSON file. This file can be used as input of the fetch or cache operations.

Input: One or multiple platform information files created by the PCK ID Retrieval Tool.
Output: A JSON file containing a list of platforms.

Note

The collect operation is not often used in setups where PCCS is available, as the PCK ID Retrieval Tool is typically setup to import the platform registration data directly into the PCCS.

`cache`¶

Based on the platform registration data provided as an input, fetch quote generation collateral (i.e., PCK Certificates) from PCS. Then, generate one cache file per target platform containing the retrieved information. These files can be used at the target platforms directly, provided the QCNL is configured in a local-only (air-gap) mode of operation ("local_cache_only": true setting in QCNL config file).

Input: A JSON file containing a list of platforms. The PCCS Admin Tool is able to produce such a list with the get operation. Alternatively, the collect operation of the PCS Client tool can be used.
Output: One binary file per target platform containing the corresponding PCK Certificate.

Note

Since the cache operation bypasses PCCS entirely, this operation is typically used in air-gapped setups where PCCS is not present.

Download information¶

The PCS Client Tool can be found in the DCAP project on GitHub*. The tool's complete command-line syntax and latest usage information are available in the README located in the same directory.

Design Guide for Intel® SGX and Intel® TDX Provisioning Certificate Caching Service (PCCS)

Introduction¶

Terminology¶

Overview¶

Architecture Overview – ECDSA-Based Data Center Attestation¶

Intel® SGX ECDSA Public Key and Data Structure Hierarchy¶

API Specification for PCCS¶

Get PCK Certificate¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Get PCK Certificate CRL¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Get TCB Info¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Get Intel's QE Identity¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Get Intel's QvE Identity¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Get Intel's TD QE Identity¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Get Root CA CRL¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Post Platforms IDs¶

Endpoint(s)¶

Request¶

Parameters¶

Body¶

Response¶

Status codes¶

Process¶

Get Platform IDs¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Put Platform Collateral to Cache¶

Endpoint(s)¶

Request¶

Parameters¶

Body¶

Response¶

Status codes¶

Process¶

Cache Data Refresh¶

Refresh through HTTP Request¶

Endpoint(s)¶

Request¶

Response¶

Status codes¶

Process¶

Default (type is not specified)¶

Type is certs¶

Type is `certs`¶

`pck_cert`¶

`platform_tcbs`¶

`platforms`¶

`pck_crl`¶

`fmspc_tcbs`¶

`identities`¶

`pcs_certificates`¶

`platforms_registered`¶

`pck_certchain`¶

`LAZY` Cache Fill Mode¶

`REQ` Cache Fill Mode¶

`OFFLINE` Cache Fill Mode¶

`get`¶

`put`¶

`refresh`¶

Cache Fill Mode is `LAZY` or `REQ`¶

Cache Fill Mode is `OFFLINE`¶

Cache Fill Mode is `LAZY` or `REQ`¶

Cache Fill Mode is `OFFLINE`¶

Cache Fill Mode is `LAZY`¶

Cache Fill Mode is `REQ`¶

Cache Fill Mode is `OFFLINE`¶