Dear community, I have published a new version of draft-giron-acme-pqcnegotiation. Any feedback is appreciated.
https://datatracker.ietf.org/doc/draft-giron-acme-pqcnegotiation/ Diff: https://author-tools.ietf.org/iddiff?url2=draft-giron-acme-pqcnegotiation-03 Pros: - RFC 8555 offers a 'try-and-error' negotiation: doing account creation + identifier validation + finalize request to see that the desired signature/algorithm might not be supported (e.g., badKey error). This draft includes support for algorithm negotiation in a flexible way: clients check support in advance and they are able to select a suitable algorithm for each "piece" of the certificate. Therefore, this draft can save resources on both sides (client and server). - RFC 8555 does not clearly support issuing/revoking KEM certificates. This draft includes support for KEM certificate issuance and (now) revocation. It's simple, but it does not break compatibility with old clients. The procedures have optimizations available, depending on your use case. Changes based on comments/suggestions: - The algorithm name representation ( https://mailarchive.ietf.org/arch/msg/acme/OJk0_hmm7yp6sv_VJcJ_0qjL-YM/). I think it is better now. - Classical algorithms to the list ( https://mailarchive.ietf.org/arch/msg/acme/DYBAH5327vdB1iVVIXLYgTSPjPA/): It is easy to add classical algorithms to the list now. Some notes: I think that we could envision a more inclusive ACME by considering different types of clients. This way, TLS is better adopted in the different computing environments available. I think that our thoughts are somewhat focused on the "most clients ...." but this does not consider the "few", thus not being inclusive enough (or generic). Maybe a few clients require (or will benefit from) an ACME with better performance and/or support for different algorithms (e.g., KEMs), etc. But this does not mean that they should be neglected. For example, maybe KEMTLS is better in some scenarios, but if ACME is not "his friend", KEMTLS adoption will be difficult. Obviously, if the community perceives an overlap or preference for other proposals, I am still happy and will make myself available to help if needed :-). Also, if the community prefers, we can focus on the KEM part, i.e., "acme-kem-certificate draft" instead of "acme-pqcnegotiation draft". Best regards, -- Alexandre Augusto Giron Federal University of Technology - Parana (UTFPR <https://coenc.td.utfpr.edu.br/%7Egiron/>)
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
