Shibboleth Developers

["Scott Cantor" <>]

> One of my next tasks is actually to find out where up-to-date 
> CRLs are used and/or needed in the shibboleth architecture.

Try here for starters:

https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/KeysAndCertifica
tes

I've updated it finally for 1.3, it was badly out of date.

> I know how to configure the apache side of the SP and IdP to 
> use CRLs when SSL (client authentication) is required and if and only if I

> get hold of all relevant CRLs of the certification chain/path.

No, you don't. ;-)

We don't use Apache anywhere for that anymore.

> As I currently understand the communication pattern of shibboleth, it
> additionally still needs to check for revoked server certificates on the
> client side of a https connection and also when the certificates are used
> for verifying received signed SAML messages.

Yes, and this is done by embedding X509CRL elements in the metadata inside
the proprietary KeyAuthority element we created to make CAs work.

There is no support for pulling CRLs from a file because there's no XML
Signature syntax for doing that. There's one for indirecting to a file
containing a <ds:X509CRL>, but that's not really too helpful since CRLs
don't come that way from CAs.

> Since certificates used securing https connections and certificates used
> to secure SAML messages are not necessarily the same, a 
> successful verification of the certificates used during https
> communication on the server or the client side does not imply that the
> certs used on received signed SAML messages are valid also.

They're totally separate operations. Trust plugins handle both signature and
TLS verification.

> Is my understanding of the shibboleth architecture in regards 
> to CRLs correct?

No, see above regarding Apache.

> If so, is it possible to configure shibd and tomcat IdP to do 
> their own independent CRL checking?

You *have* to. Nothing else will work.

> Or does shibboleth always depends on the fact that *all* valid used
> server-, client- and signing-certificates are in the up-to-date meta data
> file?

No. I'm simply saying that for practical purposes, people will reach that
conclusion one of these days and 2.0 will just speed it up.

> And if the latter is the case, why are CA certificates 
> listed/needed in the meta data file?

They're not really needed, they're supported in place of keys because people
wanted us to support them. But without use of CRLs, I'm saying that's a
dangerous thing to use, and so I'm just starting to fully comprehend the
danger.

-- Scott