The annoying thing from a client author perspective is that their implementation is based on draft 01 despite draft 02 being published 8 days prior to their announcement. Worse, the TXT record format for draft 01 is incompatible with draft 02 and the post states they won't "make changes unless required by a final IETF standard."
So I guess clients are going to have to support draft 01 and 02+ in some fashion.
Despite being based on draft 01, I noticed that the implementation isn't technically complete. Specifically, the challenge object is missing the required accountUri field.
I haven't had a chance to test yet how or if they're handling wildcard validation at differing namespace levels (validation record living at example.com, but order request for www.example.com or sub1.sub2.sub3.example.com which are both supposed to work).
Create a draft 01 _validation-persist.example.com record with the policy=wildcard flag.
Request cert for sub1.sub2.example.com and/or *.sub1.sub2.example.com succeeds
I don't believe they're doing JIT validation. So the client still has to explicitly hit the challenge URL to trigger the check. But they must be walking the namespace from most specific to least specific. I'll need more time to actually verify that on authoritative DNS servers with logging enabled.
I checked the "minimal" profile and its default chain is the leaf and two intermediates. The size reduction is considerable vs "standard". Down to 3400 from 5270 (rounded) for a cert with a single short domain name.
There are also two alternate chains but I didn't retrieve those. I'd guess they'd provide the leaf and just one of the two intermediates of the default chain.
I thought LE was largely waiting on a solution to the problem of wildcard validation because they don't want to walk the namespace like Google seems to be doing. So the client needs a method to inform the ACME server where in the namespace to validate the record.
