InlineX509DataProvider skips credential extraction if only X509SKI is present

[Cantor, Scott]

On 12/21/12 3:41 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Right, it's not supported out of the box.  The provider-based KeyInfo
>impl is pluggable and could easily be made to support SKI via a plugin.
>We don't supply one because this is one of the key-by-reference cases,
>which requires some sort of key/cert store, indexed by appropriate
>mechanisms to allow lookup via the reference.

That¹s true of some use cases, but I think there are scenarios involving,
say, comparison of a "trusted" SKI against a credential used to sign a
message, and that wouldn't require independent storage.

For example, we could have implemented this for use with the PKIX engine,
where you'd put the SKI in metadata, and then require that the signing
cert have the same SKI.

With this use case, there would be a desire to have the
SubjectConfirmationData carry the SKI and then require that the client
cert match it.

So it isn't necessarily a desire to turn the SKI into a cert, but rather
extract the SKI and then compare it to what's used in the message. In the
case of the SP, I do this with KeyName in the PKIX case. It's not a
perfect fit, but that's how the CredentialResolver interface works. It can
return certs or keys, but also "references" like a name that can be
evaluated against the message. This would be a similar model.

How easy it would be to do any of that in the OpenSAML code now, I don't
know.

-- Scott