[Rats] about the four (+?) different LAMPS/ACME documents involving certificates and attestation

[Michael Richardson <[e-mail]>]

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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide