3.2.5.1 Validating an HCEP Request

When an HCEP request arrives from the client on the HRA, the HRA MUST perform correctness checks on the request.

The HRA MUST perform the following checks:

  1. All the required fields in an HCEP request MUST be present in the received request, as specified in section 2.2.1, including the health certificate request with statement of health certificate extension as specified in section 2.2.1.4.

  2. If the HRA is configured to authenticate the client (as specified in section 1.5), it MUST validate that the Subject Alternative Name (as specified in section 2.2.1.4) is the same as the FQDN of the authenticated client.

  3. If the HRA is configured to not authenticate the client (as specified in section 1.5), it MUST validate that the Subject Alternative Name (specified in section 2.2.1.4) is empty.

  4. The health certificate request that is present in the HCEP request MUST conform with the specification in section 2.2.1.4 for the rest of the fields not previously mentioned.

If any of these checks fail, the HRA MUST respond with an HTTP Internal Server Error, as specified in [RFC2616] section 6.1.1.

The HRA SHOULD<35> perform the following checks:

  1. The size of the request is less than the maximum size, as specified in section 3.2.1.

  2. The user agent that is present in the HCEP request contains one of the strings from the list of strings specified in section 3.2.1.

  3. The algorithm that is used for signing the certificate request is present in the list of algorithms specified in section 3.2.1.

  4. The public key in the certificate request is created by using an algorithm that is present in the list of algorithms specified in section 3.2.1.

  5. The CSP that is used to create the health certificate request is acceptable. This is accomplished by checking that the CSP certificate extension of the health certificate request (as specified in section 2.2.1.4) specifies a CSP that is present in the list of CSPs specified in section 3.2.1.

  6. If the HRA is configured to authenticate the client (as specified in section 1.5), it MAY validate the subject and Extended Key Usage as specified in section 2.2.1.4.

  7. If the HRA is configured to not authenticate the client (as specified in section 1.5), it MAY validate the subject as specified in section 2.2.1.4.

If any of the previous checks fail, the HRA MUST respond with an HTTP Internal Server Error, as specified in [RFC2616] section 6.1.1.