Hi Mike, Brandon,
On Wed, 24 Jul 2024 at 23:10, Mike Ounsworth
<Mike.Ounsworth=40entrust....@dmarc.ietf.org> wrote:
>
> Hi Brandon,
>
> So, you are registering the challenge “device-attest-01”, but your draft is
> very specific to WebAuthn, and excludes any other attestation technology.
>
> Request: could you either rename your draft to “webauthn-attest-01”
I support this.
> or if you’re willing to broaden the scope of your draft, then I think the
> obvious way would be to add a “type” field to POST /acme/chall :
>
> "payload": base64url({“type”: “webauthn”,
> "attObj": base64url(/* WebAuthn attestation object */),
>
> … then continue your WebAuthn draft as you are.
>
> At least then it would be extensible to accept other attestation evidence
> formats in the future – we’d have to debate whether we need a new registry
> for those “type” values; or whether there already exists a suitable registry
> that we could piggy-back on.
Re: Extensibility. Note that CMW [1] has been designed precisely to
support situations like this, i.e., where the RATS "relying party" (in
this case, the ACME server) need not know the details about the
specific attestation evidence format and blindly forwards it to the
attestation verifier to get a yes/no answer. An OID (id-pe-cmw) has
been registered for the purpose in the relevant SMI registry [2].
cheers, t
[1] https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/
[2]
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
