On Thu, 2009-06-25 at 13:54 +0200, Philipp Kern wrote: > > What do you mean? GridKa-CA? > Yes. Well the Grid-CA's are generally another problem,.. there are so many of them,.. and there are many "political" hierarchies (see the private eMail I wrote you this night).
So for the German Grid-CA's we'd have about the following: IGTF | +-EUGridPMA | +-DFN Grid +-GridKa-CA But this is (AFAIK) no technical hierarchy in the X.509 context. I mean there is no IGTF-CA or EUGridPMA-CA which sign the sub-CAs below. > > What do you mean, should be put under /usr/local? > The CA. Ok,.. but this would of course require complete local management and (more important) local verification if the root-CA is really the correct one. > > [ Snipping your ideas. ] > I'll think about it. Great :-) > > In the case of DFN I don't see it as DFN Global > is clearly a sub-CA of Telesec Well technically definitely,.. but I'm not sure if this also fully applies to the organisational/political point of view. I always had the feeling that DFN Global considers itself to be quite independent and largely autonomous from Deutsche Telekom. When you look at the policy (http://www.pki.dfn.de/index.php?id=policies) the Deutsche Telekom root-cert is only mentioned, and I always felt, that the only reason for having DFN Global signed by it was to get it accepted by the browsers withough paying for webtrust ;) So in principle I think DFN Global could decide (with a new version) to move away from the current model). > and needs to obey to their policies > (as well as their own). There are no further sub-CAs below that > because they would otherwise violate them. At least this is (as far as I understand) wrong: https://info.pca.dfn.de/ holds a list of CAs below DFN Global and thus below Deutsche Telekom Root 2 > > A package split would work. What I would get to is to have only > Mozilla's certs to be activated by default and maybe SPI's and leave > the others for the local sysadmin to activate. Well,... I mean I've told you my ideas before,.. and they would probably mean a lot of work. And perhaps it would even be necessary to discuss this in general with other Debian developers. I mean one thing I suggested was to move away from simply take the Mozilla-distribution... as I think Debian should check all this on it's own (no delegation). So perhaps to conclude: 1) split ca-certificates in a infrastructural package (ca-certificates) and one (or perhaps even more) "data"-packages, e.g.: ca-certificates-base: containing only SPI and/or Debian's own root-CAs ca-certificates-grid: containing Grid-Root-CAs ca-certificates-misc: containing Verisign, thawte, cacert, etc. Perhaps it would even make sense to move the ca-certificates-base directly into ca-certificates and use this name for the certs from -misc. 2a) No longer delegate the trust work to e.g. Mozilla. Debian should check whether a cert is really the root-cert from e.g. CACert itself and not trust others for this. I really mean only _checking whether a cert is the root-cert of some PCA. Not checking the policy itself, or giving a statement whether one can trust them. 2b) Giving information how these certs were "verified". 3) Make a "Debian-Policy" about which CA's can be included. e.g.: - no intermediate CA's from the same policy-hierarchy (where I'd say that e.g. Deutsche Telekom and DFN are different policy-hierarchies). - only important and wide-spread PCAs e.g. generally all governmental CAs, big players like Verisign, thawte, StarCom, etc. etc. > > > IMHO StartCom should already be included through Mozilla, no? Yes it is... Best wishes, Chris.
smime.p7s
Description: S/MIME cryptographic signature
