RE: Comments on draft-sstc-metadata-iop-02

["Scott Cantor" <cantor.2@osu.edu>]

> Here are some comments on the Metadata Interoperability Profile draft. I
> hope you can take these into consideration.
> 
> 2.4.1 Peer Authentication, and E62 SAML Errata
>
> "Re-using" the "signing" key for TLS authentication is in my opinion a bad
> idea.

There's no requirement to do so, but there is no capability to independently
identify a key for TLS, and the meaning of "signing" in the core spec is
both. That has nothing to do with this profile. I'm not sure if you thought
this profile was changing that, but it does not.

The errata was only mentioned because it's important to the profile that the
meaning of the attribute is understood.

> For example one might have a web site www.example.com that hosts several
> SAML entities. By nature of TLS there exist only one TLS key for the site
> www.example.com. However it should be possible to clearly identify and
> authenticate each entity hosted on the site.

And you can. Just don't use TLS for SAML purposes. In the case of an SP,
this isn't very difficult to accomplish.

> E62 suggests that each entity hosted on www.example.com publish the TLS
key
> for www.example.com in their metadata. The problem is that this makes it
> possible for an entity to impersonate any other entity on the same site.

With respect to what E62 "suggests", it has no freedom to do otherwise. If
you plan to use that key for some SAML purpose, you need to publish it
somehow.
 
In the context of my profile, yes, you would have to do that. But in answer
to your concern, I would submit to you that you cannot hope to achieve any
meaningful separation of concerns of multiple entities living behind one
vhost. The web simply doesn't work that way. You can pretend it's three
entities, and that might be helpful in some contexts, but you're just
playing games at that point.

Essentially, the fact that such entities could impersonate each other is a
good thing. It shows everybody what's really going on.

But again, you need not do this. Using TLS keys is not a requirement in
SAML. Signing and encryption can accomplish essentially the same things.

> 2.6.1 Key Processing
> 
> If more than one key with the same key type are given for an entity role,
> then how does an implementation identify which of the keys to use for
> signature validation or message encryption?

This also has little to do with this profile. It's simply a given in SAML
metadata that multiple keys are possible. This is made clear in the metadata
spec, and in some subsequent errata to explain that multiple keys are
interchangeable for a given purpose.

You are free to encrypt to any key available, and you would accept any key
for signing or TLS (where this profile actually does tell you explicitly
what "accept" means).

Actually identifying the right key at runtime, while not strictly necessary,
is a useful optimization, and you can do that with the KeyInfo information
in a signature, or a TLS certificate, and intelligent comparison logic to
locate the matching key. Explaining how to do that well isn't in scope for
this profile, because it doesn't affect interoperability, only
implementation efficiency.

-- Scott