Re:Maintaining Digital Certificate Security
by nickodell on Tuesday March 24, 2015 @10:34PM
(#9260947)
>DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency.
Better in what way?
Re:Maintaining Digital Certificate Security
by itistoday2 on Wednesday March 25, 2015 @06:01PM
(#9266275)
We wrote a blog post to answer this question: https://blog.okturtles.com/2015/03/certificate-transparency-...
Re:Maintaining Digital Certificate Security
by nickodell on Wednesday March 25, 2015 @10:20PM
(#9267448)
>The CT spec allows only one SCT to accompany a certificate, making this attack feasible
No, it doesn't. It describes the format of multi-SCT on page 16, and it explains the rationale for this (basically all of the points you brought up) on page 32.
Re:Maintaining Digital Certificate Security
by itistoday2 on Wednesday March 25, 2015 @11:53PM
(#9267729)
> No, it doesn't. It describes the format of multi-SCT on page 16, and it explains the rationale for this (basically all of the points you brought up) on page 32.
I see the wording wasn't very clear, so I removed the word "only" to make the meaning clearer. It now reads:
"The CT spec allows one SCT to accompany a certificate, making this attack feasible"
Good catch. :)
If you want to prevent MITM attacks, it's one of the only options available to you (probably the only realistic option):
https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
> However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1]
DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency.