[Last-Call] Re: draft-ietf-lamps-csr-attestation-29 ietf last call Secdir review

[Shivan Kaul Sahib <[e-mail]>]

Hi Hannes,

On Mon, Oct 19, 2026 at 7:36 PM Hannes Tschofenig <[e-mail]>
wrote:

> Hi Shivan,
>
> Thank you for your review. Very helpful comments.
>
> We initially missed your review because it only showed up on the
> datatracker and was not distributed as email to the list. Sorry about
> the delay in responding.
>

Ah strange, I just used the Datatracker system I always use for submitting
SECDIR comments. Not sure why this email didn't go through.

>
> In any case, we have addressed your feedback in version -30 of the draft:
>
> - Cryptographic binding: Sections 4.1 and 6.1 now clarify the required
> security properties of the binding between the attestation and the CSR's
> public key.


> - Missing key attestation: Section 6.1 now talks about the concept of
> key attestation and what it means in the context of the attested CSR
> specification. Whether to reject the CSR without key attestation depends
> on the CA's issuance policy. Note that there is also ongoing work on
> this topic in the RATS working group.
>
> - Privacy: We added a dedicated Privacy Considerations section covering
> device identification, linkability across enrollment requests,
> disclosure to external Verifiers, and possible mitigations. Note that we
> have also written a dedicated draft on this topic since it deserves more
> attention. The content in this draft does, however, give the reader
> useful guidance. You can find the separate draft here:
> https://datatracker.ietf.org/doc/draft-ounsworth-rats-privacy-framework/
>
> - Resource exhaustion: We added text to the security consideration
> section recommending limits on bundle sizes, the number of attestations
> and certificates, processing effort, and external verification requests.
>
> The latest draft version is available at:
> https://www.ietf.org/archive/id/draft-ietf-lamps-csr-attestation-31.html


Thanks! This all resolves my concerns.

>
>
> Ciao
> Hannes
>
> Am 14.10.2026 um 21:50 schrieb Shivan Sahib via Datatracker:
> > 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.
> >
> >
>