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 16:55:31 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport02.merit.edu; dkim=neutral (message not signed) header.i=none

On 2/27/13 8:26 AM, "Tom Scavo"
<>
wrote:

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

Probably, though Ian's more familiar than I am.

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

A simple DER-encoded file with a public key seems better to me. I don't
see OpenSSL supporting JSON any time soon, so that's not going to be very
helpful as a format for me, no.

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

But anyway, this is all sliding into the metadata discussion that I keep
wanting to separate out.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page