Key resolver in Decryptor

[Sandy]

Thank you Scott and Brent for your responses.

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.
>

True. Even the peer of EncryptedKey isn't <ds:KeyInfo>, but directly the
<ds:X509Data> element. It didn't sound valid. Am I correct in understanding
that the validity of the XML is governed by the XMLENC specification rather
than SAML? But given SAML spec follows XMLENC, it could be said this is not
valid SAML. This doesn't matter much, but I'm just curious.

I verified that this is not case #2. I see that <EncryptedKey> is within
<EncryptedData>. I also tried EncryptedElementTypeEncryptedKeyResolver in a
desperate attempt only to see the key resolution fail.

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 also reached the same conclusion. We are now using only
StaticKeyInfoCredentialResolver. For the record, we started our development
with OpenSaml v 2.4.3. So, we'll stick to SKICR until we upgrade to v3.

Regards,
Sundeep




On Thu, Feb 26, 2015 at 7:32 PM, Brent Putman <putmanb at georgetown.edu>
wrote:

>
>
> 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.
>
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150302/efd0476a/attachment.html