> I don't think there should be two Authorizations with the *exact* same Identifier in the order.
Why so, I'm curious? ------------------------------ 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. Ar Iau, 24 Gorff 2025 am 17:10 Aaron Gable <[email protected]> ysgrifennodd: > > So multiple Authorization objects, not additional challenges within a > single Authorization. > > Yep, I agree with Q, this is the way. > > I don't think there should be two Authorizations with the *exact* same > Identifier in the order. But because Identifiers have types, there easily > could be this set of Authorizations: > - {identifier: {type: "dns", value: "example.com"}, challenges: [{type: > "http-01", url: "..."}, {type: "dns-01", url: "..."}]}, and > - {identifier: {type: "rats", value: "example.com"}, challenges: [{type: > "rats-01", url: "..."}, {type: "rats-02", url: "..."}]} > or (as I've been suggesting above) > - {identifier: {type: "dns", value: "example.com"}, challenges: [{type: > "http-01", url: "..."}, {type: "dns-01", url: "..."}]}, and > - {identifier: {type: "rats", value: "OID 1.2.3.4.5"}, challenges: [{type: > "rats-01", url: "..."}, {type: "rats-02", url: "..."}]} > > Aaron > > On Thu, Jul 24, 2025 at 7:26 AM Q Misell <[email protected]> wrote: > >> > So multiple Authorization objects, not additional challenges within a >> single Authorization. >> >> I see this as the way forward too. An authorization needs an identifier, >> but I don't see an issue with multiple auths in the same order with the >> same identifier. >> That is, two auths for example.com, one with http-01, one with rats-01. >> ------------------------------ >> >> 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. >> >> >> Ar Iau, 24 Gorff 2025 am 15:32 Michael Richardson <[email protected]> >> ysgrifennodd: >> >>> >>> Aaron Gable <[email protected]> wrote: >>> >> *ONE* of the challenges. But more than one challenge needs to be >>> >> done. >>> >>> > I don't understand why this is true. Maybe this is because I don't >>> > fully understand how RATS attestations work. >>> >>> > My understanding is that the server has some set of things that it >>> > wants the client to prove, e.g. that the client's OS is up to >>> date, and >>> > it is in FIPS mode, and that the key lives in a TPM. >>> >>> You have it right. >>> >>> > My reading of RFC 9334 suggests that a Remote Attestation Result >>> can >>> > contain any number of claims. If that is true, then all the claims >>> the >>> > server wants to see can be satisfied by a single challenge. If >>> that is >>> >>> Yes. >>> And then how/when does the client prove that they own example.com? >>> >>> > not true, then what is stopping the server from creating multiple >>> > Authorization objects, each with one claim that the client needs to >>> > prove? In either case, each Authorization will be fulfilled by >>> exactly >>> > one challenge. No need for multiple challenges to be completed. >>> >>> So multiple Authorization objects, not additional challenges within a >>> single >>> Authorization. >>> >>> >>> >>> >>> -- >>> Michael Richardson <[email protected]>, Sandelman Software Works >>> -= IPv6 IoT consulting =- *I*LIKE*TRAINS* >>> >>> >>> >>> _______________________________________________ >>> Acme mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
