What are "attestations"

[dthaler]

Originally raised by Henk during IETF 115 meeting:
Section 4.3.3 has

4 -- Certificate Issuance:
Certification Authorities (CA's) may require attestations prior to the issuance of certificates related to keypairs hosted at the entity. An EAT may be used as part of the certificate signing request (CSR)."

(note "attestations" in that text)

I suspect above means "Attestation Results" instead of "attestations"

[gmandyam]

I suspect above means "Attestation Results" instead of "attestations"

No. In this case, CA is the relying party. Moreover, CA can be a verifier if the FIDO definition of RP operations is assumed: https://www.w3.org/TR/webauthn-2/#sctn-rp-operations. This was the definition I assumed when writing this text. As can be seen, neither the term "attestation evidence" nor "attestation results" appears in the FIDO document.

For whatever reason, the RATS Architecture document states that an RP can only consume attestation results and not evidence: https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-4.1.

Given that the FIDO/Webauthn specification preceded RATS Architecture by several years (and also had demonstrable "running code" well before the RATS WG was even chartered), I think that there should have been a detailed discussion in the RATS Arch. document contrasting this new definition of Relying Party role with the previous one, and a full justification as to why the RATS definition of roles should supersede the FIDO definition.

The PR in #338 appears to align with RATS arch. Please review.

[henkbirkholz]

The roles (and thereby the duties) of Verifier and Relying Party can be composed in a single entity. My assumption is, that in FIDO the Relying Party is a composite of RATS Verifier and RATS Relying Party. Does that sound feasible? The RATS architecture does not intentionally "supersedes" anything, I think. The RATS architecture enables:

1. a mapping to existing remote attestation mechanisms (be it stronger/augmented web authentication, TCG remote attestation, or TEE remote attestation)
2. a way to map and integrate remote attestation into existing Internet protocols (originating from IETF or elsewhere)

I am a bit surprised by the timing of this issue, as the RATS architecture was extensively discussed over the years, in some years via well-announced, continuous weekly meetings.

[gmandyam]

My assumption is, that in FIDO the Relying Party is a composite of RATS Verifier and RATS Relying Party. Does that sound feasible? The RATS architecture does not intentionally "supersedes" anything.

For an independent reader, it sure seems that the RATS architecture is intended to be authoritative - there is no text in the Architecture document that even acknowledges the prior FIDO definition (outside of a passing reference to the Webauthn specification). At very least I assume we agree that both definitions are equally valid in light of the EAT specification.

I am a bit surprised by the timing of this issue

By "this issue" I am assuming you are referring to #337. I agree - this issue should not have been filed.

[henkbirkholz]

By "this issue" I am assuming you are referring to #337. I agree - this issue should not have been filed.

Ha! 😊 No, I was referring to your post-merge comment. Also, I did not write that it is not authoritative, I highlighted how it does not conflict, but rather provides the flexibility to map different approaches.

There are different sets of requirements on remote attestation in different contexts. And FIDO authentication has a different focus than, for example, TCG remote attestation. For example, for quite some while Global Platform provides approaches how to combine FIDO authentication with their approach of evidence production, which aligns with RATS. Another example is the CCC (Confidential Computing Consortium) that shows how to unify remote attestation across different HW-specific embodiments based on RATS.

FIDO actually provides one of the use-cases RATS is based on (https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#name-fido-biometric-authenticati). Calling that "a passing reference" reads like a bit of an exaggeration to me, tbh. The RATS architecture does neither dismiss or supersede FIDO/WebAuthN approaches. It provides generic terminology and a framework to relate and combine different approaches, so stakeholders with different sets of requirements (and different terminology used) can relate and combine work better - that is where the RATS architecture can be called authoritative, I think.

[gmandyam]

By "this issue" I am assuming you are referring to #337. I agree - this issue should not have been filed.

Ha! 😊 No, I was referring to your post-merge comment. Also, I did not write that it is not authoritative, I highlighted how it does not conflict, but rather provides the flexibility to map different approaches.

I was actually serious - this issue should not have been filed. Go back to the original statement in the issue: 'I suspect above means "Attestation Results" instead of "attestations"'. I've already established that the original text was written with regards to the FIDO definition of RP operations, which does not distinguish between Attestation and Attestation Results. Since we agree that the FIDO definitions and architecture are not superseded in any way by the RATS Architecture document, then #337 is not valid.

FIDO actually provides one of the use-cases RATS is based on (https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#name-fido-biometric-authenticati). Calling that "a passing reference" reads like a bit of an exaggeration to me, tbh.

Then why is Sec. 4.1 of the arch. document not consistent with the FIDO definition of RP operations? Why is there not even mention of how the FIDO definition differs in this section.

I suggest taking this discussion over to ietf-rats-wg/architecture#440.