<mailto:[email protected]> @Brandon Weeks – I wonder if acme-device-attest-01 could be broadened so that “attObj” is allowed to contain evidence other than WebAuthn – ie make WebAuthn an example rather than normative? I would suggest listing “EvidenceBundles” from draft-ietf-lamps-csr-attestation, and RATS ConceptualMessageWrapper from draft-ietf-rats-msg-wrap as other valid examples.
--- Mike Ounsworth From: Mike Ounsworth Sent: Friday, February 23, 2024 11:48 AM To: Brandon Weeks <[email protected]>; Prachi Jain <[email protected]> Cc: Mike Malone <[email protected]>; Deb Cooley <[email protected]>; Thomas Fossati <[email protected]>; [email protected]; [email protected] Subject: RE: [Acme] [EXTERNAL] Re: acme-device-attest expired Here’s my 5-minute side-by-side of the two drafts. draft-ietf-lamps-csr-attestation: - whatever evidence blob your device can produce, stick it as an OCTET STRING (or whatever other ASN.1 type) inside a new CSR attribute called id-aa-evidence. - Any cert chains required to validate the evidence blob also go inside id-aa-evidence. - It’s the CA’s job to find a verifier that can parse whatever evidence data you gave it. - Was written under the full generality of the RATS Architecture. draft-acme-device-attest: - Defines new SANs for use in CSRs: “permanent-identifier” and “hardware-module”. - Defines a new ACME Challenge “device-attest-01” - Expects the returned Evidence data to be in WebAuthn format. "payload": base64url({ "attObj": base64url(/* WebAuthn attestation object */) - Was written specifically for Android, Chrome, and TPM attestations in WebAuthn format. My first impression is that we should continue with both in parallel and not try to combine them. lamps-csr-attest is more general in that it applies to things that are not WebAuthn, and will work anywhere that accepts CSRs. acme-attest allows the client to send a cert req, and then the CA to decide whether or not to challenge for an attestation. It also has invested implementors. --- Mike Ounsworth From: Brandon Weeks <[email protected] <mailto:[email protected]> > Sent: Thursday, February 22, 2024 4:25 PM To: Prachi Jain <[email protected] <mailto:[email protected]> > Cc: Mike Malone <[email protected] <mailto:[email protected]> >; Mike Ounsworth <[email protected] <mailto:[email protected]> >; Deb Cooley <[email protected] <mailto:[email protected]> >; Thomas Fossati <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [Acme] [EXTERNAL] Re: acme-device-attest expired Apologies for letting the draft expire. I've recently switched roles within Google and have been busy ramping up. My new team is responsible for Android Key Attestation[0], one of the attestation schemes included in the draft, which hopefully Apologies for letting the draft expire. I've recently switched roles within Google and have been busy ramping up. My new team is responsible for Android Key Attestation[0], one of the attestation schemes included in the draft, which hopefully allows me to build a production implementation of the draft. I've incorporated one change from Thomas and updated the draft to version 2[1]. There hasn’t been much feedback on the draft during the ACME sessions or on the mailing list, especially from implementers, so I’m really excited to see all of the interest on this thread. I’d be more than happy to incorporate any feedback received and present at IETF 120. If reviewing the draft in a meeting would be helpful, please reach out to me directly and I’d be happy to schedule time. Thanks, Brandon [0] https://urldefense.com/v3/__https://developer.android.com/privacy-and-security/security-key-attestation__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem9PC1YNe$ <https://urldefense.com/v3/__https:/developer.android.com/privacy-and-security/security-key-attestation__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem9PC1YNe$> [1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-acme-device-attest/02/__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem6-cnbGh$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-acme-device-attest/02/__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem6-cnbGh$> On Thu, Feb 22, 2024 at 1:53 PM Prachi Jain <[email protected] <mailto:[email protected]> > wrote: > > I plan to do a POC using this draft and potentially implement it based on the > results. Thus very motivated to get this past the finish line. > > @Mike Ounsworth, I haven't read draft-ietf-lamps-csr-attestation yet so I am > going to give it a read and come back with my thoughts. > > On Thu, Feb 22, 2024 at 3:00 PM Mike Malone <[email protected] > <mailto:[email protected]> > wrote: >> >> It's worth noting that Apple has already implemented this draft on macOS, >> iOS, iPadOS, and tvOS[1]. We've implemented the server side at Smallstep and >> can confirm that there is adoption. That shouldn't stop the evolution of >> this draft, of course, but could help inform it. Adoption is promising and >> it would be unfortunate to see this die at draft. >> >> We don't have any experienced IETF authors here -- not sure what that >> entails -- but we are very interested in the outcome here and would be happy >> to help however we can. To start, I've shared this with a few contacts that >> I know will also be interested. >> >> Mike >> >> [1] >> https://urldefense.com/v3/__https://support.apple.com/lt-lt/guide/deployment/dep28afbde6a/web__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem_caMV21$ >> >> <https://urldefense.com/v3/__https:/support.apple.com/lt-lt/guide/deployment/dep28afbde6a/web__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem_caMV21$> >> >> >> On Thu, Feb 22, 2024 at 12:21 PM Mike Ounsworth >> <[email protected] >> <mailto:[email protected]> > wrote: >>> >>> At the risk of adding another draft to my plate, I am the lead author on >>> draft-ietf-lamps-csr-attestation, so I suppose it is reasonable for me to >>> volunteer to work on this one also. >>> >>> >>> >>> I wonder if the design of acme-device-attest should change in light of the >>> existence of draft-ietf-lamps-csr-attestation? But I admit to not having >>> read acme-device-attest in a while :/ >>> >>> >>> >>> --- >>> >>> Mike Ounsworth >>> >>> >>> >>> From: Acme <[email protected] <mailto:[email protected]> > On >>> Behalf Of Prachi Jain >>> Sent: Thursday, February 22, 2024 6:03 AM >>> To: Deb Cooley <[email protected] <mailto:[email protected]> > >>> Cc: Thomas Fossati <[email protected] <mailto:[email protected]> >; >>> [email protected] <mailto:[email protected]> ; >>> [email protected] >>> <mailto:[email protected]> >>> Subject: [EXTERNAL] Re: [Acme] acme-device-attest expired >>> >>> >>> >>> Thank you for the update, Deb. I am more than willing to work as an author >>> on this draft and help out :) On Thu, Feb 22, 2024 at 5: 28 AM Deb Cooley >>> <debcooley1@ gmail. com> wrote: I know Brandon has been busy, but I don't >>> know his plans >>> >>> Thank you for the update, Deb. >>> >>> >>> >>> I am more than willing to work as an author on this draft and help out :) >>> >>> >>> >>> On Thu, Feb 22, 2024 at 5:28 AM Deb Cooley <[email protected] >>> <mailto:[email protected]> > wrote: >>> >>> I know Brandon has been busy, but I don't know his plans for this draft. >>> Maybe his use case has changed? I've cc'd him on this message. >>> >>> >>> >>> Note: acme is a 'working group', to get a draft through the process people >>> have to be willing to work on the draft (vice merely following). Also >>> drafts can certainly have multiple authors, perhaps an offer of helping as >>> an author might work. >>> >>> >>> >>> Deb >>> >>> >>> >>> On Tue, Feb 20, 2024 at 11:01 AM Prachi Jain <[email protected] >>> <mailto:[email protected]> > wrote: >>> >>> Hello, >>> >>> I have been closely following this document as well and would like to know >>> the status of the same. >>> >>> Thanks, >>> Prachi >>> >>> >>> >>> On Sun, Feb 18, 2024 at 1:57 AM Thomas Fossati <[email protected] >>> <mailto:[email protected]> > wrote: >>> >>> Hi, all, >>> >>> The acme-device-attest draft is expired. >>> >>> Just checking: what are the plans? >>> >>> cheers, thanks! >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] <mailto:[email protected]> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$ >>> >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$> >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] <mailto:[email protected]> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$ >>> >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$> >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] <mailto:[email protected]> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$ >>> >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$> >>>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
