Shibboleth Developers

["Scott Cantor" <>]

> For what it's worth, I think this is the right approach.  It might make 
> sense to get more sophisticated later in terms of where the information 
> is stored and how it is retrieved, but that's why you're proposing an 
> API *and* an implementation, rather than just an implementation, right?

Probably, depends how awkward it is to handle the inline keys with some kind
of extra API. I already have something I can probably adapt for it.

> Even if keys-in-metadata does turn out to be how things work out, 
> though, I wouldn't anticipate it happening soon; any existing production 
> federation will take a while to adopt that posture and then 
> transitioning will require a whole lot of administrative and 
> technical work.

To be frank, some of us aren't doing CRLs in practice. 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.

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.

> It might, actually, be interesting to think about how one could manage 
> such a transition.  Does the current codebase "do the right thing" in 
> the presence of both an explicit key in the metadata and a key reference 
> in the form of a key name?  For example, does adding the explicit 
> material shortcut the path validation?

Yep.

-- Scott