<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 25, 2016 at 9:48 PM, Francisco Corella <span dir="ltr"><<a href="mailto:fcorella@pomcor.com" target="_blank">fcorella@pomcor.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>[...] remarkable advantages.  In particular, the verifier can validate<br></div><div>a certificate chain on its local copy of the blochain</div></div></blockquote><div><br></div><div><div class="gmail_quote"><div>The disadvantage is every client needs a copy of the entire blockchain / log. There's already a system in place that works much like a blockchain for certificates: Certificate Transparency logs:</div><div><br></div><div><a href="https://mikecborg.wordpress.com/2016/10/25/googles-ct-logs-and-purposes/">https://mikecborg.wordpress.com/2016/10/25/googles-ct-logs-and-purposes/</a><br></div><div><br></div><div>Unfortunately these logs have such high volume that nobody but Google can presently operate one capable of handling Let's Encrypt, let alone trying to push that volume of data out to every client so they have a local copy of every certificate.</div></div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div> without any network access</div></div></blockquote><div><br></div><div>What's the use case? I'll note with OCSP stapling a client can validate a certificate chain with only network access to the destination service whose certificate they're trying to validate. You seem to be talking about verifying certificates in a context where you aren't even trying to initiate an SSL/TLS connection?</div><div><br></div><div>-- <br></div></div><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>