>> 4. draft-ietf-lamps-csr-attestation provides assurance that the generated
>>private key is held in a secure enclave, from which it can not be exported.
>
>This is confusing. There is a jump from TPM to secure enclave. TPM is not a
>secure enclave.
>
I think the intent is to say that the private key is protected in some
meaningful way. Protection in software (which is to say it's in memory
(virtual, partitioned, paged) or storage (flash, HDD)) isn't good enough. There
are lots of ways to harden memory, storage, and execution. It would be
difficult to try to prescribe something in the draft. TPM and secure enclaves
maybe are exemplary at best. I believe the draft should not be prescriptive and
be policy agnostic. Nevertheless, it still needs to communicate the intent that
key protections are meaningful.
________________________________
From: Muhammad Usama Sardar <[email protected]>
Sent: Saturday, September 20, 2025 2:42 PM
To: Michael Richardson <[email protected]>; [email protected] <[email protected]>
Cc: [email protected] <[email protected]>; [email protected] <[email protected]>
Subject: [Rats] Re: about the four (+?) different LAMPS/ACME documents
involving certificates and attestation
On 18.09.25 23:56, Michael Richardson wrote:
**draft-ietf-lamps-csr-attestation**
Evidence: The Evidence is included *within* the Certificate Signing Request,
and then
via background check, Verified, producing Attestation Results.
Is there a commercial/public CA which actually supports this?
4. draft-ietf-lamps-csr-attestation provides assurance that the generated
private key is held in a secure enclave, from which it can not be exported.
This is confusing. There is a jump from TPM to secure enclave. TPM is not a
secure enclave.
-Usama
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
