Non-deterministic PEM certificate chain order

[Nirusu]

https://github.com/intel/SGXDataCenterAttestationPrimitives/blob/c057b236790834cf7e547ebf90da91c53c7ed7f9/QuoteVerification/QVL/Src/AttestationLibrary/src/CertVerification/CertificateChain.cpp#L66-L87

Usually, most PEM certificate chains are defined to go:

• Leaf
• [Intermediate CA]
• Root CA

Even most of the sample files of the attestation app use the same order, with a few exceptions.

My question here is, why is the order indeterministic in the first place? As you can see from the code example above, it makes parsing more annoying.

Can I expect the Trusted Services API to always return a proper chain from Leaf -> Intermediate -> Root CA? Or is the order really "dunno, you need to check"?

And if it really is designed to be non-deterministic, why is that?

[hyjiang]

Actually we have fixed certificate order, if you check the detail in quote buffer, you will see the order would always same as you list above. The response from Intel(R) PCS is a little different, intermediate and Root certs are in response header. You can details from PCS official website.

But you will see that TCB info and QE identity don't have leaf cert, and we don't want to use different function to verify the cert chain. In addition, we never guarantee the cert older officially, so the code logic includes some additional logic.

[Nirusu]

Yeah, I was referring to the example files from the TCB signing example data here in this repository.

For example, this example certificate chain and its TDX equivalent have the order of the Root CA and the TCB signing certificate flipped.

I personally find that behaviour a bit weird. But given it's likely out there, support for arbitrary orders has to be there anyway I suppose.

Though it would be great if new(er) versions of the PCS API would also enforce a correct order.

Otherwise feel free to close the issue.

[jcape]

I would also love it if the contents of the PEM chain are well-specified. Technically, there's nothing preventing certs happening out of order, but there's also nothing to prevent multiple chains to different anchors in the same blob. In my case, the verification code was itself going into an enclave, so I ended up having to write very defensive manual certificate chain validation---code that wouldn't have been necessary if the spec was clear about what a "PEM chain" is going to look like.