[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Comments on draft-sstc-metadata-iop-02
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]