Interfederation

[Tom Scavo <>]

Well, like I said, if you don't think we need a new signing key for
this, then we need to start over. I will fall back and try to document
on a wiki page why I think we need a new metadata signing key.

Thanks,
Tom

On Mon, Feb 25, 2013 at 4:01 PM, Cantor, Scott 
<>
 wrote:
> On 2/25/13 3:18 PM, "Tom Scavo" 
> <>
>  wrote:
>
>>Okay, I'm evidently doing a poor job of communicating today, so let me
>>summarize the points I'm trying to make as a top post and see if that
>>helps. I assume I have at my disposal a second signing key, not a set
>>of signing keys but a single signing key distinct from the current
>>signing key. Let me refer to these keys as Key1 (current) and Key2
>>(new). (If you won't allow a new signing key into the discussion, then
>>we're at an impasse and need to start over.)
>
> I haven't yet heard anything but a claim that we need one, but no
> discussion as to why. I think you are making this claim because in some
> sense you think the current key, acting as essentially a CA, has some kind
> of implicit policy OID associated with it such that a different use case
> would involve a different policy OID, and thus in this context a different
> signing key.
>
> If that's not so, then I don't know what your goal would be in having a
> second key. If one looks at the key not as a CA but more like a
> traditional certificate or keypair, I certainly don't sign things with
> different certificates for other than simple technical reasons. I use one
> certificate (or PGP key or whatever) for multiple kinds of emails and
> content.
>
> I guess others will have to weigh in, but my inclination is to start with
> the assumption no new key is needed unless the case is made as to why. A
> big win of not using PKI in SAML is to avoid hidebound assumptions about
> why things have to be done in certain ways for reasons obvious only to
> people who write PKI profiles.
>
>>- We would publish one or more new metadata aggregates signed with
>>Key2. At one extreme, we would aggregate all the trusted IdPs of the
>>world into a single file. At the other extreme, each participant would
>>receive its own custom aggregate of trusted IdPs.
>
> Initially you seemed to be taking a position explicitly against that
> "extreme", but allowing that nobody is saying it has to be "every IdP in
> the world", I'm just saying that having a federation-level aggregate of
> "many" IdPs is better than expecting every SP to manually create their own
> aggregate either on their own or through some interaction with IC.
>
>>- Aggregation of SP metadata is a completely separate conversation.
>>AFAICT aggregation of IdP metadata is mostly technical whereas
>>aggregation of SP metadata is mostly policy. Thus the motivation to
>>separate the two.
>
> I don't understand this statement. If anything, IdP metadata is a lot more
> sensitive given what they are allowed to do.
>
> I would point out that for this to work for LIGO on the other end (the UK
> IdP trusting LIGO), you essentially are expecting the UK Fed to do this
> while at the same time claiming it's not at all similar to what IC is
> being asked to do.
>
> -- Scott
>
>
>
>