RE: [security-services] comments re draft-sstc-metadata-iop-01

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

> Are all the deployments based on the same implementation?  If so,
> there's really only one deployment in effect, so my comment still
> stands.

No, they're not, but the issue is having varied deployment *models*, not the
number of implementations. The exchange of metadata can be secured with many
different trust models, including those based on a rigorous PKI.
 
> 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.

Turn it around. You could follow this profile and not lose anything either,
so claiming that it "doesn't work" is wrong. It composes perfectly well.

I'm also not trying to get people to abandon everything else they've ever
implemented. This is a profile, not a replacement for the standard. Now, if
you have problems getting particular federations to support your
requirements, that's a different issue, but it's off topic here.

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

I think it's an argument for X509Certificate, and nobody has ever suggested
using SKI instead until now. That tells me something. I also know that my
implementation will have a heck of a time adding support for it because
nothing I have built-in will handle SKI, so that leaves me pretty cold
unless I see a value-add from it. Reducing size has value, but I don't think
quite enough.

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

The confusion to date has been minor and easily rectified. The advantages
outweigh confusion, and so few people rely on bare keys anyway that it's
been a small point.
 
-- Scott