<div dir="ltr">Thank you Scott and Brent for your responses.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br></blockquote><div bgcolor="#FFFFFF"><br></div><div bgcolor="#FFFFFF">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.<br><br></div><div bgcolor="#FFFFFF">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.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br></blockquote><div><br></div><div>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.<br><br></div><div>Regards,<br></div><div>Sundeep <br></div></div><div bgcolor="#FFFFFF"><br><br></div><div bgcolor="#FFFFFF"><br><span class="im"></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 26, 2015 at 7:32 PM, Brent Putman <span dir="ltr"><<a href="mailto:putmanb@georgetown.edu" target="_blank">putmanb@georgetown.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>On 2/26/15 11:04 AM, Sandy wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br>
<br>
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 <a href="https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaXMLEncryption" target="_blank">here</a>.<br>
</div>
</div>
</div>
</blockquote>
<br></span>
To be complete, that example illustrates support for the 3 main
EncryptedKey placement strategies that we support:<br>
<br>
1) InlineEncryptedKeyResolver - what you're seeing our IdP do by
default)<br>
2) EncryptedElementTypeEncryptedKeyResolver - from the SAML 2 spec,
EncryptedKey is peer of EncryptedData<br>
3) SimpleRetrievalMethodEncryptedKeyResolver<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<br></span>
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.<span class=""><br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>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? <br>
<br>
</div>
<div>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.<br>
</div>
</div>
</div>
</blockquote>
<br>
<br></span>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
</div>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div>