Hi all, I agree with what Aaron says about the difficulty in validating that a complex request from the client meets whatever requirements the CA is adhering to. I do however think that a simple list of profiles isn't the most suitable. Instead I propose that there is a list of profiles, and each profile has a small number of optional boolean flags (the name, and definition of these left to the CA).
For example a CA could have an "rsa_intermediate" and "ecdsa_intermediate" profile, both with an "oscp_must_staple" flag. This would reduce the number of profiles enumerated, whilst also restricting how complex the request from the client can be. A CA would, of course, be free to list profiles and define no flags if it thinks that's the best approach for it. Thoughts? Q Misell ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Fri, 1 Sept 2023 at 07:41, Buschart, Rufus <rufus.buschart= 40siemens....@dmarc.ietf.org> wrote: > Hi all! > > > > I’d like to add two ideas: > > > > 1. The profile entries in the new Profiles object should be capable to > link to ACME servers on a different URL. By this, one could maintain a > central list of ACME servers operated by various CAs within the ACME > protocol standards. > 2. We should enforce, that every profile object must contain a URL to > the CP/CPS of the respective CA (or to the CCADB entry). > > > > Thank you very much for this proposal to extend ACME! > > > > /Rufus > > > > *Von: *Acme <acme-boun...@ietf.org> im Auftrag von Aaron Gable <aaron= > 40letsencrypt....@dmarc.ietf.org> > *Datum: *Donnerstag, 31. August 2023 um 00:21 > *An: *IETF ACME <acme@ietf.org> > *Betreff: *[Acme] Proposal: ACME Profiles > > Hi ACME community, > > > > I believe it is time for us to seriously consider the topic of “profiles”. > > > > For the purposes of this discussion, a profile is a collection of > characteristics which affect the contents of the final certificate issued > by an ACME CA. For example, two different profiles might cause certificates > to have different validity periods (e.g. 10 days vs 90 days), or different > EKUs (e.g. ServerAuth and ClientAuth vs ServerAuth only), or even be issued > from different intermediates. > > > > Historically, profile selection within ACME has been somewhat ad-hoc: > > · The NewOrder request contains “notBefore” and “notAfter” fields > which allow clients to request certain validity periods, but other aspects > of the certificate cannot be customized and support for these fields is > minimal. Let’s Encrypt rejects requests which contain these fields, and > Google Trust Services recommends that they be omitted, because clients are > likely to request values which the server cannot respect (e.g. notBefore > dates unacceptably far in the past, violating BRs requirements regarding > backdating). > > · The CSR contained in the Finalize request message can carry > additional information, but copying values directly from CSRs to final > certificates has been the root cause of many CA incidents, so great care > must be taken. Let’s Encrypt does use the presence of the “ocspMustStaple” > extension in the CSR to cause the inclusion of the same extension in the > final certificate, but this is the only attribute we extract from the CSR > and frankly we’d rather not even do that much. > > · I’m aware of one CA which uses url query parameters to control > aspects of the certificate profile. The client specifies query parameters > in its configured directory URL, the directory object reflects those same > parameters back in its newOrder URL, and then the newOrder endpoint > processes those query parameters to affect the certificate profile. > > > > Recently there has been an uptick in interest in profile selection in > ACME. For example, the recent PQC negotiation thread > <https://mailarchive.ietf.org/arch/msg/acme/FEZYTUfhSeur-wKQI6H2xytSkvY/> > is largely an exercise in profile selection. There’s also been significant > discussion > <https://community.letsencrypt.org/t/offer-a-new-endpoint-and-acme-spec-update-to-list-available-chains/203329> > on the Let’s Encrypt community forum, largely prompted by the desire for > more control in intermediate selection. Let’s Encrypt itself is interested > in formalizing profile selection so that we can make backwards-incompatible > changes to our current issuance profile without breaking clients. And of > course I’ve spoken with other CAs who are interested in the same. > > > > Therefore I believe it is time for ACME to grow support for some form of > profile selection. As argued above, I don’t think that the Finalize CSR is > a good format for this, so something will need to be added to the ACME > protocol itself. I propose the following very simple change: > > > > 1. The directory’s meta object gains a new “profiles” sub-object, whose > keys are short profile name strings (such as “default” or “rsa 2023”) and > whose values are human-readable descriptions of those profiles (such as > “our standard profile, but with a validity period of only 10 days” or a URL > pointing at more verbose documentation). > > 2. The Order object gains a new “profile” field, which can be set in > NewOrder requests, or will be set automatically by the Server according to > its own server policy if no recognized profile is requested. > > > > In some of the discussions mentioned above, much more complex systems have > been proposed. These systems would establish a format for a CA to advertise > every individual adjustable field and all values each field can take. > Clients would then have the ability to both tightly customize the > certificate they request, and to compare the offerings of multiple CAs to > select the one that most closely matches their operator’s preferences. > However, I believe that such a complex system would ultimately be largely a > failure, as most operators would not have complex desires to express, most > clients would not implement complex configuration mechanisms to allow > operators to do so, most CAs would not advertise directly-comparable sets > of attributes, and if we attempted to standardize the set of advertisable > attributes we would inevitably fail to anticipate actual needs. > Additionally, we’ve seen from TLS algorithm negotiation itself that it is > better to offer a few well-studied options than to allow (poorly configured > or misinformed) clients to pick-and-choose from a wide variety of options. > > > > Therefore I believe that this simple approach is best. It will be easy for > both clients and servers to adopt. It will allow CAs to offer well-vetted > profiles for clients who need specific attributes. And it will allow CAs to > preview upcoming profile changes to clients that want to opt in and to > gracefully evolve profiles over time. > > > > We are already working on a draft which formalizes the proposal above, and > hope to implement a version of this in the near future to facilitate the > evolution of our own issuance profile. We’d love to hear all of your > thoughts before we embark down this path! > > > > Thanks, > > Aaron > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
