Hi Peter! Thanks for your submission to the ACME working group. I'll start by admitting I don't really have much background knowledge on RATS so my comments may be mis-informed. Feel free to tell me I got it wrong.
I think your draft is a good start - but needs a lot of work. First, some editorial nits: - BCP14 isn't referenced, nor is BCP14 language used - this is required for all proposed standards - draft-moriarty-rats-posture-assessment has been replaced by draft-ietf-rats-posture-assessment Nowhere in the draft does it appear to define what a RATS identifier is (it merely says "The identifier itself"). This at the very least requires a normative reference to the construction of a RATS identifier. In section 3.1, simply echoing back the token to the server over the same channel provides nothing cryptographically - perhaps you intended to bind this token somehow? "attestationResult" also needs a definition or a normative reference. You also have an inconsistency between section 2 and section 3, is the challenge "rats" or "rats-01"? I am very confused by the HTTP challenge type and how it applies to RATS. Your draft states "The Client provisions the keyAuthorization string in the resource path defined in the original http-01 challenge -- /.well-known/acme-challenge/" but this is impossible. A RATS identifier is not a DNS identifier, so there is nowhere for this to be provisioned where the CA can bind to it. What was your intent with this section? It's also unclear to me what kind of certificate will be issued by a CA in response to a RATS order request. Your example use case section is a little vague and could do with a more thorough step-by-step of the expected way in this draft is used (non normatively). Finally, your draft states that it has no IANA actions, in spite of defining IANA actions. I would expect a request to IANA to assign the "rats" identifier type and the "rats-01" challenge type. I look forward to your revisions to this draft and further involvement in the ACME working group! Q Misell ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Wed, 23 Oct 2024 at 09:22, Liuchunchi(Peter) <liuchunchi= 40huawei....@dmarc.ietf.org> wrote: > 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
