Hallo Philipp On Thu, 2009-06-25 at 13:20 +0200, Philipp Kern wrote: > But now you also raise another > certificate authority... What do you mean? GridKa-CA?
> How would the certificate be used? Sadly I don't know how those grids > work[*]. Would users need the certificate installed or somehow the > individual nodes? (As for the latter they can be put into > /usr/local/share/ca-certificates with the newest version.) Both,... in principle there's nothing special about Grid-Certificates... you give them to hosts,.. and to users (and sometimes even to services),.. and they're used to authenticate to each other. What do you mean, should be put under /usr/local? > Well, it's X.509. Unfortunately ;) > I won't include every intermediate root out there. > I'm already happy that DTAG will be included in nss for Firefox 3.5, > so that I can get rid of that certificate in ca-certificates. > That's also why your Mozilla root example doesn't hold at all. It's > not > how X.509 works. In this case Mozilla would not only sign the other > roots but issue them. There is no real cross-signing facility there. > I'm also not happy that I cannot assign trust values to certificates > like Mozilla does in their truststore, so this is kind of best effort. Uhm,.. perhaps the problem is, that I'd expect something different from ca-certificates, that it actually is. In principle I'd like to have the following (please don't feel offended,... I'm not wanting to tell you how to do your job ;)): ca-certificates: Should perhaps only contain the infrastructure, like man-db for manpages Another package, e.g. ca-certificates-data, could contain CA-root-certs, that have been "validated" by Debian, e.g. : ca-cert Verisign/thawte DFN several goverment root CAs etc. etc. This package could also contain some information, how each root-cert was "validated", e.g. - simply downloaded from their webiste - verified by personal meeting between Debian developer X, Y and Z with Verisign representative A, B and C on April 1th 2000 in Munich. - compared with the version that is distributed by Mozilla and/or Microsoft and/or Terena Tacar - etc. A user could then choose which ones he want to activate. Of course this would probably a major rewrite of the ca-certificates package :-/ But from a security point of view, I think that's not the best way to delegate the "trust-work" to e.g. Mozilla, or Deutsche Telekom, when it goes about validating other Root-CAs Of course you're right,.. we cannot/should not include every intermediate CA, but here I'd say the following: For example DFN is clearly not intermediate,... it's an own PKI-hierarchy. It's sub-CA's (e.g. the CA's of most German Universities) _ARE_ intermediate CA's, because they all follow the same policy. So perhaps it would be good to differ between CA and PCA (Policy CA), like DFN does: CACert, Verisign, thawte, Deutsche Telekom, DFN, or e.g. Germanys Bundesnetzagentur (the top-authority for Germanys digital signatures) are PCA's But LMU-CA, TUM-CA (CA's from German Universities below the DFN hierarchy) or CA's below the Bundesnetzagentur are only intermediate CA's and should thus not be included. There _can_ be examples where it makes sense to even include intermediate CAs (IMHO). StartCom is proably a PCA,.. but it provides the XMPP intermediate CA, which gives free server certs for Jabber-Servers. As this cert is probably needed by most Debian-Jabber-Admins,.. it may be ok to include it. Best wishes, Chris. > [*] Despite being a student in Karlsruhe. Oh well. It's not that you > would get access to such things easily. ;-) I'm not fully sure,.. but I think they're still have one or two open positions at GridKa ;)
smime.p7s
Description: S/MIME cryptographic signature
