Dear community, Thank you for the feedback. I am compiling the suggestions and changes to the I-D. From what I understand, mainly: 1. The I-D naming using "PQC algorithm negotiation" could be generalized to a "profile" selection; 2. Proof-of-possession for the KEM private key does not need to be addressed by this I-D (it seems to be a problem for revocation, not for algorithm selection);
Other details: - Add/cert-algorithms to the directory: Yes, this is the original plan. Thanks for pointing it out, we should clarify this in the draft; - Change the algorithm representation dictionary: Yes, the I-D proposal followed the JSON notation, but we could change it to something more convenient. We need something to represent the possible options (KEMs, signatures, hybrids). Also, for flexibility, we could consider something like a Kyber512 web server key signed by a Dilithium2 ACME server key (i.e., the client selecting the algorithm that the CA is signing). - 1-RTT mode (encrypting the cert) would not work with CT logs: yes, that is true. Maybe changing how the log works is not feasible, or we would have to consider different ACME use cases (in which there is no CT log). On the other hand, if the community does not agree with this mode, we can remove it. 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
