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: Wed, 28 Jun 2006 12:58:15 -0400
  • Organization: The Ohio State University

> I'd be interested to know how many people were, actually. The whole
> revocation thing is (a) theoretically critical to PKI but (b) widely
> ignored. Certainly at one point essentially all browsers came with
> checking disabled by default because it slowed things down; I don't know
> what the current defaults are.

Browsers aside, the issue is Shibboleth, and I think it's likely that few
people have them in place because we don't actually describe how to do it
anywhere, really.

> That has been our theoretical model, too. I'm not happy that this
> leaves us dependent on people refreshing metadata to get revocations,
> because I know a lot of people just download it once and forget it. I
> can't see that the situation gets any better from that standpoint if you
> move the keys into the metadata, though.

I think it gets much better because it's really clear what a silly thing
that is to do in an inline key world. If people are not maintaining
metadata, they will be vulnerable and someday will probably get screwed by
it. Caveat emptor. Their systems will also fail any time a key changes. This
is currently viewed as "bad" by some, but I think I disagree with that.

> Correct me if I'm wrong, but the other pre-requisite would be that all
> entities were running at least Shibboleth 1.3, because 1.2 doesn't know
> about explicit keys in the old-style metadata. I realise that may be
> implicit from where you're standing.

Well, 1.2 sort of does because you can put inline keys in the trust file.
There are some caveats wrt SSL usage, but it can be made to work. But no, I
haven't really studied that aspect, I just know 1.3 would be oblivious to
it.

> That's good, because it provides some benefit (probably performance, and
> of course incremental live testing) *during* a transition if that has to
> be an extended process for whatever reason.

Inline is always favored over anything else because it's MUCH faster. It's a
fall-through from the basic plugin to the advanced wrapper that does path
checks when the basic plugin gives up.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page