Hi Aaron, Great to see this work in I-D form! Overall I think your draft is well thought out and leaves plenty of flexibility for different situations whilst not being too onerous on any party.
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? Q ------------------------------ 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 Wed, 6 Nov 2024 at 23:37, Aaron Gable <aaron= 40letsencrypt....@dmarc.ietf.org> wrote: > Hi ACME WG, > > Here's the material I intended to present regarding my ACME Profiles draft > at IETF 121. My slides are attached. > > I have published draft-aaron-acme-profiles-00 > <https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/>, the first > draft of my proposal for incorporating "profile selection" into the ACME > protocol, as I proposed at IETF 120. > > Concretely, the draft does four things: > - establishes a new "profiles" field within the Directory's "meta" object, > which allows the server to advertise the profiles that clients can select; > - establishes a new "profile" field on Order objects, which allows clients > to request a profile when making a new-order request and allows servers to > display the profile associated with an order; > - sets rules for when and how clients should request profiles, and when > and how servers should accept or reject such requests; and > - establishes a new "invalidProfile" error to facilitate the rejection of > invalid requests. > > This draft is implemented by both the Boulder and Pebble ACME server > implementations, with the exception of the "invalidProfile" error type. The > code supporting profile selection is deployed in Let's > Encrypt's environments, but the functionality is gated behind a feature > flag which has not yet been enabled. I have locally augmented clients to > support requesting profiles, but have not yet upstreamed such changes to > open-source ACME client projects. > > I'm not yet asking for working group adoption, but I would like to kick > off a first round of edits, suggestions, and feedback. > > 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
