> On Sep 22, 2025, at 11:13 AM, Michael Richardson <[email protected]> 
> wrote:
> 
> 
> Laurence Lundblade <[email protected]> wrote:
>> Not sure what precisely is meant by posture assessment, but I
>> don’t think attestation/RATS requires measurements at all. A
>> single evidence message that just identifies the device as made
>> and secured by some OEM is enough.
> 
> Yes.  We have a single authentication flow that asserts th device serial
> number.  

Right.

>  But, as every authentication flow is a potential remote attestation
> flow, I guess, every remote attestation flow can be degenerated to doing just
> authentication :-)

The thing for me is the key material. Who owns, how was it provisioned, what 
the life cycle and what is the policy around it. Attestation key material is 
really difference than server/TLS authentication key material which is really 
different end-user/client authentication.

I still think use of the word authentication without qualification is 
potentially confusing. I think you are using it in a generic way and it mostly 
means signing a nonce to prove who you are.


> My only problem with the nomenclature for acme-device-attest is that it will
> attract people looking for remote attestation, and fail to attract people who
> want device authentication.
> 
> Abstract says:
>  } This document specifies new identifiers and a challenge for the
>  } Automated Certificate Management Environment (ACME) protocol which
>  } allows validating the identity of a device using attestation.
> 
> and a clue should be the lack of the word **remote** before attestation.
> It's authentication, or even authorization, but not attestation.

I can’t tell where acme-device-attest is coming from / going to yet. They do 
seem to be deconstructing WebAuthN to get the attestation part out.

I don’t like the total lack of discussion of attestation key material.

I don’t know why they aren’t using EAT, or at least allowing it. It seems some 
of the fields they are defining might overlap with EAT.

Seems like they should do a lot more work to explain themselves (to us).


>> (FIDO needs device attestation because the user is no longer
>> presenting their authentication credential to the server. Instead
>> the user presents their credential (e.g. fingerprint) to the
>> device and the device authenticates to the server. The server
>> wants to know the device is a trusted intermediary. There’s no
>> measurement of the device in FIDO attestation).
> 
> Yes, there is no measurement of the state of the smartphone REE.
> There is an endorsement of the fingerprint scanning hardware as a trusted 
> intermediary.
> My understanding is that hardware, and the firmware that processes the
> fingerprint is part of some securely booted trusted execution environment.

FIDO certification allows for different levels of security, including fairly 
weak security. Security is orthogonal to the protocol. Of course, few are going 
to do fingerprint or much FIDO at all without fairly good security. But it’s an 
important distinction that the level of security is orthogonal to the protocol. 
EAT was very explicit about this.

LL

_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to