Shibboleth Developers

[Jim Fox <>]

> > 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."

It's only extra work because this example is an existing client migrating
to the new system.  Adding a new SP involves entering some data. 
Part of that can be the key.

> 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).

OK, we have SPs who play fast and loose with certs.  Suppose the SP
decides a cert from FlyByNightCA is cheaper, so it gets one of those.
The new cert works with browsers because browsers accept all certs.
It doesn't work with our IdP.  In the emergency we decide to add
FlyByNightCA to out list of acceptable CAs.

I don't think we're out of line by asking for the smallest bit of
sophistication on the part of our SPs.  A simple web form might be
all that's required for the SP to stay up-to-date.

The new-key-from-the-same-CA example might be the only case where
the non-CA approach causes extra trouble.  A change of CA might not
work in any cass.  Nor would a change of CN.

Jim


> 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.