On Fri, Feb 16, 2024 at 08:29:00PM -0300, Alexandre Augusto wrote: > 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).
Account signatures always use JWS, so those should use JWS mechanisms for specifying the algorithms, not OIDs. However, There is an issue with using JWS alg values: "EdDSA" is not an algorithm. However, JOSE WG is working to replace that by "Ed25519" and "Ed448", both of which are algorithms. How is client supposed to use the certificate signature algorithm information? I do not think there is any facility in ACME that would let client affect signature algorithm selection. The proposed profiles can affect signature algorithm, but do so in indirect way. For public key, a single OID is not enough, because all generic ECC keys have the same OID, and the curve used is a parameter. It would be possible to give base64url encoding of the AlgorithmIdentifier for the key. > - 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. I don't think the proposed revocation mechanism can work. The problem is how ACME represents revocation by private key. That mechanism can only work for signature keys. And furthermore, there must be at least one JWS algorithm usable with the private key. I think making revoking KEM certificates using private key would take a whole new revocation endpoint. One could also use this to solve the algorithm issues caused by using JWS signatures instead of TLS signatures. Every key type usable in TLS is guaranteed to have TLS signature scheme, but is not guaranteed to have JWS algorithm. And instead of screwing with CSRs, I think it would be better to get rid of CSRs altogether and transmit the information in NewOrder request. The ACME server could then use challenge mechanisms on the certificate key, depending on its policies. This would solve many annoying issues in ACME. > 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. I don't think performance of ACME matters very much, as long at is not very bad. E.g., I think 5 seconds and 20 seconds is not a major difference, but 10 seconds and 10 minutes might very much be. Most ACME clients are effectively single-threaded, working on one order at a time. There are multiple annoying race conditions in ACME that a multi-threaded client would have to deal with. And synchronization mechanisms for solving those are not trivial. 20 seconds per cert with average 60 day replacement period still works with 250K certs. I think that anybody that comes even close to that is going to use highly custom stuff. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
