Interfederation

["Cantor, Scott" <>]

On 2/26/13 2:19 PM, "Scott Koranda" 
<>
 wrote:

>Any and all trust about the current feed is not bound to "the key"
>used to sign that metadata. The trust is codified in other places and
>other ways (I can read and sign various documents) and then the key
>and the signature of the metadata is only a way for me to be sure as
>an SP operator that I am trusting the right set of bits.

Well, the problem is the key doesn't give you any assurance that the
document you meant to fetch from a particular location is actually the
document at that location. You know it's what InCommon signed, but you
have no way to defend against MITM attacks. That's why it has to expire
and you have to block a document that doesn't expire.

>So to my mind there is no need to have a new key that would be used to
>sign a new InCommon metadata aggregate. I simply need to be sure as an
>SP operator that I understand what sets of bits I am getting (what URL
>I am fetching from) and that the bits once I get them have not been
>corrupted.

The URL is irrelevant to the trust decision because there's no
verification at the transport layer.

So InCommon has two options if it wants to distinguish two aggregates:

- use a different key
- put something into the aggregate

So it doesn't follow that a different key is needed a priori, but it is
true that the URL alone won't do it if the intent is to communicate
something "different" about the signed bits.

-- Scott