shibboleth-dev - RE: Encryption key strategies
Subject: Shibboleth Developers
List archive
- 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
- Re: Encryption key strategies, (continued)
- Re: Encryption key strategies, Reimer Karlsen-Masur, DFN-CERT, 06/22/2006
- Re: Encryption key strategies, Chad La Joie, 06/22/2006
- Re: Encryption key strategies, Tom Scavo, 06/22/2006
- Re: Encryption key strategies, RL 'Bob' Morgan, 06/23/2006
- RE: Encryption key strategies, Scott Cantor, 06/23/2006
- Re: Encryption key strategies, Thomas Lenggenhager, 06/26/2006
- RE: Encryption key strategies, Scott Cantor, 06/26/2006
- Re: Encryption key strategies, Ian Young, 06/28/2006
- RE: Encryption key strategies, Scott Cantor, 06/28/2006
- Re: Encryption key strategies, Ian Young, 06/28/2006
- RE: Encryption key strategies, Scott Cantor, 06/28/2006
- Re: Encryption key strategies, Ian Young, 06/28/2006
- RE: Encryption key strategies, Scott Cantor, 06/28/2006
- Re: Encryption key strategies, Ian Young, 06/29/2006
- Re: Encryption key strategies, Jim Fox, 06/29/2006
- RE: Encryption key strategies, Scott Cantor, 06/29/2006
- Re: Encryption key strategies, Ian Young, 06/29/2006
- RE: Encryption key strategies, Scott Cantor, 06/28/2006
- Re: Encryption key strategies, Ian Young, 06/28/2006
- RE: Encryption key strategies, Scott Cantor, 06/28/2006
- On using CRLs in Shibboleth (was: Re: Encryption key strategies), Reimer Karlsen-Masur, DFN-CERT, 06/29/2006
- RE: On using CRLs in Shibboleth (was: Re: Encryption key strategies), Scott Cantor, 06/29/2006
- Re: Encryption key strategies, Ian Young, 06/28/2006
- RE: Encryption key strategies, Scott Cantor, 06/28/2006
- Re: Encryption key strategies, Reimer Karlsen-Masur, DFN-CERT, 06/22/2006
Archive powered by MHonArc 2.6.16.