Subject: [KEYPROV] Key IDs: Local, Global, Virtual, or Certified?

From: Anders Rundgren <[email-masked]>
Date: Fri, 21 May 2010 06:45:37 +0200

For the [fairly unlikely] case that there will be another KEYPROV or OATH
effort the following may be worth reading...

I have encountered quite a bunch of rather fundamental questions that I
believe needs to be addressed at an early stage and one is how provisioned
keys should be identified by the issuer.

Using local ("native") key IDs does not appear to be a generally useful
option since this presumes either that the key container is fully owned
and known by the issuer (which seems hard to achieve for mobile phones),
or that the protocol would perform additional rounds in order to avoid
potential ID clashes.

Global key IDs obviously address this issue.  However, such a scheme
should [IMO] be complemented with a mechanism where you prove ownership
of the claimed name-space through [messy] trust decisions or that you 
ask the
[poor] user if they accept that a key is overwritten.

Due to this I have been playing with "virtual" key IDs that only have a 
meaning
for the actual provisioning session.  After the recent KeyGen2 revision 
where
E2ES (End-to-End Security) were added, virtual key IDs have evolved from 
being
"a bit cool", to become a corner stone of the design since it enables 
you to create
more efficient multi-stage secure provisioning protocols.  Defensive 
publication:
http://webpki.org/papers/keygen2/session-local-namespace-for-object-provisioning.pdf

Unfortunately neither local, global, nor virtual key IDs address 
post-provisioning
key management in a generic way since key management should only be
possible to perform if you can prove ownership to the key to be managed.
KeyGen2 have for this purpose since the beginning provided "certified"
key IDs in the form of X.509 certificates as a part of the key deployment
process, but that's something I have already written about before.

Anders