On Sun, Aug 06, 2023 at 08:00:00AM -0300, Alexandre Augusto wrote: > > I would like to share our proposal for improving ACME with algorithm > negotiation support. The main features are: > - Flexibility: allows clients to know (in advance) if their desired > algorithm is supported by the server; > - Automated Issuance of KEM certificates: currently not supported in ACME, > our proposal specifies two ways to allow clients asking for such a > certificate. > > Link: https://datatracker.ietf.org/doc/draft-giron-acme-pqcnegotiation/ > > If there is any interest, doubts, please let me know. I'll be happy to > discuss it with you.
Some comments from quick read: 1) "/cert-algorithms" endpoint: This seems to run afoul of the prohibition of unprefixed fixed paths in HTTP (and ACME can not prefix its paths). The path of this resource would either have to be discovered via the directory, or its contents would have to be embeded in directory itself. 2) Algorithm representation: Why is the algorithm list a dictionary? And OID might not be enough to specify algorithm exactly. One possible presentation would be array of base64url encodings of X.509 AlgorithmIdentifier (including leading SEQUENCE tag). E.g., for NIST P-256 keys: "MBMGByqGSM49AgEGCCqGSM49AwEH". The LAMPS WG has decided that generic composition is too complicated. 3) 3-RTT versus 1-RTT: ACME is not exactly a high-performance protocol, so optimizing round- trips does not do much. However, things are very different from server point of view. It could be very much worthwhile to optimize how much state does the server have to hold. 4) Signature in KEMTLS CSRs: Is the signature to be just ignored on the server side? If it is, best for client to send as short signature as possible. AFAICT, the shortest possible signature is empty bit string made using algorithm with OID 0.0 and absent parameters. 5) How does server signal the key confirmation requirement: What should the CSR submission return if key confirmation is required? 6) "/key-confirm" endpoint: The same problem as in 1). Maybe the key confirmation could be re- posted into the CSR submission endpoint? Possibly in a way that does not require server-side state? 7) 1-RTT mode: I don't think this mode makes much sense. The certificate gets issued, and if the client does not have the private key, the certificate would be useless anyway. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
