Thanks for the continued discussion, all! Replies to multiple emails inline.
On Tue, Sep 19, 2023 at 4:17 PM Ben Burkert <benburk...@anchor.dev> wrote: > The way we solve this is at the intermediate CA level, which we refer to > as a SubCA. Each SubCA is an intermediate CA that issues end entity > certs, and a template that sets a common set of properties of the end > entity certs that it issues. For example, when creating a SubCA you can > specify the expiry time (as a duration), key usage and other extensions, > and allowed DNS/IP naming rules (which can turn into name constraints on > the intermediate). Tying profiles to intermediates is interesting, but difficult in the public WebPKI context, where generating new intermediates means accessing the offline Root HSM. That would make creating new profiles significantly more difficult. Also, relying on EAB for profile selection is suboptimal for CAs that have never needed EAB, like Let's Encrypt. On Mon, Oct 9, 2023 at 3:10 AM Deb Cooley <debcool...@gmail.com> wrote: > When a request is made, as long as the CSR matches the options we have > given them in the profile, the cert is issued. I think this old school > method should scale to ACME without too much trouble. > >From what Let's Encrypt saw when launching, relying on CSRs to determine profiles was deeply fraught and error prone. This is why LE ignores everything in the CSR except for 1) the names (as mandated by RFC 8555), 2) the public key, and 3) the ocspMustStaple extension. As a simple example, it's a very common mistake for an ACME client to produce a CSR with a validity period 1 second greater than intended (because the validity period is inclusive of the notAfter timestamp), which would then not match the profile and be rejected. Personally, I'd rather move in the direction of removing CSRs from the ACME protocol altogether, than enshrining even more profile selection within them. But even more to the point, this doesn't describe how the client selects a profile from amongst those advertised. Are you suggesting a combination of the approach I described (a profile name in the newOrder request) and CSRs to fine-tune options within that profile? On Tue, Sep 19, 2023 at 5:33 PM Matthew McPherrin <mattm= 40letsencrypt....@dmarc.ietf.org> wrote: > My personal opinion here is that adding a profile field to the Order > object is likely to hamper client adoption, and as Ben just said, makes > configuration more difficult if CAs don't have matching profiles. > > An alternative approach that I believe has been used is adding URL > parameters to the directory URL, as Aaron mentioned in his initial email. > > I believe that adding parameters to directory URLs requires no additional > standardization work, and Let's Encrypt can add a profile parameter > immediately. > Let's Encrypt is now considering going in this direction. Given that it requires zero client development, no standardization, and has been effectively used by at least one other CA, the "directory URL query parameters" approach seems very tempting. I personally would still like to include some sort of profile selection in ACME itself, but maybe this work will be rolled into my larger thoughts for an ACME-bis that takes into account some of the things we've learned over the last eight years. Aaron
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
