That’s fine, but it opens the potential for the same types to be registered under different wrappers. It’s not the end of the world.
From: Q Misell <q...@as207960.net> Date: Tuesday, July 30, 2024 at 2:59 AM To: Carl Wallace <c...@redhoundsoftware.com> Cc: Mike Ounsworth <mike.ounswo...@entrust.com>, Thomas Fossati <thomas.foss...@linaro.org>, "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"? Given "device-attest-01" is already shipped in some client implementations I don't think we should change the name. I also don't think we should try and make this more generic and add more wrapper layers, type IDs are free, we can just invent more. Personally I'm in favour of a CMW attestation being device-attest-02. We haven't really settled on what the 'version' number in types means, but I think setting the precedent this way is probably correct. 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, LEI 875500FXNCJPAPF3PD10. ICO register №: 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. On Fri, 26 Jul 2024 at 12:09, Carl Wallace <c...@redhoundsoftware.com> wrote: Inline… From: Mike Ounsworth <mike.ounswo...@entrust.com> Date: Thursday, July 25, 2024 at 3:40 PM 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, You’d propose to put <watever_evidence_data_format> inside CMW, inside WebAuthn, inside the device-attest-01 defined in Brandon’s draft? Is that done? I see the registry you’re referring to of registered Webauthn sub-formats: https://www.iana.org/assignments/webauthn/webauthn.xhtml but I don’t see CMW. [CW] Well, right. That would need to be added, which is why I referenced the registration steps. None of the items in your list are “done” either. Is that the intended usage of CMW; to be a sub-format of WebAuthn? [CW] I get that it’d be a wrapper in a wrapper (to Thomas’s point elsewhere in the thread), which sub-ideal. Having multiple wrapper types is also sub-ideal, especially if some types get registered to be conveyed in different types of wrappers. Is the cost of an extra wrapper layer greater than the extra complexity of supporting multiple top level wrapper types? --- Mike Ounsworth From: Carl Wallace <c...@redhoundsoftware.com> Sent: Thursday, July 25, 2024 2:32 PM To: Mike Ounsworth <mike.ounswo...@entrust.com>; Thomas Fossati <thomas.foss...@linaro.org> 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"? 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> _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
