Hi carl, thank you very much for the detailed feedback, indeed some clarification are needed. Please see inline
Peter From: Carl Wallace <c...@redhoundsoftware.com> Sent: Wednesday, October 23, 2024 11:32 PM To: Liuchunchi(Peter) <liuchun...@huawei.com>; acme@ietf.org Cc: acme-cha...@ietf.org Subject: Re: [Acme] new acme draft -- rats identifier and challenge 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). [CPL] please see response 3 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). [CPL]: Sorry for the confusion, it should be “for example” JWT, not restricting to only JWT 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. [CPL]: it is my humble understanding that EAT can be either used to encode evidence or attestation result. Maybe draft-ietf-rats-ar4si or draft-fv-rats-ear-03 is usable? 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). [CPL]: my humble understanding is this token can be used as a rats freshness-nonce (Section 10.2 from rfc9334), sent from RATS appraising entity to the attester. In this case, the ACME server is the RATS Relying Party I think. Could reusing “token” claim as rats nonce somehow cause some trouble, and send a separate nonce would be better? Thanks again for all the good comments and contribution is highly welcomed in our github page<https://github.com/liuchunchi/draft-liu-acme-rats> From: "Liuchunchi(Peter)" <liuchunchi=40huawei....@dmarc.ietf.org<mailto:liuchunchi=40huawei....@dmarc.ietf.org>> Date: Wednesday, October 23, 2024 at 3:22 AM To: "acme@ietf.org<mailto:acme@ietf.org>" <acme@ietf.org<mailto:acme@ietf.org>> Cc: "acme-cha...@ietf.org<mailto:acme-cha...@ietf.org>" <acme-cha...@ietf.org<mailto: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<mailto:acme@ietf.org> To unsubscribe send an email to acme-le...@ietf.org<mailto:acme-le...@ietf.org>
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
