My goal for draft-acme-device-attest is to provide a relatively simple method for issuing client certificates using the attestation schemes and formats that exist today. Making "attObj" generic explodes the complexity of implementing the draft.
I assume that this document will be supplanted by the RATS
architecture (and future ACME extensions) once platform vendors have
adopted it.
On Fri, Feb 23, 2024 at 9:56 AM Mike Ounsworth
<Mike.Ounsworth=40entrust....@dmarc.ietf.org> wrote:
>
> @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 <bweeks=40google....@dmarc.ietf.org>; Prachi Jain
> <prachi.jain1...@gmail.com>
> Cc: Mike Malone <m...@smallstep.com>; Deb Cooley <debcool...@gmail.com>;
> Thomas Fossati <tho.i...@gmail.com>; acme@ietf.org;
> draft-acme-device-attest.auth...@ietf.org
> 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 <bweeks=40google....@dmarc.ietf.org>
> Sent: Thursday, February 22, 2024 4:25 PM
> To: Prachi Jain <prachi.jain1...@gmail.com>
> Cc: Mike Malone <m...@smallstep.com>; Mike Ounsworth
> <mike.ounswo...@entrust.com>; Deb Cooley <debcool...@gmail.com>; Thomas
> Fossati <tho.i...@gmail.com>; acme@ietf.org;
> draft-acme-device-attest.auth...@ietf.org
> 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$
>
> [1]
> 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 <prachi.jain1...@gmail.com> 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 <m...@smallstep.com> 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$
>
> >>
>
> >> On Thu, Feb 22, 2024 at 12:21 PM Mike Ounsworth
> >> <Mike.Ounsworth=40entrust....@dmarc.ietf.org> 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 <acme-boun...@ietf.org> On Behalf Of Prachi Jain
>
> >>> Sent: Thursday, February 22, 2024 6:03 AM
>
> >>> To: Deb Cooley <debcool...@gmail.com>
>
> >>> Cc: Thomas Fossati <tho.i...@gmail.com>; acme@ietf.org;
> >>> draft-acme-device-attest.auth...@ietf.org
>
> >>> 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 <debcool...@gmail.com> 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 <prachi.jain1...@gmail.com>
> >>> 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 <tho.i...@gmail.com> wrote:
>
> >>>
>
> >>> Hi, all,
>
> >>>
>
> >>> The acme-device-attest draft is expired.
>
> >>>
>
> >>> Just checking: what are the plans?
>
> >>>
>
> >>> cheers, thanks!
>
> >>>
>
> >>> _______________________________________________
>
> >>> Acme mailing list
>
> >>> Acme@ietf.org
>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$
>
> >>>
>
> >>> _______________________________________________
>
> >>> Acme mailing list
>
> >>> Acme@ietf.org
>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$
>
> >>>
>
> >>> _______________________________________________
>
> >>> Acme mailing list
>
> >>> Acme@ietf.org
>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
