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 08:26:05 -0500
  • Authentication-results: sfpop-ironport04.merit.edu; dkim=pass (signature verified)

On Tue, Feb 26, 2013 at 8:43 PM, Cantor, Scott
<>
wrote:
> On 2/26/13 5:22 PM, "Tom Scavo"
> <>
> wrote:
>>
>>Well, I can say this: the intended use and expectations of the current
>>feed are different than the intended use and expectations of the new
>>feed we've been discussing. I'm hoping that's obvious to folks.
>
> Yes, but I doubt we'll find 100% agreement about what the differences are.
> And it's worth doing some thinking, I think, about how to make as many
> assumptions as possible more explicit in any future aggregates so as to
> avoid implicitness in the future.

Agreed. For example, I'm guessing that this subcommittee will
recommend full support for MDRPI.

>>- The signing key is bound to an X.509 certificate, which confuses the
>>heck out of people.
>
> Yes, but that's what 30 year lifetimes are for.

Yes, but that's not quite what I meant. We're still using keys bound
to X.509 certificates rather than keys bound to some other structure
that better supports (conceptually) the trust model of the Federation.
JSON Web Keys (http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08)
is the first alternative that comes to mind.

>>- One or more *new* metadata signing keys may be in our future. The
>>current key is bound to a certificate that expires in one year.
>>Something has to be done about that.
>
> Issue a cert for 30 years with the same key. We've renewed the key
> certificate before, I believe. If so, we made a mistake by not making it
> long that time.
>
> 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.

>>- The current signing key is associated with a very tight production
>>pipeline, with very strong protections. (It is an offline signing
>>key.) We don't want to disrupt that secure pipeline.
>
> No argument from me (unless we want to move it online, which means
> changing the verification model).

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?

Thanks,
Tom



Archive powered by MHonArc 2.6.16.

Top of Page