InlineX509DataProvider skips credential extraction if only X509SKI is present

[Brent Putman]

On 12/21/2012 3:15 PM, Cantor, Scott wrote:
> 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.

Sure, I understand this aspect of using SKI + a PKIX-style trust 
processing model.  I was commenting mainly on what the poster was 
actually asking about re: the InlineX509DataProvider (which is a plugin 
component to the provider-based KeyInfoCredentialResolver) not doing 
anything with extracting and using the SKI in the Signature's KeyInfo.

> 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.

Right, I understand.  In Java OpenSAML, however, that processing would 
not involve any kind of Credential, nor any impl of the 
KeyInfoCredentialResolver, since a Credential is defined to be a key (by 
value), period.  A naked key reference (SKI, KeyName, X509IssuerSerial, 
etc) isn't a Credential by itself, at least in Java.  It can in theory 
be resolved into a Credential.  However that is not how this case would 
be processed. The PKIX trust engine would know how to resolve the 
"trusted" SKI(s) and then also know how to compare them to the  signing 
cert, which would have to be present in the Signature's KeyInfo.  IIUC 
the OP's case, his Signature's KeyInfo did *not* contain the cert by 
value, only the SKI, so this case is not really what he was talking about.


>
> 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.

I know the OP made reference to the HOK spec, but I didn't think the HOK 
aspect was what he was asking about, since his question was about the 
response signature.


>
> 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.

Yeah, this is one of those areas where the Java and C++ diverged. In 
Java, the PKIX Signature trust engine could theoretically do this, it's 
similar to the current KeyName case that we already support.  But it 
doesn't do it today by default.


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

In Java OpenSAML, I *think* both the components that lookup the trusted 
name info from metadata and which do the comparison inside the PKIX 
trust engine are pluggable.  So I think this could be done, but I've 
never looked at doing this case specifically.