Skip to Content.
Sympa Menu

shibboleth-dev - RE: Encryption key strategies

Subject: Shibboleth Developers

List archive

RE: Encryption key strategies


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: Encryption key strategies
  • Date: Mon, 26 Jun 2006 14:06:51 -0400
  • Organization: The Ohio State University

> My concern with keys in metadata is the deployment issue, when an SP or
> IdP has to replace a key. Would there be means for smooth key changes
> with no service interruption?

For planned rollover, sure, you put both keys in. For emergencies, no, but
we have that problem now for the most part. Indirection just makes it
somebody else's problem. But we is us.

> Provided the policy requires new keys for certificate renewal, that
> might happen once a year for each SP or IdP.

If we can't get people to do daily metadata update, there's not much we can
rely on, because whatever layer you base the indirection on will still
require that.

> Is it related with dynamic metadata retrieval, based on the providerId?
> If I understand correctly, dynamically retrieved metadata would have to
> be signed by a trusted third party.

Or some kind of SSL or DNSSEC thing, I guess. I think it's not clear how
it's a win to make me submit my changes, get a signed document back, update
it on my site, then rely on the peer to get a fresh copy.

At least with central distribution, only the peer has to get that new copy.
I just submit and the change is signed and ready for pulling.

But yeah, I think it's connected. I just don't know (yet) how practical
dynamic is or how it will work, and I don't think encryption will wait on
answering all that.

Really it's somewhat academic...we *are* going to support inline keys, just
as we do now, and if people don't start offering compelling alternatives, it
will win. Because it works "well enough".

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page