> 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]
