Because, semantically, an authorization "represents a server's
authorization for an account to represent an identifier". It's very unclear
what it means for a server to be "authorized to represent" {type: "dns",
value: "example.com", status: "valid"} and simultaneously not authorized to
represent {type: "dns", value: "example.com", status: "pending"} at the
same time.But more critically, because the IANA Registry of ACME Validation Methods <https://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods> binds each validation method to an Identifier *type*. It would be a very bad security vulnerability to register the "rats-01" challenge as being able to validate Identifiers of type "dns" -- clearly, these methods aren't even designed to actually demonstrate control over a dns identifier. So the rats-01 methods will need to be registered to a different identifier type anyway, for separation of concerns. Aaron On Thu, Jul 24, 2025 at 8:24 AM Q Misell <[email protected]> wrote: > > 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]
