Verifiable Health Link, published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.0.2-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.VHL/ and changes regularly. See the Directory of published versions

2:3.YY2 Retrieve PKI Material

2:3.YY2 Retrieve PKI Material

2:3.YY2.1 Scope

The Retrieve PKI Material transaction allows both VHL Sharers and VHL Receivers to retrieve trusted cryptographic material from the Trust Anchor. This material includes:

• Public key certificates (e.g., X.509),
• Certificate revocation data (e.g., CRLs or OCSP responses),
• JSON Web Keys (JWKs) or equivalent,
• and associated metadata required to validate the authenticity of a Verified Health Link (VHL) and to establish mutually authenticated TLS (mTLS) sessions.

Retrieved material SHALL be used to determine the trustworthiness of VHL artifacts and service endpoints in accordance with the governing trust framework.

2:3.YY2.2 Actor Roles

Actor	Role
VHL Receiver, VHL Sharer	Request PKI material
	Receive PKI material
Trust Anchor	Provide PKI material

2:3.YY2.3 Referenced Standards

2:3.YY2.4 Messages

2:3.YY2.4.1 Retrieve PKI Material Request Message

2:3.YY2.4.1.1 Trigger Events

A VHL Sharer or VHL Receiver, as a participant in the trust network, SHALL be capable of requesting public key infrastructure (PKI) material from a designated Trust Anchor.

The retrieved material MAY include:

• Public key certificates and associated trust lists
• Certificate revocation data (e.g., CRLs, OCSP responses)
• Metadata used to:
  • Validate digital signatures on VHLs and related resources
  • Establish mutually authenticated TLS (mTLS) connections
  • Decrypt content protected via asymmetric encryption

Participants SHOULD cache the received trust list to reduce network and server load.

Preconditions:

• The requesting participant knows in advance the endpoint from which to retrieve PKI material, as published or distributed by the Trust Anchor.

2:3.YY2.4.1.2 Message Semantics

OPTIONS TO DISCUSS:

• DID / JSON Web Keys
• mCSD Endpoint

2:3.YY2.4.1.3 Expected Actions

2:3.YY2.4.2 Retrieve PKI Material Response Message

2:3.YY2.4.2.1 Trigger Events

A Trust Anchor initiates an Retrieve PKI Material Response Message once it has completed, to the extent possible, the expected actions upon receipt of a Retrieve PKI Material Request message.

2:3.YY2.4.2.2 Message Semantics

The Retrieve PKI Material request MAY take one of several forms, depending on the transport and representation models adopted by the content profile. Potential representations include:

• A FHIR Parameters resource with serialized public key material (e.g., PEM, DER, or JWK)
• A DID Document conforming to W3C DID Core
• A pointer to a .well-known URI under organizational control, with machine-readable key data

The payload SHOULD include sufficient metadata to identify the submitting entity and bind the key material to its intended usage context (e.g., use: "sig", keyOps, x5c chain).

Content profiles SHALL define exact payload constraints, validation rules, and error behaviors.

2:3.YY2.4.2.3 Expected Actions

A VHL Sharer or VHL Receiver, after receiving PKI material from a Trust Anchor, SHALL validate and process the trust information for subsequent cryptographic operations.

Participants SHOULD:

• Cache the received trust list or certificate material to reduce network and server load
• Validate digital signatures or trust paths before use in VHL validation or mTLS sessions
• Monitor certificate expiration or revocation status where applicable

2:3.YY2.5 Security Considerations

All Retrieve PKI Material interactions SHOULD occur over secure channels using TLS 1.2 or higher, with mTLS recommended for enhanced endpoint authentication. The Trust Anchor SHOULD validate the authenticity, scope, and expiration of all retrieved key material before publishing or caching.

Clients (e.g., VHL Receivers and VHL Sharers) SHOULD verify the signature chain or integrity envelope of the material prior to using it for signature verification or secure session establishment.

Implementers SHOULD ensure that any out-of-band trust anchors or directory sources (e.g., .well-known/ endpoints) are tamper-resistant and publicly resolvable.

Content profiles MAY define additional constraints, such as:

• Minimum key lengths
• Permitted algorithms (e.g., RSA-2048, ECDSA P-256)
• CRL/OCSP freshness requirements
• Retry and caching behavior