Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Tue, 1 Mar 2005, Jim Fox wrote:

> FWIW, we at UW could get by just fine with the "MetaData Alone" 
> implementation, and just bag all the CA stuff.

Let's look at the case of the non-InCommon SP that we just added to our UW 
IdP the other day, the one that gave us a VeriSign-issued cert.  Because 
the IdP AA can only use mod_ssl to verify AA requests, we had to add the 
VeriSign root to the mod_ssl cert bundle on the AA.  So we take the risk 
some malicious person will obtain a VeriSign-issued cert with the same 
name as one of our other SPs and masquerade as that SP, potentially 
getting access to sensitive user data.  It's not that big of a risk at 
this point, not big enough to make us force this SP to use a UW-issued 
cert apparently.  But we know we're looking forward to the day when the 
Shib IdP has the capabilities we're talking about, the kind of 
fine-grained trust capabilities the Shib SP has now, so we can avoid this 
risk.

Let's imagine the world a few months from now when the IdP has all that. 
Suppose it is "metadata only" as people are proposing, ie the only keys it 
can validate are those in the metadata.  We don't have this SP's cert now, 
we don't need it because with SSL/TLS they send it every time.  So we have 
to ask them to give it to us (or capture it some time when they send it 
via SSL).  Not a big deal maybe, but it's some extra work we (and all 
others in our position) have to do, and it's hard to sell as "an 
improvement."

So a few months later the SP's VeriSign-issued cert expires and they get a 
new one from VeriSign, with a new key of course.  They install it and now 
access to their site via our IdP breaks.  They didn't have to install it 
for client access to the AA, of course, but they did, because that's what 
you do when certs expire, as everyone knows.  So now we have to get their 
new key and stick it in, in crisis mode.  But of course we anticipate this 
and have in our docs for them:  you don't really ever have to change your 
client key ("UW best practice recommendations: never change keys"), but if 
you do, you have to do this step with us to give us your new key before 
you install it.  Yes, this looks a lot like the step they have to do with 
VeriSign to get their new cert, the step that all SSL-using web admins 
have had to become familiar with, but it's a different step, and if they 
have peer-to-peer arrangements with other IdPs, they have to do it with 
them too.  They would naturally ask:  gee, we just got our new cert from 
VeriSign, can't that just work with Shib without having to do a bunch of 
extra work to copy our cert around?  For browser access to our site we 
just install it and it works, right?  And we'd say:  oh no, Shib is much 
more advanced, it avoids that CA hassle, please send us your cert 
(attached to a plaintext email message, of course).

So I think being able to use trust anchors to validate certs is very 
practical, more secure in several ways, less work for SP and IdP 
operators, and takes advantage of the existing knowledge people have about 
certs and CAs.  I think it would be a regrettable step backwards for Shib 
to lose this ability, and we would spend much more time defending this 
decision than it would take to do the right thing and support it.  I think 
we can very likely get the SSTC to agree to whatever metadata extensions 
we propose to provide this capability (while also gaining some useful 
insight from the participants there, I bet).  I think the answer for 
people who have path validation problems is:  they aren't a fact of life, 
you can avoid them if you want by sensible naming, and if all else fails, 
you can always jam the key into the metadata.  This shouldn't prevent the 
rest of us from being able to use non-trivial validation.

 - RL "Bob"