interfed - Re: [inc-interfed] questions to InCommon Ops (John and Tom)
Subject: Interfederation
List archive
- 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
- [inc-interfed] questions to InCommon Ops (John and Tom), Scott Koranda, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Scott Koranda, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Scott Koranda, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/27/2013
- Re: [inc-interfed] MDRPI, Ian Young, 02/27/2013
- Re: [inc-interfed] MDRPI, Tom Scavo, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Tom Scavo, 02/27/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
- Re: [inc-interfed] questions to InCommon Ops (John and Tom), Cantor, Scott, 02/26/2013
Archive powered by MHonArc 2.6.16.