Inline…
From: Mike Ounsworth <mike.ounswo...@entrust.com> Date: Thursday, July 25, 2024 at 11:30 AM To: Carl Wallace <c...@redhoundsoftware.com>, Thomas Fossati <thomas.foss...@linaro.org> Cc: "acme@ietf.org" <acme@ietf.org>, "draft-acme-device-att...@ietf.org" <draft-acme-device-att...@ietf.org> Subject: RE: [Acme] Re: Can we rename "draft-bweeks-acme-device-attest" to "webauthn-attest"? 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. [CW] My point was that those situations could be represented as attestation statement formats within WebAuthn (though since my note below I recalled that this draft does not leverage the existing registry but creates its own). I don’t think we want to end up with a scenario like what happened with cert request protocols in PKIX 20+ years ago and wind up with multiple competing mechanisms to support attestations. 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. [CW] Leveraging WebAuthn extensibility mechanisms ought not to impact Brandon’s draft. I think the steps to define how to carry a CMW in ACME are those described in 7.4. That might be a good exercise to conduct before discarding that as a way forward. --- 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$. On 7/25/24, 9:13 AM, "Thomas Fossati" <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: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$> [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$> _______________________________________________ Acme mailing list -- acme@ietf.org <mailto:acme@ietf.org> To unsubscribe send an email to 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
