I gave the draft a quick skim. I realize it is understood that much work remains but wanted to point out a few terminology issues and perhaps some gaps in the specs that might underpin this mechanism.
1) That you have different challenge types to sustain the passport model and the background check model is good, but I think at present there is some confusion about the passport model. Section 3.1 suggests the "entire EAT" is provided in support of passport model operations. This is inconsistent with section 5.1 of RFC9334 (assuming the ACME server is playing the role of Relying Party). 2) Section 3.1 suggests that EATs must be presented in JWT format. In my opinion, this is not an election a specification like this can make. EATS may be JWTs or CWTs (and there are other formats it may make sense to consider here as well for completeness which dovetails into Mike’s comment). 3) Throughout (or at least in some cases) I think the term "attestationResult" is being used to mean "evidence." If attestation result is actually meant, there will need to be a reference to an attestation result format. I’m not sure anything suitable exists at present. 4) Section 3.2 suggests that evidence will be generated to include the "token" claim. I tend to doubt all attesting environments will be so flexible as to support introduction of arbitrary claims. Deciding how to address this should probably follow deciding what RATS role the ACME server is playing in each challenge scenario. It may be that requesting a nonce and using a nonce claim is the right thing here (leaving token to serve its original purpose only). From: "Liuchunchi(Peter)" <liuchunchi=40huawei....@dmarc.ietf.org> Date: Wednesday, October 23, 2024 at 3:22 AM To: "acme@ietf.org" <acme@ietf.org> Cc: "acme-cha...@ietf.org" <acme-cha...@ietf.org> Subject: [Acme] new acme draft -- rats identifier and challenge Hi folks, Recently I submitted a new ACME draft that extends “rats” identifier and challenge type. The purpose of this work is to provide a means that allows an ACME server to test if an ACME client possess a valid remote attestation result (and an identifier to that), before issuing a certificate to it. Wonder if anyone may find this work interesting? The draft is here https://datatracker.ietf.org/doc/draft-liu-acme-rats/ and github repo is here https://github.com/liuchunchi/draft-liu-acme-rats, with some todos that welcomes contribution or comments. Dear chairs, can I request a small slot in Dublin to share this work? 15 or 10 minutes would suffice. Best, Peter (Chunchi) Liu _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
