Shibboleth Developers

[Chad La Joie <>]

Actually, the signing question has already come up (multiple times as I 
understand).  I've wondered a number of times why we actively make a 
complex system even more complex by adding additional technology that 
arguably adds no real-world value.  I've strongly suggested to everyone 
I've helped deploy this that they not use PKI and they've been relieved 
that they don't have to deal with it.

Keith Hazelton wrote:
> "We can't solve the problems of PKI in this project." Absolutely.  So 
> for encryption keys, let's adopt  Scott's proposed KeyResolver API using 
> metadata.  It makes sense for this community and this problem.   Let's 
> cross the "why not do this for signing keys, too?" bridge when we come 
> to it.  That topic, when and if it comes up, may energize the proponents 
> of classic PKI to make their case.  In the meantime, there's no reason 
> to shy away from this useful and sound solution for encryption keys.
>
>       --Keith
> ____________________
>
> Scott Cantor wrote:
>
> > Another topic that's going to need some discussion at some point (I've
> > brought it up with Chad) is encryption keys. The problem with 
> > encryption is
> > that you need the peer's key.
> >
> > With signing, you can do fancy things like use metadata to authorize 
> > keys by
> > name and then use path validation, but encryption isn't like that. If we
> > don't store an actual key or certificate inside the metadata, we have no
> > mechanism today to obtain the peer's public key to do the encryption 
> > with.
> >
> > If we start storing keys for encryption in the metadata, you quickly 
> > have to
> > ask why anybody would bother not doing that with the signing keys and the
> > path validation option becomes rather pointless. You lose the benefits of
> > key roll-over.
> >
> > If we don't store the keys there, that means building something else. 
> > But we
> > can't solve the problems of PKI in this project, so is it really in 
> > scope to
> > build a key indirection solution for our use of encryption?
> >
> > I guess I would advocate we build an API for this, presumably just a
> > KeyResolver API which I already have, but implement it with metadata 
> > for the
> > time being. The problem with that is simply the point I raised 
> > above...once
> > we do that, the path validation stuff quickly becomes stupid to use.
> >
> > This would be mostly unimportant if encryption wasn't useful, but I think
> > it's very useful and quite simple to implement in and of itself as it 
> > turns
> > out.
> >
> > -- Scott
> >
> >  

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124