Earlier, Pekka Nikander wrote: % But then you just shift the burden to the secrecy of the CA private % key. That is, if all keys are eventually compromised, what do you do % when the CA private key gets compromised? You have to reconfigure all % hosts, I guess.
There are several things to consider here. First, it is routine operational practice with CAs deployed today to have time limits on the validity of any given CA certificate. The operational practices *plan for* and actually routinely undertake CA rollover. The most obvious example on a MacOS X system is the relatively large number of (US) DoD CAs present in an Apple-supplied default Keychain, but the same basic operational practice is also used by commercial CAs. Second, and this is really the important point here, when the CA rolls over (or if it is compromised before rollover), a node using that CA ought NOT lose its identity due to that certificate/key-change event. Third, if a key is compromised in the model where the node identity is f(public key), then one STILL has to handle generation, configuration, and deployment of the new keys -- and the affected node(s) ALSO lose their identity. So the impact of a key compromise is much broader in such a case than if the node identity is not a function of the node's public key. % To me, it would be better to not to concentrate the trust too much. % If (manual) reconfiguration is inevitable, it might pay off to make % sure that a) its probability is minimised and b) when it happens, % only a small fraction of all hosts are affected. Hence, maybe % threshold certs at the top of the tree, or a forest instead of a % single tree, or both? Again, using the US DoD PKI as an example, and recalling that other PKIs have similar operational practices, there is a hierarchy for signing. I am told that the top-level and 2nd-level keys are never present in a system that has any external (e.g. network) connectivity. Further, those signing systems are physically very well protected from access. Such "offline signing" is being used for signing critical DNS keys, or so it has been claimed in presentations at various NOGs in the past year (and I think also at IEPG about 8 days back). Last, ordinary user certificates (could be node certificates if desired) are not signed at the top-level, but instead are signed by a key with a certificate below the top-level. Again, this facilitates recovery from either key compromise or key rollover. It also significantly reduces the amount of material signed by the top-level keys that an adversary could use to try to attack such keys. I am very far from being an expert on either X.509v3/PKIX, PKIs generally, or CA operations. So the above relies upon what I've seen (e.g. on my Mac), what I've heard from others (e.g. NOG presentations), and what is written in some RFCs (mainly PKIX-related). So I suspect that PKI-specific followups likely should be moved to the IETF PKIX list, where suitable expertise ought to exist, while architectural followups might belong here i(Routing RG) nstead. Cheers, Ran [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
