Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> > So the main question is: is this behaviour by design, and therefore 
> > unlikely to change in future releases?  Or is it a short-term limitation 
> > of the code likely to be augmented by additional checking at some later 
> > date?
>
> For out of band verification, I don't have any interest in changing it, and
> it's near the bottom of the list of things I have to worry about right now.
> But I have no idea what the 2.0 version of these tools will be. As much as I
> want to just have one Java tool, the problem is the runtime. It would be a
> hassle for people to have to install the JRE just to run it on an SP.

Understood.  But the current siterefresh tool treats things the same as 
metadatatool does?

> > Obviously from the first question we know that the end certificate 
> > doesn't have to resemble the external certificate except for having the 
> > same public key, but for example are its notOnOrAfter constraints (and 
> > those of the other certificates in the chain, if there is 
> > one) checked?
>
> I can tell you that across the system, anywhere the certificate is used
> solely for public key extraction, there is no evaluation of the certificate
> whatsoever. Only when PKIX code runs. 

By saying across the system, I think you're also talking about what the 
IdP and SP do when there is a KeyInfo with X509Certificate data in the 
metadata.

So, the only part of the X509Certificate that is used in the validation 
of assertions in that case is the embedded RSA key?  Everything else in 
there is just decorative?

Again, I'm interested in knowing whether this case is just-for-now or 
you might change it in the future (you say you're not interested in 
changing the out-of-band verification case, but I suppose this is the 
in-band verification case you excluded there).

If this also isn't likely to change, I am wondering why one would use an 
X509Certificate instead of, say, an RSAKeyValue element, which would 
presumably be a fair bit shorter?  I can see that might be an 
inconvenient value to derive if someone hands you a .pem file or 
whatever, but are there other reasons not to go there?

And, I suppose, this trail of questions would be incomplete if I didn't 
also ask in passing whether the current code base was able to process an 
RSAKeyValue if it saw one go by...

        -- Ian