Laat me hier in de details duiken. Hier is een realistisch beeld van wat ik echt bedoelde toen ik zei dat de verificatie **last** is verschoven. Context: In moderne SGX/TDX TEE-protocollen, stuurt de PROVER: + attestatiebewijs (quote/rapport) + verificatiecollateraal dat nodig is om het te valideren OF De protocollen vertrouwen op een derde partij en NIET Intel als bron van waarheid voor hun collateraal. Nu is het feit dat de prover zelf de materialen die nodig zijn voor verificatie (collateraal) naar de verifier stuurt OF dat een derde partij kritische besluitvormingsartefacten levert, NIET zo problematisch als het op het eerste gezicht lijkt. Maar we moeten door wat modder waden om dit goed te krijgen. Laat me je vertellen waarom. Deze ontwerpkeuze is grotendeels een afweging tussen praktische haalbaarheid en beschikbaarheid. Veel verifiers WILLEN NIET afhankelijk zijn van live Intel-netwerkoproepen bij elke handshake. Eerlijk. Dus welke ontwerpkeuzes richten mensen zich meestal op: 1. Verifier haalt rechtstreeks van Intel PCS om de PCK-certificaatketen, PCK CRL's, TCBInfo, QEIdentity, enz. op te halen. Goed: Versheid stonk, Rollbackrisico is verwaarloosbaar Slecht: Verifier heeft uitgaande netwerk + Intel beschikbaarheids-/latentieproblemen nodig 2. Verifier haalt op uit een vertrouwde cache (PCCS) Hier hebben we een Provisioning Certificate Caching Service die synchroniseert met Intel PCS en wordt beschouwd als de bron van waarheid voor verifiers (in plaats van Intel)...