On Thu, Sep 07, 2023 at 05:12:57PM +0100, Q Misell wrote: > 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.
Can you expand on why you feel that a set of profiles isn't sufficient? While the issue of combinatorial explosion has been raised as a theoretical problem, I haven't seen anyone involved in operating a CA say "we have mapped out the set of profiles we would need to support, and it is unworkably large". > 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). While I agree this seems to nicely split the difference, I worry that it's actually the worst of both worlds: CAs will still need to support a potentially-unbounded set of profiles (for any variation that can't be expressed reasonably as a set of boolean values) while also having the "validating a complex request" issues. It also makes it difficult to delineate what should be a "flag", and what should be a separate profile, as your example can be made to show: > 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. I can totally imagine a CA starting off with a single profile, with no options. Then they start offering a ECDSA intermediate, and "for compatibility reasons" decide to stick with the single profile and make "ecdsa_intermediate" a default-false boolean flag (with false indicating "use an RSA intermediate"). Then, some years down the road, PQC rolls out, and "for compatibility reasons", the CA adds a new flag, "pqc_intermediate", which is now mutually-exclusive with the "ecdsa_intermediate" flag, and we're back into having to validate a whole set of flags. One can partially mitigate this scenario by saying that all flags defined to be associated with a profile must be specified in a request (ie "no default values"), but that will most likely end up with profile proliferation, as whenever a CA needs to add a flag to their profiles, they have to define new profiles (and keep the old ones around, for compatibility). For example, consider a CA that has "rsa_intermediate" and "ecdsa_intermediate" profiles, but *doesn't* support OCSP must-staple. These profiles have no options. Then, due to customer demand, they implement OCSP must-staple, and want to make it optional. However, they can't add an option flag to the existing profiles (because that would break usage for all their existing clients who don't specify a value for that flag), so they need to make "rsa_intermediate_ocsp_must_staple" and "ecdsa_intermediate_ocsp_must_staple" profiles, where ocsp_must_stable is a flag, and migrate all users to that profile (and teach them to set the flag if they want it). Lather, rinse, repeat for all other optional features the CA introduces over time. - Matt _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
