Shibboleth Developers

["Scott Cantor" <>]

> I think what happens (from some observation and some poking around in 
> the source) is that when metadatatool and siterefresh verify the 
> signature on a metadata file against an external certificate, they only 
> verify that the signature on the file has been made with the private key 
> associated with the public key contained in the external certificate.

Correct.

> Some implications of this are:
> 
> The DN, issuer, validity dates and everything else in the external 
> certificate are ignored.  Only the public key is relevant to the 
> verification process.

Correct. It assumes you have a known-good key, and if you need a process to
establish that key, it doesn't handle that part.

> For example, this means that the external certificate can expire and 
> no-one will notice (I've been happily verifying InQueue metadata against 
> an external certificate that expired in September 2003; the external 
> certificate I have been using for InCommon is also out of date).

Normally, a signing cert ought to be like a CA and last a while, but this is
true.

> Similarly, the external certificate might not be self-signed, but 
> verification doesn't require that the certificate chain for the external 
> certificate be presented.

Right. That's one reason I didn't want to do it, because not everybody might
be using a self-signed cert for metadata signing.

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

> The second question is whether anything in the certificate (chain) 
> included as part of the digital signature itself is examined during the 
> verification process, other than again the public key in the end 
> certificate?

No, but I think the Java version has some internal code that I believe will
warn you if it has no verification key but notices that the internal
signature doesn't check out.

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

-- Scott