Awesome. Thanks for talking with Yaron Michael!
Cross-posting to ACME. One quibble, “ACME uses CSRs.”; true; putting the attestation payload inside the CSR, and the CSR inside ACME is one way to do it (IMO it’s an excellent way to do it), but I also want to nod to Brandon’s draft-acme-device-attest which defines a new ACME challenge type “device-attest-01”, but that is unfortunately narrowly-defined to WebAuthn, so is not useful to P11 type devices that don’t feel like cramming themselves into a WebAuthn-shaped box. So we’re proposing that our solutions (draft-ounsworth-rats-pkix-evidence, draft-ietf-lamps-csr-attestation) describe the most general and flexible way of conveying evidence to a CA. pkix-evidence(draft-ounsworth-rats-pkix-evidence), inside of a CSR (draft-ietf-lamps-csr-attestation) inside of any CSR-carrying protocol (ACME, EST, CMC, usb-stick-out-of-airgapped-datacentre, email to your IT guy, CTRL+V to CA webpage, or any other protocol for transporting CSRs. Not to mention the whole suite of Microsoft proprietary cert enrollment protocols: WNES, WSTEP, and friends, which I believe also carry CSRs, so could benefit from this for free. I joke a bit, but in all seriousness, part of the answer to “Why not ACME?” is that especially for Enterprise and People PKIs, “USB stick, email, and CTRL+V” still represents a large bulk of how certs get issued. Of course our draft is not limited to certificate request usecases; it becomes another general attestation evidence payload format that could be used in attested-tls, attested-ike, attested-routers, whatever. --- Mike Ounsworth From: Michael Richardson <m...@sandelman.ca> Sent: Wednesday, July 24, 2024 2:26 PM To: Mike Ounsworth <mike.ounswo...@entrust.com> Cc: r...@ietf.org Subject: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft, Mike Ounsworth <Mike. Ounsworth=40entrust. com@ dmarc. ietf. org> wrote: > The comments yesterday from Yaron of "Why not use ACME?", and from the > chairs "Does this belong in LAMPS", makes me think that we have not > explained the Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org <mailto:Mike.Ounsworth=40entrust....@dmarc.ietf.org> > wrote: > The comments yesterday from Yaron of "Why not use ACME?", and from the > chairs "Does this belong in LAMPS", makes me think that we have not > explained the purpose of the draft very well. I spoke to Yaron afterward: and the key piece of information that was missing from the discussion are: a) ACME uses CSRs. b) the Evidence has to be within the CSR signature. c) the Evidence is *not* about the posture of the system that will be using the key/certificate, but rather about the storage of the private key. > Table of contents of this email: > - Problem statement > - Why EAT doesn't work well for HSMs > - What this draft does > - New claims
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
