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.
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]
