On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi  wrote:
> Could you expand on this? It's not obvious what you mean.

I guess I was unclear. My concern was that one obvious way to approach this is 
to set things up so that after the certificate is signed, Boulder runs cablint, 
and if it finds anything wrong with that signed certificate the issuance fails, 
no certificate is delivered to the applicant and it's flagged to Let's Encrypt 
administrators as a problem.

[ Let's Encrypt doesn't do CT pre-logging, or at least it certainly didn't when 
I last looked, so this practice would leave no trace of the problematic cert ]

In that case any bug in certlint (which is certainly conceivable) breaks the 
entire issuance pipeline for Let's Encrypt, which is what my employer would 
call  a "Severity 1 issue", ie now people need to get woken up and fix it 
immediately. That seems like it makes Let's Encrypt more fragile.

> Could you expand on what you mean by "cablint breaks" or "won't complete in
> a timely fashion"? That doesn't match my understanding of what it is or how
> it's written, so perhaps I'm misunderstanding what you're proposing?

As I understand it, cablint is software, and software can break or be too slow. 
If miraculously cablint is never able to break or be too slow then I take that 
back, although as a programmer I would be interested to learn how that's done.
dev-security-policy mailing list

Reply via email to