You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Christian Geuer-Pollmann <ge...@nue.et-inf.uni-siegen.de> on 2002/10/01 11:17:19 UTC
KeyResolverContext porposal
Hi Axl,
hi all,
one idea for you which is probably interesting: What about a
KeyResolverContext ;-))
When using ds:KeyInfo elements, there can be identifiers like ds:KeyName
which do refer to some specific key, whereas they do not define *which*
type it is, e.g. AES/128, RSA, DSA or RC4 key. Additionally, the meaning of
a KeyName depends heavily on the context, i.e. which are the communication
partners.
<ds:KeyName>key number one</ds:KeyName> can refer to key_1 when Alice sends
Bob a message and refer to key_3 when Alice sends Carol a message. So an
intelligent key management is an issue.
Additionally, the ds:KeyName can contain arbitrary Unicode sequences,
including whitespace, which means that
<ds:KeyName>foo</ds:KeyName>
and
<ds:KeyName>
foo
</ds:KeyName>
refer to *different* keys.
Imagine you have an object like a KeyResolverContext which acts like a
KeyStore: You can bind java.util.Key objects to ds:KeyInfo structures and
supply this object to a signature or encryption object in order to allow it
to find the appropriate keys. And, like a KeyStore, you can supply a
passphrase so encrypt/MAC it to save this object to an octet stream. This
would mean that applications can easily handle symmetric, private and
public keys as well as key agreement parameters and certificates in a
single object which serves as a container for a key management context.
What do you think about that?
Christian