Hi Mike, I can see it reasonably covers both cases. Very happy to work together and discuss more. I will be there since weekend hackathon. See you there or if not, then in the sessions.
Hi Misell, you brought up great questions, some are actually raised in the issues page<https://github.com/liuchunchi/draft-liu-acme-rats/issues>. Happy to accept your suggestions and discuss more if you will be in Dublin. See responses inline. Peter From: Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org> Sent: Wednesday, October 23, 2024 10:06 PM To: Q Misell <q...@as207960.net>; Liuchunchi(Peter) <liuchun...@huawei.com>; Thomas Fossati <tho.i...@gmail.com> Cc: acme@ietf.org; acme-cha...@ietf.org Subject: RE: [EXTERNAL] [Acme] Re: new acme draft -- rats identifier and challenge Hi Peter. I have not reach your draft yet (too-many-draft-overload syndrome). But @Thomas Fossati<mailto:tho.i...@gmail.com> and I talked at the last IETF meeting about submitting a draft that extends draft-bweeks-acme-device-attest-00 to be more generic by supporting generic CMWs in a similar way to the way that draft-ietf-lamps-csr-attestation does it. Obviously, we have not managed to submit this draft, so maybe we could join forces and make sure that your draft covers our use-cases as well? Will you be in Dublin? --- Mike Ounsworth From: Q Misell <q=40as207960....@dmarc.ietf.org<mailto:q=40as207960....@dmarc.ietf.org>> Sent: Wednesday, October 23, 2024 8:57 AM To: Liuchunchi(Peter) <liuchunchi=40huawei....@dmarc.ietf.org<mailto:liuchunchi=40huawei....@dmarc.ietf.org>> Cc: acme@ietf.org<mailto:acme@ietf.org>; acme-cha...@ietf.org<mailto:acme-cha...@ietf.org> Subject: [EXTERNAL] [Acme] Re: new acme draft -- rats identifier and challenge 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 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. [CPL]: left that on purpose-- it depends on what does rats identifier represent— an attester identity (a perm-identifier), or just an attestation result (hash of it for example). My personal inclination is the latter but I agree the former is also important. 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? [CPL] thumbs up – maybe putting the response inside of payload of a proper JWS object is better? This is what draft-bweeks-acme-device-attest did. "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"? [CPL] so, rats-01 and rats-02 makes up 2 kinds of “rats”. The former and latter corresponds to the 2 models (passport and background check) of RATS. My bad for not making it very clear 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. [CPL] right, it may not be a good idea. 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://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!d7xvk0ms4WWy2Vsg5HG3Ra2cIEbJJQqmK3h-EzD5g510yOxA_UAcYxTq6hR7DpjJSrgU2McLeZAk8NkWzdURkEjjUItUYy9nnqao$>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!d7xvk0ms4WWy2Vsg5HG3Ra2cIEbJJQqmK3h-EzD5g510yOxA_UAcYxTq6hR7DpjJSrgU2McLeZAk8NkWzdURkEjjUItUYz4-p2Ax$>. 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<mailto: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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-liu-acme-rats/__;!!FJ-Y8qCqXTj2!d7xvk0ms4WWy2Vsg5HG3Ra2cIEbJJQqmK3h-EzD5g510yOxA_UAcYxTq6hR7DpjJSrgU2McLeZAk8NkWzdURkEjjUItUY7t6GW6s$> and github repo is here https://github.com/liuchunchi/draft-liu-acme-rats<https://urldefense.com/v3/__https:/github.com/liuchunchi/draft-liu-acme-rats__;!!FJ-Y8qCqXTj2!d7xvk0ms4WWy2Vsg5HG3Ra2cIEbJJQqmK3h-EzD5g510yOxA_UAcYxTq6hR7DpjJSrgU2McLeZAk8NkWzdURkEjjUItUYy5oxmeP$>, 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
