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