Inline…
From: Mike Ounsworth <[email protected]> Date: Saturday, September 20, 2025 at 4:08 PM To: Carl Wallace <[email protected]> Cc: Michael Richardson <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Subject: Re: [Acme] Re: [Rats] about the four (+?) different LAMPS/ACME documents involving certificates and attestation Ugg. Words. The data formats are perfectly RATSy; what I mean is that using them simply for the purpose of extracting an identifier is not particularly RATSy. [CW] I guess I disagree on this. There are a variety of identifiers in EAT, which is as RATSy as it gets (and I think the attestations play a role beyond just serving up identifiers). However, I’m not sure pondering these demarcations between the specs is particularly useful and, given the some of the same formats referenced in device-attest could be used with csr-attestation, it may just highlight that part of the fragmentation stems from CBOR vs DER. Nobody needs that debate again. Regarding this point from the original note: TL;DR> no overlap between them. Reasonable to mix and match. [CW] I don’t think the front part of this is true (and I’m also doubtful the words on acme-client are altogether right). There’s bound to be overlap between device-attest, acme-client and csr-attestation and that’s OK (I’m not familiar yet with draft-liu-acme-rats, so not sure offhand if there’s overlap with it or not). Format reuse has already been noted. Additionally, one shop might use acme-client to get a code-signing cert and another shop might use csr-attestation. This is an artifact of the multitude of certificate request protocols and is not likely something that we’re going to fix here. On Sat, 20 Sept 2025 at 15:06, Carl Wallace <[email protected]> wrote: One question inline… From: Mike Ounsworth <[email protected]> Date: Saturday, September 20, 2025 at 3:55 PM To: Michael Richardson <[email protected]> Cc: <[email protected]>, <[email protected]>, <[email protected]> Subject: [Acme] Re: [Rats] about the four (+?) different LAMPS/ACME documents involving certificates and attestation +1 Good writeup MCR. I agree with your assessments. In particular, I agree that both draft-acme-device-attest and draft-acme-client both make use of WebAuthn, which is ... I guess ... attestation, but they are using at as a form of authentication; device auth in the case of draft-device-attest, and human auth in the case of draft-acme-client ... neither of them is *really* doing anything RATSy, which would involve for example taking a posture assessment of the device from which the request originated. [CW] What makes the attestation formats referenced by device-attest any less “RATSy” than, for example, statement formats that may be used with csr-attestation? See https://www.w3.org/TR/webauthn-2/#sctn-attstn-fmt-ids. On Thu, 18 Sept 2025 at 16:56, Michael Richardson <[email protected]> wrote: Let me write this up, since I've been through a few iterations of explaining this. I would welcome edits and clarifications, but note that there are definitely details that I have omitted for purposes of clarity. The documents I know about: 1. draft-ietf-lamps-csr-attestation. (in LAMPS) 2. draft-acme-device-attest (adopted in ACME, despite wrong name) 3. draft-liu-acme-rats-latest (yet to be adopted in ACME) 4. draft-ietf-acme-client (adopted in ACME) TL;DR> no overlap between them. Reasonable to mix and match. To understand things best, consider a system that has a TCG TPM 2.0 device attached. There are some places that a private key can be stored: in the TPM, or in a file on the system disk. (Note that private keys can be "sealed" by the TPM, which means that the private key is symmetrically encrypted by a key that only the TPM knows. Such a key is effectively in the TPM, since they can never be used when outside) **draft-ietf-lamps-csr-attestation** This document is about providing Evidence/Attestation Result about the location of the private key. A CA wants proof as to where the private key is. The certificate signing policy of the CA to sign certain kinds of keys requires that the key be stored in a place with particular security properties. Evidence: The Evidence is included *within* the Certificate Signing Request, and then via background check, Verified, producing Attestation Results. This mechanism can be used with any enrollment protocol: ACME, SCEP, EST, CMP... anything that uses CSR. Certificate: The Attestation Results will not typically affect anything that goes into the resulting certificate. **draft-acme-device-attest** This document is about authorizing an identity relating to a TPM, or equivalent TEE, such as Android Keystore or ChromeBook. The identity in question is the permanent-identifyer/hardware-module, and includes hwType and hwSerialNum. This allows authorization by leveraging keys built in the TPM during manufacturing time. Evidence: A challenge nonce is provided, and the client uses the credential in their hardware to sign a WebAuthn statement. This credential is used as the AccountKey, and this can connect to an Enterprise based directory. Certificate: The hwType/hwSerialNum can be included into resulting certificate as an otherName SAN. Note that the private key associated with the certificate has no set relationship to the TPM/TEE. It could be the same, it could be entirely different, and *this* extension says nothing about that key. **draft-liu-acme-rats** This document is about authorizing issuing of a certificate based upon an evaluation of the trustworthiness of the system making the request. While it now uses (I-D not yet updated) a pseudo-identity with ACME, the resulting Certificate never has a related identity in it. Evidence: A challenge nonce is provided, a passport mechanism is used to get fresh Attestation Results, which are then returned to the ACME server in the Authorization Response. Certificate: No identity that goes into the certificate is defended. **draft-ietf-acme-client** This document offers OTP (HOTP, TOTP, OTP), public key and WebauthN authorizations. While the document presents these as challenges, it is not clear to me how that is correct. It seems to me that this is an account authentication in the guise of an account. Evidence: The HOTP and TOTP mechanisms are not challenge/response systems. A new password is generated every 30s (TOTP), or when a key is pressed (HOTP). Validation of the result value requires that the ACME Server has access to the per-user secret. Or to a validation service that has access to it. RADIUS (User-Password) or DIAMETER or another service could be used. Cerificate: No identity that goes into the certificate is defended. ------------- Could one use all four at the same time? Yes. Assume a new-hire to an Enterprise. The new employee has been issued with a corporate device (phone or laptop), and a TOTP physical device (which might be the phone, or a token with biometric activation) 1. draft-ietf-acme-client could be used to authenticate the ACME account (if rewritten), or an ephermal account used with the challenge mechanism described used. This authenticates the new employee. 2. draft-lui-acme-rats is used to provide evidence that the device itself is running appropriate ("golden") versions of software; that it's malware free. 3. draft-acme-device-attest is used to connect the certificate is going to be issued to the device itself. This provides evidence that the credential is on the device that the Enterprise expected to deploy to. Alternatively, in a BYOD situation, a TOFU step results. Certificate renew then can be locked to that device. This could mitigate physical attacks/threats on the *person* itself ("gun to the head") where they are compelled to load a credential into an attackers device. 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. 5. RFC8823. An email-reply-00 challenge provides proof of control of an email account, and results in a certificate with a SubjectAltName rfc822Name for that email address. ps: I think that draft-ietf-acme-client needs significant revision. I don't think it's about client-certificates, in the same sense that DANCE thinks about them. It's about authenticating human-shaped things. pps: I would not use the word "attest" with draft-acme-device-attest. To me, this is a form of device authentication, with optional authentication of the HardwareModule otherName contents. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ RATS mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
