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 <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. 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$ > > <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$> > > <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 <acme@ietf.org>> > > To unsubscribe send an email to acme-le...@ietf.org > <mailto:acme-le...@ietf.org <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
