> 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.
Should the profile include a "deprecated" flag, or a notAfter date of some sort? That may require modifying the proposal's JSON in the directory a bit to support metadata about each profile, but that may be useful for other profile metadata in the future as well. > 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 If we did allow server-selected profiles in the face of an invalid profile, the selected profile would still be reflected in the returned order. The client could then error out if it has "very specific reasons". On the other hand, I expect Let's Encrypt to have a very small number of profiles and probably approximately never remove them. At most, we might change one to be an alias of another, rather than implement some sort of mapping to upgrade. On Thu, Nov 7, 2024 at 1:03 PM Aaron Gable <aaron= 40letsencrypt....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
