On Mon, 30 Nov 2015, Tim Ruehsen wrote:

What sort of problem do you see with this?

I already gave a scenario where the requested change is dangerous. If you think it is not appropriate, please give some arguments.

(Let me preface this by saying that I'm not a TLS expert.)

You mentioned a case where the root CA was compromised as a reason. Can you elaborate on how such a situation would be relevant?

We've seen compromised CAs several times in the past few years and we've seen CAs do (stupid) mistakes. Comodo, diginotar, symantec and more.

In neither of those cases they would suddently populate my CA bundle with a new faulty cert. Also, in neither of those cases (to my knowledge) would trusting an intermediate CA had made the situation much different. In all those cases the CAs handed out certs to sites that they really shouldn't have and thus the already present root certs and intermediate certs were unmodified. (Some of them were later removed and/or blacklisted, but that's a slow process.)

I think the perfect remedy for a client to detect those things are cert pinning (ie detecting when a site changes its cert) and possibly oscp stapling. A remedy for a wider scale detection of these compromises is Certificate Transparency.

Or am I wrong?

We don't normally fear adding options in libcurl, but this is a very
specialized option that very few users would know how to handle.

??? IMO, Reiner and Petr know what they want - and they seems to be the only ones who needs this feature so far. Why do you think they can't handle a CLI option ?

They would be examples of users in the subset of humans that understand this topic and would understand what such an option does. The vast majority of (lib)curl users have much less knowledge of protocols in general and TLS in particular than Reiner and Petr. And in fact than most people who subscribe to this mailing list.

--

 / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Reply via email to