Carl, Thomas,
I think we’re gonna see three situations: 1) ACME attestation evidence comes wrapped inside WebAuthn. 2) ACME attestation evidence comes wrapped inside CMW. 3) ACME attestation evidence comes in some other format – either not wrapped, or in some other wrapper format. Case #1 is covered by Brandon’s draft (but I would like to see it suitably renamed). For cases 2 & 3, since CMW is an IETF spec, it’s reasonable for ACME to make an opinionated choice that you can’t put bare attestation payloads, they have to be either WebAuthn, or wrapped in CMW. That does put the responsibility on the ACME client Regardless, somebody probably needs to start a draft parallel to Brandon’s that tells how to carry CMW in ACME so that we can start having these discussions – let’s not slow down Brandon’s draft by trying to add CMW to it because I understand that it has real-world deployments waiting for it. --- Mike Ounsworth From: Carl Wallace <c...@redhoundsoftware.com> Sent: Thursday, July 25, 2024 8:19 AM To: Thomas Fossati <thomas.foss...@linaro.org>; Mike Ounsworth <mike.ounswo...@entrust.com> Cc: acme@ietf.org; draft-acme-device-att...@ietf.org Subject: [EXTERNAL] Re: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? Why is the extensibility mechanism in webauthn not sufficient? There's even a registry already set up for those already: https: //urldefense. com/v3/__https: //www. rfc-editor. org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$. Why is the extensibility mechanism in webauthn not sufficient? There's even a registry already set up for those already: https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$ <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8809*sctn-attstn-format-registry__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXheqJNgT$> . On 7/25/24, 9:13 AM, "Thomas Fossati" <thomas.foss...@linaro.org <mailto:thomas.foss...@linaro.org%20%3cmailto:thomas.foss...@linaro.org> <mailto:thomas.foss...@linaro.org>> wrote: Hi Mike, Brandon, On Wed, 24 Jul 2024 at 23:10, Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org <mailto:Mike.Ounsworth=40entrust....@dmarc.ietf.org%20%3cmailto:40entrust....@dmarc.ietf.org> <mailto: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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/__;!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXqzqhwh8$> > [2] https://urldefense.com/v3/__https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml*smi-numbers-1.3.6.1.5.5.7.1__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXtoZTdvJ$ <https://urldefense.com/v3/__https:/www.iana.org/assignments/smi-numbers/smi-numbers.xhtml*smi-numbers-1.3.6.1.5.5.7.1__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXtoZTdvJ$> <https://urldefense.com/v3/__https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml*smi-numbers-1.3.6.1.5.5.7.1__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXtoZTdvJ$ <https://urldefense.com/v3/__https:/www.iana.org/assignments/smi-numbers/smi-numbers.xhtml*smi-numbers-1.3.6.1.5.5.7.1__;Iw!!FJ-Y8qCqXTj2!aiBwd3KAvAXhfER-77w2Zd-7I0czKmRxeJtH9JepnAfqAKMcbNq75XlqMxdAlEkbV7hRuZPHpZvjzBoZXtoZTdvJ$> > _______________________________________________ Acme mailing list -- acme@ietf.org <mailto:acme@ietf.org> <mailto:acme@ietf.org> To unsubscribe send an email to acme-le...@ietf.org <mailto:acme-le...@ietf.org> <mailto:acme-le...@ietf.org>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
