Should we drop the SSL certificate bundle?

[Rolf Eike Beer]

Brad Hards wrote:
> On Thursday, August 19, 2010 08:18:17 am Rolf Eike Beer wrote:

> > -is there any policy written down when a certificate is accepted? I
> > searched a bit for "kssl" bugs and found e.g. 175651 where one new root
> > was accepted (but bug is still open for what reason?) and 219508 where
> > there was no further action (ok, these bugs can not really be compared
> > for themself, but you should get the idea). So: when do we accept a root
> > certificate? Where is the policy written down? And who watches on this?
> 
> The rough policy is "Mozilla or IE", and they get added whenever I get
> enough enthusiasm to do so. I won't add certs unless the CA requests it
> (i.e. user request is not enough) - we can't ship certs without the
> copyright holder's approval.

Don't get me wrong here about CAcert: I like what they are doing and I'm 
assurer myself. But I can absolutely live with adding their root to my stores 
until they finally finish their audit or whatnot. For this mail (thread) it's 
just a not so random example as it's the CA I usually add. It could have been 
a private CA of my employee (if there were such a CA) or whatever. No more, no 
less.

CAcert has an explicit license for their key allowing us to ship them. And if 
you would accept them it should be no problem to get a proper request from 
them.

Otherwise: do CAs really care? Are we important enought that there is more 
than the one CA from that one bug report that cares about KDE at all? I'm just 
curious.

> I also won't add certs with very short key length.
> It isn't written policy - it was developed by George Staikos and handed
> down to me.

I think that should be fixed ;) If I would be a CA I would probably not know 
how to get into KDE or what to do. I think there should be at least a techbase 
page on this, better to be moved to a "real" website directly on kde.org later 
(I wouldn't want to trust a wiki on such essential things as a CA).

> > -if the policy is just "do what at least 2 other browser vendors do" then
> > why don't we get an agreement with e.g. Mozilla dudes to just use their
> > store?
> 
> We could do that, but there are roots in our store that aren't in Mozilla
> for a combination of historical reasons.

I'm not asking to remove anything.

> > -every time I upgrade my KDE I have to re-add CAcert roots to my ssl
> > store as the old one gets replaced (not to blame KDE so far). For a long
> > time in KDE4 it was not possible to add new CAs to the users store
> > (tracked by 162485 besides a ton of other stuff IIRC). Since all my
> > boxes have the CAcert thing added to the global store I can not test
> > right now. Maybe after 4.5.1.
> 
> There are two issues - what goes into the bundle we ship, and what else KDE
> can do with certs. I can only address the first one.

Sure.

> On the specific issue of CACert - it can go in if it meets the other
> criteria. No special treatment.

I'm sure they are working on that ;)

> > I think I start to repeat to tell my positions from different angles. Ok,
> > let's shorten this:
> > 
> > -do we have a policy for our certs? If yes, which one?
> 
> See above.
> 
> > -do we _really_ want to care? For Mozilla SSL/TLS is essential. For KDE
> > software it's just a small part as we have so many libraries and
> > applications in our stack.
> 
> I'd like to see it come from Qt (where our TLS comes from). Thiago was
> looking at this problem.

That sounds reasonable.

> > When we do our own bundle we must do it really good, i.e. with extremely
> > careful checking of what we add, strict policy, you name it. Otherwise
> > it's just not worth the effort IMHO.
> 
> I'm not sure if this is a criticism or not. Do you have a problem with
> anything I've added?

No, not at all. It was just sort of a braindump.

Some time ago a discussion came up (i18n-doc or so?) to rely on an external 
package for country names and their translations so we don't have to duplicate 
work. This is basically the same question here for SSL: do we get any benefit 
if we duplicate the work of someone else?

> > Isn't it enough if we just rely on the global store? For Un*x system that
> > should be really easy, the distributor just has to change the path of the
> > default kssl store to the global one and is done. For Windows, well, I
> > don't know. Probably not that straightforward. In doubt the distributor
> > (the KDE windows team in this case) still would have the option to just
> > grab any randomly (or more carefully) chosen root store (e.g. the Mozilla
> > one, the Debian one, the what-do-I-know one) and deliver that.
> 
> They still have this option.

Of course. If I were a packager I would fear that would be seen as an 
unfriendly act ;)

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100819/d5386a8e/attachment.sig>