Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> To be frank, some of us aren't doing CRLs in practice.

I'd be interested to know how many people were, actually.  The whole 
revocation thing is (a) theoretically critical to PKI but (b) widely 
ignored.  Certainly at one point essentially all browsers came with 
checking disabled by default because it slowed things down; I don't know 
what the current defaults are.

Similarly, we maintain a CRL for the SDSS CA but I don't think I've ever 
seen a log record for it that wasn't from some search crawler.

> That means the CA
> model we're using is leaving us quite vulnerable unless we explicitly yank
> stuff out of metadata and update the files, and we'd have to change key
> names when we revoke and reissue or else we'd never be able to prevent the
> bogus key.

That has been our theoretical model, too.  I'm not happy that this 
leaves us dependent on people refreshing metadata to get revocations, 
because I know a lot of people just download it once and forget it.  I 
can't see that the situation gets any better from that standpoint if you 
move the keys into the metadata, though.

> In other words, I think it's a real problem right now that we're pretending
> to use PKI but not really using it (for the simple reason that it doesn't
> actually work too well).
>
> Inline keys would be safer and cleaner, and as I told RLBob, transitioning
> it could happen in a day once all the keys are collected.

Correct me if I'm wrong, but the other pre-requisite would be that all 
entities were running at least Shibboleth 1.3, because 1.2 doesn't know 
about explicit keys in the old-style metadata.  I realise that may be 
implicit from where you're standing.

> > For example, does adding the explicit 
> > material shortcut the path validation?
>
> Yep.

That's good, because it provides some benefit (probably performance, and 
of course incremental live testing) *during* a transition if that has to 
be an extended process for whatever reason.

        -- Ian