Agree with many of the comments made by Scott.
In the architecture of StrongKey (www.strongkey.org), a symmetric
key-management software, we've created the concept of a Global Key
ID (GKID) to identify every symmetric key used to encrypt something.
We chose to use the XML Encryption schema for encrypted content, &
since XML Encryption uses KeyInfo from the XML Signature namespace,
we had to come up with a "standard" for the KeyName - and GKID was
it. Now, within the confines of a given Symmetric Key Management
System in an enterprise, an application using the StrongKey API will
know where to get the symmetric key, as well as which key to get:
..
<ds:KeyInfo>
<ds:KeyName>1-10</ds:KeyName>
<ds:RetrievalMethod>
http://localhost:8080/symkeyServlet/getsymkey
</ds:RetrievalMethod>
</ds:KeyInfo>
..
So, Scott is right. There are no rules about these things yet,
but we're sort of trying to create some standards for symmetric
key management services through OASIS (see details on EKMI-TC at):
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi
Arshad Noor
StrongAuth, Inc.
Scott Cantor wrote:
I'm working on signing an XML document using a X509 certificate. As
part of the signing process, I am appending DSIGKeyInfoX509 information
in the signature (by calling appendX509Data on the DSIGSignature
object). Once that is there, I am manually adding the name of the
certificate, and then using that name to find the certificate when
verifying.
Name meaning...? There aren't really any names that unambiguously work in
the absence of a specific context. DNs are useless as there is no global
PKI, so names are always relative to a deployment scenario.
Is there a standard as to what types of information should be stored
there?
No. Embedding certificates is far and away the most common approach.
And once the data is stored, is there an automated way of
loading the certificate based on the data?
Most libraries provide some kind of key resolution mechanism. This one
includes a KeyResolver abstraction that returns a key based on a KeyInfo
object, and supports a couple of basic types when the key is inside the XML.
This is useless for real applications, since it just verifies the signature
with a key that is self-evident, but doesn't authenticate the message.
My OpenSAML project includes a ton of additional code around resolving
KeyInfo material into credentials and applying trust mechanisms. It's
extremely complex territory and there are no specs to follow. Shortcuts and
laziness abounds.
-- Scott
