OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

>> 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

>> 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]