[prev in list] [next in list] [prev in thread] [next in thread]
List: shibboleth-dev
Subject: Re: Key resolver in Decryptor
From: Brent Putman <putmanb () georgetown ! edu>
Date: 2015-02-26 18:32:41
Message-ID: 54EF66C9.6000409 () georgetown ! edu
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
[Attachment #5 (text/html)]
<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>
--
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic