Shibboleth Developers

["Scott Cantor" <>]

There's another reason, BTW, that the CRL model doesn't work unless we
implement a remote referencing approach (RetrievalMethod, in other words).

People are using the CA stuff to do support for commercial CAs. And
commercial CAs have massively large CRL lists. Putting that in the metadata
let alone maintaining it is a problem.

The second problem is that the vendors wouldn't supply their CRLs in XML
form, which means a proprietary referencing mechanism, or pulling it out of
the metadata and just loading it directly.

> Real-time is what one should aim for when authenticating end-users via
> client certificates against an IdPs SSO webpage.

Sorry, I don't follow this at all. If an end user key is compromised, the
threat is one user being impersonated. If an IdP key is compromised, the
threat is impersonation of any user from that IdP.

If anything, I think you have it backwards.

> When talking about Shibboleths inner architectural 
> trust-fabric real-time is nice but not necessary.

See above.

> See the Grid community...: Recommended CRL refresh at least 
> once a day.

The Grid model is end to end uniform PKI, not federated. It's the end-user
cert case, not the federated trust case.

> Standard installations of widely deployed Grid projects 
> download the CRLs every 6 hours (plus some random minutes to avoid load
> peaks at the CDPs),.

I'd love to see that proven, just as a matter of interest. I question the
assumption that people are doing this, and if they are, we should figure out
how they get people to do it when we can't get people to refresh their
metadata. We should learn their secret.

> In any case (real-time, CRL or metadata) there is always the slack from
> time of compromise to the detection of it which - I guess - is 
> much longer than the slack that new metadata or CRLs are polled.

This is true, yes.

> In real life the revocation of certificates happens very slowly even if
> the subscribers are obliged to revoke a certificate immediately 
> after detection of a compromise or for other reasons. I don't know if the 
> metadata inline certificate model is helping to solve this...

I think it helps a little, and moreover it also solves the encryption
problem.

> Subscribers would need to turn up at two places: at the CA or RA to get
> the certificate revoked and at the federations metadata file management.

There's only one place to go, the metadata signer. He is CA and RA.

-- Scott