Re: [security-services] comments re draft-sstc-metadata-iop-03

[Tom Scavo <trscavo@gmail.com>]

On Mon, Feb 16, 2009 at 12:09 PM, Scott Cantor <cantor.2@osu.edu> wrote:
> Tom Scavo wrote on 2009-02-15:
>> That's probably more than you wanted to hear, and maybe most of it is
>> off-topic, but hopefully it satisfies your curiosity about the use of
>> SAML metadata within an X.509-based PKI.
>
> Yes, it does. But it doesn't show that you *couldn't* embed the certificates
> of the allowed "X.509 issuers" (I think that's the term you used) into the
> metadata.

Today that's true, since the SAML token is bound to a gateway-issued
proxy certificate.  But the goal is to bind the SAML token to a
short-lived end-entity certificate (EEC) obtained just-in-time.  In
this scenario it is not possible to bind full certificates to metadata
since the EEC is not static.

> That doesn't mean you should or that I would, but it works
> functionally, as it must by definition because you can't break the security
> model by collapsing a layer of indirection.

Well, no, it doesn't work if the SAML token is bound to the EEC.  I'm
not sure what you mean by "it must by definition" since clearly that
is not the case.

> Your other note mentioned moving away from long-term certificates, but while
> that argues further against embedding the keys (assuming you also meant the
> keys would be churning), it doesn't preclude it. It means that the exchange
> of metadata would have to be more dynamic to work.

The actual keys in the certificates are irrelevant at the SAML layer,
both now and in the future when we move to SAML tokens bound to EECs.
The only constant throughout all of this is the DN.  By binding DNs to
metadata, we insulate ourselves from any foreseeable change in the
X.509-based PKI.

> Again, I wouldn't do this. But as a disproof of the universality of the
> profile, I don't see it.

Right, well, I still claim that the Metadata Interoperability Profile
can not be made to work if the SAML tokens are bound to the EEC.  In
that case there are no static certificates to bind to metadata.  The
content of the EEC is dynamic depending on the end user represented by
the sender-vouches SAML token.

> It does however suggest some properties to discuss in explaining the
> contexts in which the profile will be useful. We covered the notion of
> having an existing runtime PKI earlier. This adds the point that using
> shorter-term credentials is also probably a factor.

The most important factor is that the content of the certificate is
dynamic.  This forces the EEC to be short-lived, yes, but that's a
mere consequence.

> I do intend to produce another draft with some more text when I have time.

Thanks,
Tom