On 04/10/16 13:18, Nick Lamb wrote: > On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling wrote: >> Neither. I'd like to run cablint over all certs pre-issuance, but >> unfortunately it's not practical to do this yet because 1) cablint is >> too slow and 2) there are some differences of opinion that have been >> discussed at CABForum but not yet resolved. > > Can you expand on what "too slow" would mean here? Or does it tread too much > on specific commercial performance criteria you don't want to talk about?
Running cablint means firing up the Ruby interpreter, then fork/exec'ing a separate executable umpteen times. IIRC, last time I checked, crt.sh was only managing to cablint ~10 certs per second. (Prior to that, before I'd figured out a way to avoid having to take the "firing up the Ruby interpreter" hit again and again for every single cert, it was only managing to cablint ~3 certs per second). x509lint is written in C and uses the OpenSSL C API. IIRC, last time I checked, crt.sh was managing to x509lint ~100 certs per second. > AFAIR Comodo's CPS tells subscribers to expect to wait up to TWO days to > receive a certificate after completing validation etc.. Now I'm not crazy > enough to think Comodo is actually having ordinary subscribers wait around > two days, but an extra few seconds ought to be practical for real-world > certificate systems I'd have thought. It's easy to cope with our "normal" rate of certificate issuance. However, we need to avoid unacceptable backlogs (where "unacceptable" is defined by customer perception) when our high-volume customers request large batches of certificates. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
