On 11/09/2017 02:18 PM, Richard Barnes wrote: > Since people don't seem happy about either of these alternatives > (identifiers+CSR because of legacy issues; CSR+CSR because of > fragility), here's one last attempt at a different approach: > Draft PR: https://github.com/ietf-wg-acme/acme/pull/350
I think this approach complicates things unnecessarily. My feeling of the list is that CSR+CSR has reasonable support as a compromise solution. Hugo said it's "quite clumsy", and Eric said "seems like a great opportunity for defects." I think we can reduce (but not eliminate) the chance for defects by saying the initial CSR and final CSR MUST be identical; then Let's Encrypt can store a hash (32 bytes) rather than the full hash. I still think identifiers+CSR is better, in particular because what I've heard from a few CAs is that they generally ignore everything in the CSR except the public key, and this approach mirrors that one more closely. But ultimately finding an approach that works well enough is better than stalling out trying to find a solution that everyone finds ideal. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
