InlineX509DataProvider skips credential extraction if only X509SKI is present

[Andreas Hartmann]

Hi Scott,

thanks for your quick reply!

Am 21.12.12 16:25, schrieb Cantor, Scott:
> On 12/21/12 8:47 AM, "Andreas Hartmann" <andreas at apache.org> wrote:
>>
>> were're receiving a SAML response containing a signature with the
>> following KeyInfo. IIUC the spec [1] correctly, this should be valid.
>
> It's valid in general, but it has no validity under the metadata profile
> used by the inline trust engine. Nor is it supported by the PKIX engine.
> So it's moot in the context of the code presently.
>
> I'm not saying we couldn't have supported it, but it isn't supported now.
>
> Additionally, the spec you're talking about in [1] is nothing we have ever
> tried to support or claimed to support. I was actually against using
> X509SKI in it at the time, because I wanted it to be consistent with
> Metadata IOP since it was more or less addressing the same use case in the
> context of a different profile. I knew if it went forward with X509KI,
> we'd probably run into a mismatch at some point.

Thanks for clarifying.

>> The signature validation fails. Apparently the InlineX509DataProvider
>> skips processing because it doesn't find any X509Certificate elements.
>
> The trust engine is ultimately using a variety of KeyInfo extraction code,
> not just X509Certificate. But I don't think the SKI is supported, no.

I hope that the ExplicitKeySignatureTrustEngine will still be able to 
validate the signature by falling back to the trusted credentials. I'll 
investigate why this fails at the moment.

-- Andreas