I have two main pieces of feedback on this draft, which unfortunately are rather large / sweeping and would require rethinking the whole document to address.
1) The algorithm negotiation mechanism is too specific. Why should ACME add new API endpoints dedicated solely to listing the public key algorithms that the server supports when we know that there are many other aspects of certificates (validity periods and extended key usages to name two simple examples) that clients also might want to discriminate on. ACME doesn't need a key negotiation mechanism, it needs a profile advertisement mechanism, a concept which has been discussed multiple times before <https://mailarchive.ietf.org/arch/msg/acme/BLVAayrTrUCegT4s2twci3Q2BY8/>. 2) The proof-of-control mechanism for KEM pubkeys is too specific. ACME already has an extensible mechanism for proving control over various entities. Rather than adding a new /key-confirm endpoint that needs to be POSTed to in the midst of finalization, simply define a new identifier type for KEM keys and a new Challenge type that uses Encaps/Decaps to prove control over the key. Then new-order requests can simply include the desired key, the proof-of-control challenge can be completed asynchronously, and at finalization time the server can simply confirm that the CSR contains the same key as was included in the initial new-order request (as it does for SAN identifiers today). The matter of revocation for KEM certificates is interesting. But note that ACME supports multiple methods of revocation: the revocation request doesn't have to be signed by the certificate private key, it can instead be signed by the original issuing account key (which still works with certificate KEM keys), or it can be signed by an account which *controls one or more identifiers in the certificate*. So with my suggestion from (2), keyCompromise revocation can be accomplished by proving control over the KEM key just like for a normal issuance, then requesting revocation with the normal ACME account key. Finally, the "1 RTT" mechanism for confirming control over the KEM private key (i.e. encrypting the final certificate to the KEM key so that the applicant cannot access the certificate unless they have the private key) simply doesn't work in the WebPKI. The WebPKI requires that all issued certificates be logged in Certificate Transparency logs, so the certificate will be publicly available in plaintext for anyone (including the original requester) to access. I'm excited for ACME to adapt to the world of post-quantum cryptography, and I look forward to future drafts of this document integrating better with existing ACME mechanisms. Aaron On Fri, Feb 16, 2024 at 3:30 PM Alexandre Augusto < [email protected]> 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). > - 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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
