Skip to Content.
Sympa Menu

interfed - Re: [inc-interfed] questions to InCommon Ops (John and Tom)

Subject: Interfederation

List archive

Re: [inc-interfed] questions to InCommon Ops (John and Tom)

Chronological Thread 
  • From: Tom Scavo <>
  • To: Interfederation TAC Subgroup <>
  • Subject: Re: [inc-interfed] questions to InCommon Ops (John and Tom)
  • Date: Wed, 27 Feb 2013 12:17:55 -0500
  • Authentication-results:; dkim=pass (signature verified)

On Wed, Feb 27, 2013 at 11:55 AM, Cantor, Scott
> On 2/27/13 8:26 AM, "Tom Scavo"
> <>
> wrote:
>>>Alternatively, explicitly and deliberately let it expire so that it's
>>>100% clear the certificate isn't the point.
>>Yes, those are options. We need to figure this out rather soon, too. A
>>major campaign is required in any case.
> I agree, I'm just not as concerned about it from the perspective that
> nothing I'm aware of that actually uses that key will actually break.
> Publicly explaining to people who are confused is cheap compared to
> shipping software changes.
>>I haven't been able to imagine any online scenario that makes sense.
>>Are you mentioning it for completeness or do you have some particular
>>idea in mind?
> For my own purposes, I looked at it, and concluded that the need to
> generate CRLs frequently rendered most of the advantages moot. It's
> certainly possible that applies to InCommon as well. The downside is that
> it's harder to do signed per-entity metadata with an offline key. Not
> impossible, just harder.
> (For the purposes of this conversation, I'm treating signing and TLS as
> the same, obviously using TLS to protect metadata exchange essentially
> moves a key online and changes the verifier behavior.)
> I don't know if it's practical to do what we will end up wanting to do
> with an offline key, and obviously moving it online means PKIX is back in
> the picture, validation, CRLs, etc. But there are precedents for this, and
> at least in Shibboleth, support for it.

An important take-away here is that the expiring signing certificate
really belongs in the Metadata Distribution Working Group, not the
Federation Operations subgroup as suggested in the minutes to the last
TAC meeting (


Archive powered by MHonArc 2.6.16.

Top of Page