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: "Cantor, Scott" <>
  • To: "" <>
  • Subject: Re: [inc-interfed] questions to InCommon Ops (John and Tom)
  • Date: Wed, 27 Feb 2013 01:43:49 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport07.merit.edu; dkim=neutral (message not signed) header.i=none

On 2/26/13 5:22 PM, "Tom Scavo"
<>
wrote:
>
>I don't know. What are the "legal or contractual obligations" for the
>*current* feed? (I really don't know the answer to that question.)

I don't think there are any. I think there are assumptions made about the
entities in the feed.

>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.

>- 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.

>- The two metadata files will have different "intended uses and
>expectations," as suggested above. I'm not convinced that two files at
>different locations is sufficient to drive home that point. Two sets
>of supporting documents are certainly required but I don't think that
>will be sufficient to distinguish between the two files either.

I certainly agree, see my response to ScottK.

>- 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.

>- 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).

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page