On 6/4/10 9:15 AM, Pellerin, Clement wrote:
What is the recommended way to implement a KeyResolver for an EncryptedKey
where the KEK is a PublicKey?
At first I thought I could write a Resolver for the KEK PrivateKey and let the
EncryptedKeyResolver call it.
Unfortunately, the KeyResolverSpi API can return a SecretKey but there is no
provision to return a PrivateKey.
Can we augment the KeyResolverSpi with a new method
engineLookupAndResolvePrivateKey()?
This method would be called by the EncryptedKeyResolver when it detects the
KeyWrap algorithm rsa-1_5
or rsa-oaep-mgf1p. This change looks possible since KeyResolverSpi is a class
not an interface.
I think the only way to do what you're asking for would be to add the
additional methods to KeyResolver and KeyResolverSpi. Since the
KeyResolverSpi is an abstract class, adding a no-op
engineLookupAndResolvePrivateKey and engineResolvePrivateKey wouldn't
break API compatibility with. Same with adding the analogous
resolvePrivateKey method on KeyResolver.
In the meantime, I tried to replace the EncryptedKeyResolver with my own
implementation.
Again, I've hit a problem because I need the symmetric key algorithm.
Normally this is passed to the constructor of a temporary EncryptedKeyResolver
in the method
XMLCipher.decryptToByteArray():
ki.registerInternalKeyResolver(
new EncryptedKeyResolver(
encryptedData.getEncryptionMethod().getAlgorithm(),
_kek));
As you can see, the constructor is called directly.
If you don't like my idea of a PrivateKey resolver, can we at least move that
constructor call
to a new protected method on XMLCipher so we could override it in a subclass?
Whether a private key resolution method was added to the KeyResolver I'd
recommend moving the construction of the KEK resolver to a method
anyways. Given some of the complexities surrounding key resolution
within XML encryption it's certainly not hard to imagine some else down
the road will need a hook like that.
--
Chad La Joie
http://itumi.biz
trusted identities, delivered
