Shibboleth Developers

[Ian Young <>]

I'm working on some stuff related to metadata signing, and I'd like to 
get a quick sanity check on a couple of details.

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.

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.

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

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

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?

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?

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?

        -- Ian