On Tue, Sep 19, 2017 at 03:34:50PM -0500, Logan Widick wrote: > Would it be possible to extract the key and identifiers from the CSR, add > the key to the database if it doesn't already exist, find or create the > authorizations for the identifiers, not store the CSR, and then assemble > the certificate from the (valid) authorizations and key later?
Most CSRs have fresh keys that are never reused (thanks to forced key- rotation[1] in most ACME clients). > Alternatively, could one get rid of the CSRs altogether, and have the > new-order be a nested JWS? The inner JWS would be signed by the key that > goes on the certificate and would contain everything required to generate > the certificate (identifiers, requested dates if applicable, etc.). The > outer JWS would be signed by the ACME account key and link the inner JWS to > the ACME account. Using the private key to sign a JWS is cryptographically very much non- kosher. Also, some systems can emit CSRs for non-exportable key. With those, you are SoL unless you can send a CSR to the CA. > What goes in a CSR or certificate that can't be reconstructed later? For Let's Encrypt, AFAIK the only things in CSR that matter are: - Requested domains - Public key - Signature (to verify proof-of-possession). [1] Even if the client has mode that does not rotate the keys, that mode is in most of the clients somehow crippled, so it does not actually work well. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
