Implement PCS fetch function and bump dcap-qvl to 0.4

[ameba23]

dcap-qvl 0.4.0 has some breaking changes meaning we can no longer fetch collateral for a specific fmspc.

The related issue #31 proposes several options for resolving this, one of which is to implement the collateral fetch function ourselves. This PR does that.

I'm not sure this is the best path forwards but i wanted to show that its not so much code and has some big advantages of things we could do as follow-ups:

• Make a sync version using ureq for http, so that collateral can be fetched at the point of attestation verification during TLS handsahke Calling async verify function from synchronous verify_server_cert function #2
• Speed up initial 'warmup' of the PCCS by not duplicating API calls - this would mean it takes less than half the time it currently takes - see last part of PCCS crate PR notes: Add PCCS crate #3

[ameba23]

This is only to handle quotes without an embedded PCK certificate chain - meaning certification data type 2 or 3.

I have never come across one of these, and dcap-qvl also does not have one in their test fixtures. So we can't actually test this code against a real quote.

[Ruteri]

I'd suggest to put this as a comment into the code

[MoeMahhouk]

if serde_json::Value alphabetizes keys on re-serialization, would that cause a fail signature on real intel collateral? Take a look at verify_tcb_info_signature which does collateral.tcb_info.as_bytes()
For example:

INPUT : {"id":"TDX","version":3,"issueDate":"2026-04-23T09:13:04Z","fmspc":"90C06F000000"}
OUTPUT: {"fmspc":"90C06F000000","id":"TDX","issueDate":"2026-04-23T09:13:04Z","version":3}

If you verify it, then you could consider serde_json::value::RawValue to preserve the exact bytes Intel signed

[ameba23]

Very good catch. Yes i think you are right.

If this is the case, its an issue for dcap-qvl too because this was lifted from there. and also applies to QeIndentityResponse (below).

We can fix this here but probably should make an issue for dcap-qvl.

[MoeMahhouk]

ah, I think I oversaw something there. They do have this feature "preserve_order" enabled for serde_json in Cargo.toml. See here
This probably avoids such issue without dealing with rawbytes

[ameba23]

hmm yeah that would help a lot. but it still feels a bit brittle - there are other reasons why it might not serialize back to the exact same bytes. using RawValue feels a lot safer.

[MoeMahhouk]

indeed, it would be a safer approach to go with raw bytes but it would add code complexity to maintain. Also, if at some point the feature graph shifts in the future, it would potentially break.
However, since this repo is mainly relying on dcap-qvl dependency, it is not a big problem since the feature preserve_order would be pulled transitively for the whole repo.
cargo tree -p pccs -e features --prefix depth | grep serde_json