Hi Q, Thanks for reading through the draft!
On Thu, Nov 7, 2024 at 7:32 AM Q Misell <q=40as207960....@dmarc.ietf.org> wrote: > One thing I would like to see addressed is CAs deprecating a profile. > Obviously, when a client requests a certificate with a deprecated profile > it will receive an invalidProfile error, however it would be nice to know > about this situation in advance. > An idea I had was to put this in the ARI response - some form of "the > profile this certificate used won't be available from X". This would allow > a client to alert someone (somehow) that they'll have to update the profile > before the next renewal, instead of possibly not having enough time when > the certificate needs renewing. > Thoughts? > Hmm, this is an interesting idea. It does seem like "renewalInfo" would be the place for information relevant to the next renewal of a certificate to live. But that "(somehow)" is doing a lot of heavy lifting in your sentence -- today, ARI is designed to be machine-readable and generally ignored by humans since the client will simply ensure the certificate is renewed at the right time anyway. One thing I've been going back and forth on in my own head is the current sentence: > If the server receives a newOrder request specifying a profile that it is not advertising... it MUST reject the request with a problem document of type "invalidProfile" (see Section 6.3). An alternative would be for the server to accept the request, but change the profile to a server-selected profile, just like it does for orders which don't specify a profile at all. This has the upside of allowing server operators to make informed decisions during profile deprecations, like "clients requesting profile X should migrate to profile Y". But it has two downsides: some clients may be requesting a profile for very specific reasons and be very opposed to getting a certificate that doesn't match that exact profile; and it means that servers would likely have to keep a list of *all* profiles they'd ever advertised in the past in order to map them to current profiles. Definitely worth continuing to think about. Thanks, Aaron
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
