[Rats] Re: Submission of Trustworthy Acquisition of Credentials using Remote Attestation (TACRA) draft

[Serhii Nikolaichuk <[e-mail]>]

Mark, Henk, Michael,

Thank you for TACRA. I read -00, and since you asked for feedback on the
binding and on architecture boundaries, here is a contribution from
measurement rather than opinion, with the artifacts public so anyone can
re-run.

1. CSR/CEK-to-Evidence binding (Sections 4.4, 5.2, 5.3, the "TBD").
A concrete construction that verifies end to end: put
SHA-512(freshness || CSR) in the attestation freshness field
(REPORT_DATA on SEV-SNP) and have the Credential Authority recompute it.
I ran the enrollment case on a Google SEV-SNP guest: the guest generates
the CSK and CSR, takes a present-nonce, binds
REPORT_DATA = SHA-512(nonce || CSR), and returns a VCEK-signed report;
the CA recomputes the binding, verifies the report and its VCEK chain to
ARK-Milan, and verifies the CSR's proof of possession, then issues.
Retrieval is the same shape with SHA-512(freshness || CEKpub). Worked
example and verifier are in the repository below, under tacra/.

2. That binding is to a genuine TEE and to the freshness handle, not to
the CAS channel. Since the CAS is an untrusted conduit (Section 7.2) and
relay is not yet discussed, a relay can sit between the Attester and the
Credential Authority while every check above still passes: binding a
public key, with or without a nonce, does not correlate the Evidence
with the session, per the public analysis of binder mechanisms
(Identity Crisis in Confidential Computing, ASIA CCS 2026;
Intra-handshake.fail, CVE-2026-33697). The remedy is cheap: also fold a
value derived from the CAS transport's shared secret, the RFC 9266 TLS
exporter, into the freshness field, and say so in Security
Considerations.

3. Architecture boundaries (Section 4). "Include CSKpub in Evidence" is
not uniform across platforms, which the CAI plug-ins need to account
for. Measured across the public clouds:

- Google SEV-SNP / Intel TDX and AWS Nitro: the guest writes its own
value into the report, so CSKpub goes in directly.
- AWS SEV-SNP shared tenancy: the guest can write REPORT_DATA, but the
report is VLEK-signed with CHIP_ID zeroed, so the Evidence names no
machine; a credential there rests on the provider's key domain, not
a chip.
- Azure SEV-SNP: the paravisor owns REPORT_DATA (it binds a
runtime-data hash at boot), so CSKpub has to travel through the
paravisor's vTPM quote, not the SNP report.

So the binding step needs three shapes: direct-in-report,
provider-scoped, and vTPM-mediated.

All of this is measured and reproducible; the reports, certificates,
probe and verifier are in the repository [1], under tacra/. Happy to
turn any of it into text for the draft.

Serhii Nikolaichuk
Austin, Texas

[1]
https://www.google.com/url?q=https://github.com/nikolaichuk7/geoar-verifier&source=gmail&ust=1789339961306000&sa=E

On Fri, Sep 11, 2026 01:18 PM, Mark Novak <[e-mail]> wrote:

> Hello RATS WG,
> Ahead of our interim meeting next Monday, I submitted the TACRA draft for
> consideration by the RATS working group.
> Draft: Trustworthy Acquisition of Credentials using Remote Attestation
> (TACRA)
> Revision: 00 (Sep 11, 2026)
> This draft describes a credential acquisition architecture for remote
> attestation and workload identity, allowing any workload to acquire any
> credential type using any protocol. The document is intended to support
> discussion within the WG on design goals, architecture, and protocol
> integration points.
> The draft is available at:
>
>    - Datatracker: https://datatracker.ietf.org/doc/draft-novak-rats-tacra/
>    - GitHub / source: https://github.com/TheBankster/rats-tacra/
>
> We would welcome review and comments from the WG, especially on:
>
>    - design goals and architecture boundaries
>    - the role of the Credential Acquisition System as a conduit
>    - interaction between the Attester and the CAS
>    - compatibility with existing credential acquisition mechanisms
>
> Thank you, and we look forward to feedback from the WG.
> Best regards,
> Mark Novak / Henk Birkholz / Michael Richardson
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>