Shibboleth Developers

[Walter Hoehn <>]

Whether or not we include support for trust rooting, I had sort of 
assumed that when an end-entity certificate was included directly in 
the metadata entry for a system entity it would be treated as "just a 
key".  So, from the standpoint of the shibboleth, the renewal wouldn't 
be required.  Likewise, a new certificate that shared a public key with 
its predecessor wouldn't require a metadata update.

 -Walter


On Mar 1, 2005, at 7:32 PM, RL 'Bob' Morgan wrote:

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature