[RRG] Node Identity, PKIs, and bindings between the two

[Randall Atkinson <rja@extremenetworks.com>]

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
rja@extremenetworks.com




--
to unsubscribe send a message to rrg-request@psg.com 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