You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@santuario.apache.org by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org> on 2010/12/07 13:06:10 UTC

[jira] Updated: (SANTUARIO-229) Cannot resolve PrivateKeys used in Key Transport algorithms

     [ https://issues.apache.org/jira/browse/SANTUARIO-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh updated SANTUARIO-229:
------------------------------------------

    Fix Version/s: Java 1.4.4
         Assignee:     (was: XML Security Developers Mailing List)

> Cannot resolve PrivateKeys used in Key Transport algorithms
> -----------------------------------------------------------
>
>                 Key: SANTUARIO-229
>                 URL: https://issues.apache.org/jira/browse/SANTUARIO-229
>             Project: Santuario
>          Issue Type: Bug
>          Components: Java
>         Environment: Operating System: Windows NT
> Platform: PC
>            Reporter: Clement Pellerin
>             Fix For: Java 1.4.4
>
>         Attachments: diff.txt
>
>
> Created an attachment (id=25632)
> source code patch with new junit
> During decryption, XMLCipher needs to find the key to decrypt an encrypted key. The kek can be provided by the caller, otherwise XMLCipher can call the KeyResolvers to resolve the kek. The KeyResolvers work fine if the Key Encryption Key is a symmetric key because the SecretKey can be returned by KeyInfo.getSecretKey(). When the Key Transport algorithm is RSA-1.5 or RSA-OAEP, the key we need is a PrivateKey and there are no calls that can return an object of this type.
> To reproduce use the junit included in the source patch attached to the bug.
> The solution is to introduce a new method called engineLookupAndResolvePrivateKey() in the KeyResolverSpi base class. The new method returns a PrivateKey. In XMLCipher, we now check which algorithm was used to encrypt the key, and if the kek type is RSA, we resolve a PrivateKey instead of a SecretKey.
> Notice the StorageResolvers have no way to return a PrivateKey either.
> To avoid controversy, the proposed solution does not affect StorageResolver. The custom KeyResolver implementing engineLookupAndResolvePrivateKey() must know a source of PrivateKeys other than StorageResolver. This explains why the StorageResolver argument of engineLookupAndResolvePrivateKey() is always null.
> The hope is that one day new APIs will be added to StorageResolver and we'll be able to pass StorageResolvers in the existing argument.
> This solution does not depend on SANTUARIO-227, but both are needed to allow PrivateKey KeyResolvers per KeyInfo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.