Key resolver in Decryptor

[Brent Putman]

On 2/26/15 11:04 AM, Sandy wrote:
>
>
> In case of Shibboleth IdP's response, the <EcryptedKey> element
> contains the <ds:KeyInfo> element as a child that contains the
> <X509Certificate> that helps resolve a credential from
> `LocalKeyInfoCredentialResolver`. In short, this is the exact case
> from the complex example for Decryption listed in the OSTwoUser
> manual here
> <https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaXMLEncryption>.

To be complete, that example illustrates support for the 3 main
EncryptedKey placement strategies that we support:

1) InlineEncryptedKeyResolver - what you're seeing our IdP do by default)
2) EncryptedElementTypeEncryptedKeyResolver - from the SAML 2 spec,
EncryptedKey is peer of EncryptedData
3) SimpleRetrievalMethodEncryptedKeyResolver


>
> In case of the third party IdP's response, the <EncryptedKey> element
> does not contain the <ds:KeyInfo> element as a child(but the
> <X509Data> element with <X509Certificate> is present as a peer
> element of <EcryptedKey>). Decryption fails in this case as it was
> not able to resolve a the credential from the supplied
> LocalKeyInfoCredentialResolver.



What you are literally describing doesn't sound like legal SAML.  I
don't see how the ds:KeyInfo could be the peer of the EncryptedKey and
be legal in SAML 2. Perhaps you mean it's the #2 case above, with the
EncyptedKey as a peer of the EncryptedData?  For that case, you'd just
need to be sure to supply the EncryptedElementTypeEncryptedKeyResolver,
or a chain containing it as illustrated in the example.




>
> However, when I use a StaticKeyInfoCredentialResolver(SKICR) in case
> of LocalKeyInfoCredentialResolver(LKICR), the decryption succeeds. Is
> there a way for the Decrypter to try both, i.e. try to resolve using
> LKICR, and if it fails, try SKICR?
>
> Sorry for the long post, but I thought that something along the lines
> of ChainingKeyInfoCredentialResolver should exist, but as it does
> not, either the above case is invalid and I'm missing something or
> there is some other way to achieve this.


Don't know what version of OpenSAML you are using, but: the
ChainingKeyInfoCredentialResolver didn't get added until v3.  I don't
think there was a conscious reasons, I think we just never had a use
case until v3.

Really, the only use case I know of for a chaining KICR with the Local-
one followed by a Static- or Collection- one would be to support
encrypting parties that don't supply any hints at all in the encrypted
structure as to the encryption key. In that case the decrypting party
basically either needs to know out-of-band which key pair(s) to use
(e.g. based on the other party's identity), or just needs to try all of
their candidate decryption key pairs.

I'm still not sure that you actually need it, but if you're using v2
you could try and pull the chaining code from v3 and make your own.  I
don't think it would be terribly hard.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150226/7c0c15eb/attachment.html