Hi Aaron, While thinking deeply about DavidBen's profile-sets draft, I had a thought that actually pertains to your draft: Implementation Considerations about change management.
I think there's an assumption here that the CA is free to evolve their offered profiles over time; for example to stay synced with CA/B or other regulatory requirements, and that the ACME Profiles mechanism provides an abstraction layer for that. Like, a cert ordered against the profile "TlsRsaRoot" in May might return a slightly different cert than one ordered against the same profile in October. But then, how much change is too much change that the CA really ought to declare a new profile and deprecate the old one? Like, if you changed the length of the CA cert path, or you change EKUs, then you're running into a risk that ACME Clients will throw errors when they try to stuff that into a web server (or worse, TLS handshakes start failing after the cert update). This is starting to feel like a profile might need a semantic versioning tag X.Y.Z; so maybe a profile naming scheme "TlsRsaRoot-1.2.3" where a Z update to the profile is extremely unlikely to cause the ACME Client or TLS server to throw any errors; a Y update SHOULD be done in a test environment first, and a X update is basically a brand new profile, such as if your root cert expires and you roll over to a new RSA key, since that's highly likely to break clients that have done any kind of root pinning. I don't have any specific text suggestions for your draft; just food for thought that I think the draft should have at least some informative text about profile change management, if not baking something normative into the protocol to handle this; like a profile naming convention or a version field.
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
