Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 4748E46 for ; Sun, 25 Oct 2026 13:40:58 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=KVc23JJr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx.ietf.org: domain of shivankaul.1993@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=shivankaul.1993@gmail.com; arc=pass ("google.com:s=arc-20260327:i=1") Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-91bb5795792so27326926d6.2 for ; Sun, 25 Oct 2026 06:40:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1792935658; cv=none; d=google.com; s=arc-20260327; b=TWPDoZUm880SRpcNp71vW9JKCLK9q1e+hB9kEwIJug2ySRVdlCavtKpyMMwVU//UMa 9eLHLqJdJ3G6U+eaJVBqMJcCt9wjsmCDS0yJpOZZuQlGXpQ/21gLJqZMk8A1KXwFdGtq Fh3Q9xtv7TV99cPWFT4Wzc8uv0ze/+XkF2cFWHnZlCQ233OX2998/X75YtB4ZCtC3rUX 2gyzc/WDXf3TiDyWIuZJKlhlSjqF52enQS6WTDEVVJ6Io5kWBxCOSupVTqNPx3/5ZuZX ObJMeUD7XGrIhwILvkdiPLOLmgOt1VYxtSSz9qFr/rwUmdajBGxVb+E64uitRs9FEgKb 8yFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=QAGD9yDE7DoBLTxjIWUo5oHqSy0GVD6/kgz3+tKNQEI=; fh=/KnstMOg7MQ1mn7TlTclywqUl+9HKEgcbJclkNCqW84=; b=O9H/EehW+mGhm6caVf1FrUff4fQmq4qNbjRhBoeWEflMn7rsa4sSOcmamxZpdsh32n xk6EJ1C5+JamekYOIiuMoTVS/YupkZgsGar118+HWBeS7onf1GeuLbCnGMMBIv2om/RH lYn4ruzi+u8+xxce7+ANjG/eFBlMhv/qqcTJbpY4du8SwQJhwSPhjTuydABzB0HO/th/ 6f7ornjn4xtQkf8RkeBpSz3Jrq8shJWnLNfb5nCQ+ZVZ2KWDaRp0Ip6AG2xAR1mqjRTx mxvQGjl3kLkAlmPdBHvRlZUbgA+uIVW+nJUEUkClKYvBNpaGwA7rbxE3oH1ovDaVtZVF XDLw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792935658; x=1793540458; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=QAGD9yDE7DoBLTxjIWUo5oHqSy0GVD6/kgz3+tKNQEI=; b=KVc23JJr1eop8NlOY6U3pdYXt6CEe6Tod9CQ0VkkmoarF9szmo7TOStwfVVjdg/VCF AKpW1MaAKhjJ/uTBYO3LIXWywy1JD2jEiNG/45WF4+wxPZ8vtPpQ5N51+E7lMdAFUQpA LKdifTNx3MMWgPpvL3sIjerm1bOONMsRoVNGTj+VPaWx7aTWsIqSTudnVnCqhEGhhvC3 K19bjhw9hBbQENB3O9IvtzRaVrb8mP9Yv1D1A1Bo5sJvEkjWDDwFlamDkRBMDdmcS/fu wRSdvtqG1fxLCruxhe9X1esSFepLegmbVtXc/s3bV2Y/8NdKwXyL9S3ZeNW/T2eH5HCt Woiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792935658; x=1793540458; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=QAGD9yDE7DoBLTxjIWUo5oHqSy0GVD6/kgz3+tKNQEI=; b=Po+Ce/hrQn20xzngmmM/T/SOaTI0/QRDF/31w0S/m18p38zLCtsn8/pbc20dHofSqe CdvE2UN4T9TowsECsbPy6kv9nCJKjprT0Q2RhLElJq6zITAiJOAb+vsq8N9NThucI+LF 2jJ+VeAkFOgXaxNINfp8bcT8ZGSgyYcry6wdMchRwmlOKZrl7EpWXeXjB29C5/G3ZV3x di+a7ypCTnoJ/YmaXkXH2fdUjGVVMDXAwr1wlvaFu+92iVb16UEesrey1/0hWyK/JTyw k+LksPezA/ZR1iKLwM8fNxkpak3HMYn6oRCGBG28hECo7ykR+lMAIrZl7XV36RligeG0 j71g== X-Forwarded-Encrypted: i=1; AKwUvBxvT6MNlkx1G8ExSG4Tb09tJ7HchV5xYu0VOuCd5v1FMcQk8k4VLAtjYkz5a9HhlcGmfTiqw+G2Low=@ietf.org X-Gm-Message-State: AFq9FYJY87pTY6fA8CCgnBbFcVJYzAjUVvqph7oEeL9mS9g6QleYOqLR jYr2WjQM7SHBsfyIEvq6zyQvMUbljSbGjx7/k4zXVGcpRIHuAZ5YLiMVVE8DvANdNWx/BaErE4f tv0SiIKTaFwdcN2/TaVDWoInsP+c6O8g= X-Gm-Gg: AYBFou03T6PbhMVUw0Di4kGCx8CXJxGKlWV0kU9qAJSRKYVucdvULK0DKrjtxKxjjT0 kBPeP7Z3LjF4Vycbmbx3BHEJWrmP9fNTgJH7imIn8tcGXYNRRPlQlMlhAbok10RJMgF6nF7CMDZ dpKo+8nds8xv6XU53pguKRIW/0md+hH7KC+sWCgwAJTljbVij+F5QmWkv3RcOIX+R4zqugHn3My +2onFEHRpSuKE/Z7mr9gCLQ2UauaDdJaP2Ffxx4R7d+ylq3342G2Km88oBXVXs/nMx7bF3rlry9 Q2u0815mGl3mWqOVjdYoeTomgqI825NmYdyv9xmrUW2rOkWUVR3v0L3jUszkeE2yt1orW6LcU9j 5Sz2ElZULzFnZgEj6sd2wS/vGasJISTm2Z+U7H3HZ0azgQCdV0IgKSz7IgD5SNdT587eagBkdWQ edLTwcNeGPtvk89TCg7Unx+w== X-Received: by 2002:a05:6214:21a8:b0:917:aa8e:474f with SMTP id 6a1803df08f44-91c48e2f0b6mr67461916d6.23.1792935657735; Sun, 25 Oct 2026 06:40:57 -0700 (PDT) MIME-Version: 1.0 References: <178988456911.134298.4471353467542656841@dt-datatracker-fffdbdc97-wjd6q> <289f63fb-8781-4d5a-a639-c82b18662042@gmx.net> In-Reply-To: <289f63fb-8781-4d5a-a639-c82b18662042@gmx.net> From: Shivan Kaul Sahib Date: Sun, 25 Oct 2026 14:40:20 +0100 X-Gm-Features: AclHuK-MKBed5fvUSoPfHP5GGjvPDV58kKFg1xxnFrKJVJejVsbZvEeIf29kFTM Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary="000000000000fc08c9065eaa5c29" X-Spamd-Bar: ---------------- Message-ID-Hash: 4D2LIGXKH43O3E3KDY75UQ4XQY6DMJR4 X-Message-ID-Hash: 4D2LIGXKH43O3E3KDY75UQ4XQY6DMJR4 X-MailFrom: shivankaul.1993@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: secdir@ietf.org, draft-ietf-lamps-csr-attestation.all@ietf.org, last-call@ietf.org, spasm@ietf.org X-Mailman-Version: 3.3.10 Precedence: list Subject: [Last-Call] Re: draft-ietf-lamps-csr-attestation-29 ietf last call Secdir review List-Id: IETF Last Calls Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000fc08c9065eaa5c29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hannes, On Mon, Oct 19, 2026 at 7:36=E2=80=AFPM Hannes Tschofenig 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 attestation= s > > > > 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 o= f > 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 durin= g > > 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 unde= r > > "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 documen= t. > > > > 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. > > > > > --000000000000fc08c9065eaa5c29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,

On Mon, O= ct 19, 2026 at 7:36=E2=80=AFPM Hannes Tschofenig <hannes.tschofenig@gmx.net> 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 comment= s. Not sure why this email didn't go through.=C2=A0

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.=C2=A0

- 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 ch= anges are
> required. I have a few issues with the security and privacy guidance t= hat 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 bo= und" in sections
> 4.1 and 6.1. I don't think a binding mechanism needs to be prescri= bed, but the
> desired security property should be stated. AFAICT it isn't.
>
> 2. Clarify consequences of CSR not containing any key-bound attestatio= ns
>
> Section 4.1 says:
>
>> At least one element in the attestations field SHOULD contain an a= ttestation
> 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&#= 39;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 duri= ng
> enrollment. But only one exposure is mentioned: copying attestations i= nto 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 mult= iple 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 th= emselves
> 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 und= er
> "Additional Security Considerations" which doesn't do th= e 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 docume= nt.
>
> 4. Resource exhaustion discussion
>
> The document permits an unbounded number of attestations and certifica= tes, and
> processing these can involve parsing, verifications, and external requ= ests 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.
>
>
--000000000000fc08c9065eaa5c29--