[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] comments re draft-sstc-metadata-iop-01
On Fri, Aug 15, 2008 at 2:13 PM, Scott Cantor <cantor.2@osu.edu> wrote: > >> I'm talking about the >> normative language on lines 261--263 and lines 283--286, for instance. >> Those requirements virtually rule out the use of SAML metadata in >> deployments that are already based on a PKI (such as a typical grid >> deployment). > > That is a common mistake, but it's not true. I disagree. >> I think its a deployment profile, by your own definition. There's no >> question about this, in fact. > > The question is whether it is general enough to address many different kinds > of deployments, and since I know for a fact that it is.... Are all the deployments based on the same implementation? If so, there's really only one deployment in effect, so my comment still stands. >> It certainly does. For instance, on lines 261--263, the profile says >> that other child elements of <ds:KeyInfo> "MUST NOT be required in >> order to identify the key," but in a deployment that is already based >> on a PKI (such a grid deployment), any of those child elements may be >> used. > > The fact that it doesn't work for *a* deployment based on PKI doesn't mean > that it doesn't work for many others. The differentiator is where the PKI > is. Indeed. I'm thinking about the use case described in the "Attribute Sharing Profile for X.509 Authentication-Based Systems" and the "Deployment Profiles for X.509 Subjects." In that use case, the subject authenticates to (what I call) a Grid Service Provider using an X.509 certificate. Bound to the certificate is a SAML assertion used for access control at the Grid SP. Now the Grid SP needs metadata for the entity that bound the assertion to the certificate. But the issuer of the assertion is the issuer of the certificate, so the Grid SP already has the certificate of the issuer in its trusted certificate store. All it needs in the metadata is the DN of the issuer to make the connection between certificate issuer and assertion issuer. >> Well then I'm missing something, since lines 261--263 and lines >> 283--286 seem to rule out a PKI explicitly. Please describe how a >> grid deployment can use <ds:X509SubjectName> in lieu of >> <ds:X509Certificate>, yet conform to this profile. > > In metadata? You can't. That's my point. >> That's not what I'm asking...why isn't <ds:X509SKI> defined for use in >> metadata? If all you care about is the key anyway, why wouldn't >> <ds:X509SKI> in metadata serve the purpose? > > Well.... All your points are well taken. > That said, I'm not against it if people are using it now. I'm not convinced > they are. I'm not sure <ds:X509SKI> is really needed either, but I have to keep it on the table until I've convinced myself there are no hidden requirements. >> There's already support for <ds:KeyValue> in your metadata >> implementation? I've never seen an example of such metadata so I must >> be behind the times. > > It's been supported for going on 3-4 years now. People don't use it because > the syntax for bare keys is difficult. Certificates are more convenient to > deal with, and are generally around anyway because of TLS and historical > practice. Which is an argument for <ds:X509SKI> in fact. >> That erratum has particular relevance, I think. It implies that >> <ds:KeyValue> should only be used in the case where use="encryption". >> Since use="signing" implies SSL/TLS as well, and the latter requires a >> certificate, that implies that <ds:KeyValue> should not be used in >> that case. > > No, it doesn't. Let me rephrase. If you put a <ds:KeyValue> in an <md:KeyDesriptor> with use="signing", it will confuse everyone since the key presented as a result of SSL/TLS is always bound to a certificate. > *Everything* in the metadata MUST be turned into a key. > That's the comparator. In the case of TLS, you extract the key from the > peer's certificate and if it matches, you're done. The certificate is a > runtime requirement, not a metadata requirement. Yes, that's a separate issue, and one I'm still struggling to understand the implications of given that my deployments are very different than yours. Tom
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]