[secdir] draft-ietf-lamps-csr-attestation-29 ietf last call Secdir review

[Shivan Sahib via Datatracker <[e-mail]>]

Document: draft-ietf-lamps-csr-attestation
Title: Use of Remote Attestation with Certification Signing Requests
Reviewer: Shivan Sahib
Review result: Has Issues

This document defines an ASN.1 structure for carrying one (or more)
attestations in certificate signing requests.

I found no major security issues and I don't think any protocol changes are
required. I have a few issues with the security and privacy guidance that I
think should be addressed before publication, though.

1. Clarify the required property of the cryptographic binding

It's not clear what exactly is meant by "cryptographically bound" in sections
4.1 and 6.1. I don't think a binding mechanism needs to be prescribed, but the
desired security property should be stated. AFAICT it isn't.

2. Clarify consequences of CSR not containing any key-bound attestations

Section 4.1 says:

> At least one element in the attestations field SHOULD contain an attestation
that is cryptographically bound to the public key that is the subject of the
CSR containing the AttestationBundle.

What happens if that SHOULD is not followed? Is that up to the CA (I'm guessing
yes)? If yes, then can we say as such? Could be a pointer to Section 6, perhaps.

3. Add privacy considerations

The document exists to carry sensitive, hardware-identifying data during
enrollment. But only one exposure is mentioned: copying attestations into the
published cert.

Linkability is a concern I'm thinking of: attestation formats can use stable
device-identifying keys and certificates. These can let a CA link multiple CSRs
as coming from the same device, even if the CSR key, subject name, or account
changes. This linkability exists even when the attestation contents themselves
are not sensitive. CAs can also relay these requests to third-parties,
according to the draft.

I do see the security reference to other RFCs but these are buried under
"Additional Security Considerations" which doesn't do the concerns justice. Not
saying that we need to repeat all the concerns here, but we should at least
mention them before pointing to a fuller discussion elsewhere.

Ideally there would be a Privacy Considerations section in this document.

4. Resource exhaustion discussion

The document permits an unbounded number of attestations and certificates, and
processing these can involve parsing, verifications, and external requests to
Verifiers. Since certification requests are untrusted input, it may be worth
noting that implementations should impose appropriate limits on bundle size,
counts, and verification effort.