Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
Adoption it is. Stay tuned for the updated draft. Deb On Thu, Dec 1, 2022 at 2:46 PM Sean Turner wrote: > I read it and support adoption. > > spt > > > On Nov 15, 2022, at 13:01, Deb Cooley wrote: > > > > This will be a three week call for adoption ending on 6 Dec. (because of > holidays in the US). Please speak up either for or against adopting this > draft. > > > > Thanks, > > Deb and Yoav. > > > > ___ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
I read it and support adoption. spt > On Nov 15, 2022, at 13:01, Deb Cooley wrote: > > This will be a three week call for adoption ending on 6 Dec. (because of > holidays in the US). Please speak up either for or against adopting this > draft. > > Thanks, > Deb and Yoav. > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
I think a even better idea is to actually support passports for real. Passports and ID-cards (with an MRZ), and some driver licenses with an MRZ today contain a NFC chip, so a ACME server could provide this as a validation method for getting a fully validated certificate. The passports can then be validated electronically using the country signer key, and then a fully validated certificate can be issued. On the topic of validating in the passport model however, is that if the attestation from the verifier is fraudulent, there is no possibility for the verifier to revoke it. This serves less of a importance if the ownership of physical device is being attested, whose contains no identity information. But if its a device or attestation linked to a person or organization, there must be a way to revoke said credential, for example if it becomes lost. Which means you have to implement the background check topology regardless, and in some way, check the attestation with the verifier to ensure it hasnt been blocked. There is a third model however, which mixes background check and passport model. That is, you have a long-lived attestation from a verifier. You then get a short-lived attestation that the long lived attestation is still valid (think OCSP protocol here) You then send both attestations to the RP (OCSP Stapling). This only serves a advantage if you need to verify yourself against many RPs in a short timeframe, and you want to ease up the load on the verifier. In a certificate issuance situation, this will never become a problem, since a ACME server will only contact a verifier a few times per 30/60/90 days. Thus the background check model can always be used. Från: acme-boun...@ietf.org För Thomas Fossati Skickat: den 24 november 2022 13:35 Till: Deb Cooley ; IETF ACME Kopia: acme-cha...@ietf.org Ämne: Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest I have read the draft and I think it brings a very valuable feature into the ACME ecosystem. Its also a perfect fit in at least two of our projects, and Id be happy to integrate it in our protocol flows. The only concern I have with the current proposal is its reliance on WebAuthns as the sole encap format. The trouble is it only allows background check-style topologies [1], whilst wed like to be able to support passport [2] as well. Therefore, Id like to have WebAuthn as one of the supported formats, rather than the only supported format. (For a more generic encapsulation of attestation-related payloads you may want to take a look at [3].) Cheers, thanks t [1] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section -5.2 [2] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section -5.1 [3] https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/ On 15/11/2022, 18:03, "Acme" mailto:acme-boun...@ietf.org> > wrote: This will be a three week call for adoption ending on 6 Dec. (because of holidays in the US). Please speak up either for or against adopting this draft. Thanks, Deb and Yoav. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
I have read the draft and I think it brings a very valuable feature into the ACME ecosystem. It’s also a perfect fit in at least two of our projects, and I’d be happy to integrate it in our protocol flows. The only concern I have with the current proposal is its reliance on WebAuthn’s as the sole encap format. The trouble is it only allows “background check”-style topologies [1], whilst we’d like to be able to support “passport” [2] as well. Therefore, I’d like to have WebAuthn as one of the supported formats, rather than the only supported format. (For a more generic encapsulation of attestation-related payloads you may want to take a look at [3].) Cheers, thanks t [1] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section-5.2 [2] https://www.ietf.org/archive/id/draft-ietf-rats-architecture-22.html#section-5.1 [3] https://datatracker.ietf.org/doc/draft-ftbs-rats-msg-wrap/ On 15/11/2022, 18:03, "Acme" wrote: This will be a three week call for adoption ending on 6 Dec. (because of holidays in the US). Please speak up either for or against adopting this draft. Thanks, Deb and Yoav. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
I think the ACME WG should adopt this document. I have a couple of comments below. Minor: Section 1: The text talks about permanent-identifier. Please add a reference to RFC 4043 the first time this term is used. Section 1: The text talks about hardware-module identifier. Is this about theHardwareModuleName described in RFC 4108? If so, please add a reference. If not, please pick name that will avoid this confusion. Nits: Section 1: s/and if the certificate key/and whether the certificate key/ Russ ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
We’ve implemented the draft at smallstep in our open source project and commercial product. We’ve successfully integrated with Apple devices, including phones and tablets running iOS 16 and laptops running macOS 13.1. We’ve also built our own Attestation CA and endpoint software that works with TPMs on Windows and Linux. We’re seeing strong vendor and commercial interest and overall enthusiasm for the unlock achieved via an interoperable framework for device attestation. This spec is simple and well scoped to solve the problem. We definitely support adoption. Mike On Thu, Nov 17, 2022 at 11:00 AM Amir Omidi wrote: > I've read the draft and think it's a valuable addition for the ACME > ecosystem. > > On Wed, Nov 16, 2022 at 9:11 AM Richard Barnes wrote: > >> I have read the draft, and it seems well thought through. Especially if >> there is implementor interest, this seems like a sane thing for the WG to >> adopt. >> >> On Tue, Nov 15, 2022 at 2:53 PM Carl Wallace >> wrote: >> >>> I’ve read the draft and support its adoption. >>> >>> >>> >>> *From: *Acme on behalf of Deb Cooley < >>> debcool...@gmail.com> >>> *Date: *Tuesday, November 15, 2022 at 1:01 PM >>> *To: *IETF ACME >>> *Cc: * >>> *Subject: *[Acme] Call for adoption for draft-bweeks-acme-device-attest >>> >>> >>> >>> This will be a three week call for adoption ending on 6 Dec. (because of >>> holidays in the US). Please speak up either for or against adopting this >>> draft. >>> >>> Thanks, >>> Deb and Yoav. >>> >>> ___ Acme mailing list >>> Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme >>> ___ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> ___ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > -- Mike Malone | Founder / CEO | https://smallstep.com Blog: Use SSH Certificates <https://smallstep.com/blog/use-ssh-certificates/> | Private ACME CA <https://smallstep.com/blog/private-acme-server/> Open Source: Step CA <https://github.com/smallstep/certificates> | Step CLI <https://github.com/smallstep/cli> Schedule a Meeting <https://calendly.com/smallstep/smallstep-discussion> ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
I've read the draft and think it's a valuable addition for the ACME ecosystem. On Wed, Nov 16, 2022 at 9:11 AM Richard Barnes wrote: > I have read the draft, and it seems well thought through. Especially if > there is implementor interest, this seems like a sane thing for the WG to > adopt. > > On Tue, Nov 15, 2022 at 2:53 PM Carl Wallace > wrote: > >> I’ve read the draft and support its adoption. >> >> >> >> *From: *Acme on behalf of Deb Cooley < >> debcool...@gmail.com> >> *Date: *Tuesday, November 15, 2022 at 1:01 PM >> *To: *IETF ACME >> *Cc: * >> *Subject: *[Acme] Call for adoption for draft-bweeks-acme-device-attest >> >> >> >> This will be a three week call for adoption ending on 6 Dec. (because of >> holidays in the US). Please speak up either for or against adopting this >> draft. >> >> Thanks, >> Deb and Yoav. >> >> ___ Acme mailing list >> Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme >> ___ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
I have read the draft, and it seems well thought through. Especially if there is implementor interest, this seems like a sane thing for the WG to adopt. On Tue, Nov 15, 2022 at 2:53 PM Carl Wallace wrote: > I’ve read the draft and support its adoption. > > > > *From: *Acme on behalf of Deb Cooley < > debcool...@gmail.com> > *Date: *Tuesday, November 15, 2022 at 1:01 PM > *To: *IETF ACME > *Cc: * > *Subject: *[Acme] Call for adoption for draft-bweeks-acme-device-attest > > > > This will be a three week call for adoption ending on 6 Dec. (because of > holidays in the US). Please speak up either for or against adopting this > draft. > > Thanks, > Deb and Yoav. > > ___ Acme mailing list > Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest
I’ve read the draft and support its adoption. From: Acme on behalf of Deb Cooley Date: Tuesday, November 15, 2022 at 1:01 PM To: IETF ACME Cc: Subject: [Acme] Call for adoption for draft-bweeks-acme-device-attest This will be a three week call for adoption ending on 6 Dec. (because of holidays in the US). Please speak up either for or against adopting this draft. Thanks, Deb and Yoav. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Call for adoption for draft-bweeks-acme-device-attest
This will be a three week call for adoption ending on 6 Dec. (because of holidays in the US). Please speak up either for or against adopting this draft. Thanks, Deb and Yoav. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
