[Proposal] KeyResolvers

["Pellerin, Clement" <Cl...@ibi.com>]

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.

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?

RE: [Proposal] KeyResolvers

["Pellerin, Clement" <Cl...@ibi.com>]

>> From: Pellerin, Clement 
>> What is the recommended way to implement a KeyResolver for an EncryptedKey where the KEK is a PublicKey?
>> ...

If the library already supports my use case, I would be thrilled to learn how to use it correctly. 
Otherwise I would like to implement the solution in Java and donate it to Apache XML Security.
What can I do to get this started? Should I skip the design review and ship a patch instead?
Would it help if I logged a bug to begin with?

RE: [Proposal] KeyResolvers

["Pellerin, Clement" <Cl...@ibi.com>]

On June 14, 2010 10:30 AM, Clement Pellerin wrote:
> Now that we know X509IssuerSerialResolver must resolve PrivateKeys, where does it get it from?
> I believe the answer is: the same place where it gets the list of certificates.
> My proposal is to augument the StorageResolver to return an iterator that iterates over the PrivateKeys.
> For completeness, we would need a third iterator for the SymmetricKeys.

This was a nice attempt except it does not work. For the KeyResolver to work, it must match the information
in the message against the PrivateKey. Unfortunately, the PrivateKey is not self describing.
This works when the KeyResolver is looking for a Certificate because the certificate contains a lot
of information about itself, like the SubjectDN, the IssuerDN, etc... None of that is present in a PrivateKey.
The closest we can do is to let the StorageResolver iterate structures similar to KeyStore.PrivateKeyEntry.
This would have to be our own class to be compatible with JDK 1.4. I'm not convinced anymore.

Should we consider the StorageResolver to be a simple CertStore iterator and leave it alone?
How about adding a second constructor to each X509 KeyResolver to pass a KeyStore?

RE: [Proposal] KeyResolvers

["Pellerin, Clement" <Cl...@ibi.com>]

On June 11, 2010 5:56 PM, Chad La Joie wrote:
> 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.

This validates my approach.

I would like to point out something about the new factory method to create the EncryptedKeyResolver. XMLCipher already has many similar methods but they are all for interfaces. This would be the first factory method to create a class. Other classes could also make use of a factory method. I can think of KeyInfo for example. XMLCipher.createKeyInfo() would be a great hook to attach thread-specific KeyResolvers.

Once the KeyResolver can return a PrivateKey, we have to ask ourselves where does it get it from. My first reaction was to write a KeyStoreKeyResolver that would know how to find a PrivateKey within a KeyStore passed in the constructor. I soon realized this collided with the existing KeyResolvers. It makes more sense to extend the existing KeyResolvers to resolve PrivateKeys than to introduce a super KeyResolver that knows how to return a PrivateKey for any kind of hint. KeyStoreKeyResolver was dead born.

Now that we know X509IssuerSerialResolver must resolve PrivateKeys, where does it get it from? I believe the answer is: the same place where it gets the list of certificates. My proposal is to augument the StorageResolver to return an iterator that iterates over the PrivateKeys. For completeness, we would need a third iterator for the SymmetricKeys.

When I looked at KeyStoreResolver, I was surprised to find it is not thread-safe. The code expects the user to be single-threaded or else it must create a new StorageResolver and a new KeyStoreResolver each time. I think this is very error prone. It is very tempting for the user to create his StorageResolver once and reuse it all the time. I suggest we make StorageResolver.hasNext() and next() deprecated. I also suggest a new iterator should be returned every time StorageResolver.getIterator() is called. Similarly, a new iterator should be returned every time StoreResolverSpi.getIterator() is called (see KeyStoreResolver for example).

Re: [Proposal] KeyResolvers

[Chad La Joie <la...@itumi.biz>]

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