<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 2/26/15 11:04 AM, Sandy wrote:<br>
</div>
<blockquote
cite="mid:CA+4cBy4Y43N3OT_8p9U8X9DKsGJixOdMnhFJ8FnCWXyobP5VeQ@mail.gmail.com"
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 moz-do-not-send="true"
href="https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaXMLEncryption"
target="_blank">here</a>.<br>
</div>
</div>
</div>
</blockquote>
<br>
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<br>
<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<blockquote
cite="mid:CA+4cBy4Y43N3OT_8p9U8X9DKsGJixOdMnhFJ8FnCWXyobP5VeQ@mail.gmail.com"
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>
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>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CA+4cBy4Y43N3OT_8p9U8X9DKsGJixOdMnhFJ8FnCWXyobP5VeQ@mail.gmail.com"
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>
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>
</body>
</html>