Hey Aron
(dropping RATS) > allowing ACME Servers to ignore the CSR entirely if they so wished Yeah, that is the direction that CSRs seem to be going for WebPKI – the CSR is just a public key container with PoP, but we actually don’t really care about PoP anymore. I wouldn’t be against registering a generic “device-attest” challenge type so that there’s a way to do this outside of the CSR. Unfortunately Brandon has grabbed “device-attest-01” to specifically mean “webauthn”. Actually I’ll post a comment on Brandon’s draft that it should be renamed to “webauthn-attest-01”. New email thread incoming. --- Mike Ounsworth From: Aaron Gable <aaron=40letsencrypt....@dmarc.ietf.org> Sent: Wednesday, July 24, 2024 3:06 PM To: Mike Ounsworth <mike.ounswo...@entrust.com> Cc: Michael Richardson <m...@sandelman.ca>; r...@ietf.org; acme@ietf.org Subject: Re: [Acme] Re: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft, I'll note that I'm generally strongly in favor of introducing new ACME identifier types. I'm not very familiar with the exact proposal being discussed here, but I think that more reliance on identifiers presented at newOrder time, I'll note that I'm generally strongly in favor of introducing new ACME identifier types. I'm not very familiar with the exact proposal being discussed here, but I think that more reliance on identifiers presented at newOrder time, and less reliance on attributes of the finalize-time CSR, is the way forward. For example, I hope to introduce a proposal for a "pubkey" identifier type, so that TLS ACME clients can submit their pubkey at newOrder time. This would remove the last field that the ACME CA truly relies on the CSR for, allowing ACME Servers to ignore the CSR entirely if they so wished. It also has the added benefit of letting clients prove that they control the corresponding private key (by fulfilling an ACME Challenge for the pubkey identifier, e.g. by conducting a TLS handshake with that key), which the current CSR transmission mechanism does not do. I think that more initiatives can and should take this approach, and adding new identifier types is generally a good thing. Aaron On Wed, Jul 24, 2024 at 12:56 PM Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org <mailto:40entrust....@dmarc.ietf.org> > wrote: 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 <mailto:m...@sandelman.ca> > Sent: Wednesday, July 24, 2024 2:26 PM To: Mike Ounsworth <mike.ounswo...@entrust.com <mailto:mike.ounswo...@entrust.com> > Cc: r...@ietf.org <mailto: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 _______________________________________________ Acme mailing list -- acme@ietf.org <mailto:acme@ietf.org> To unsubscribe send an email to acme-le...@ietf.org <mailto:acme-le...@ietf.org>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
