RE: [saml-dev] holder-of-key subject confirmation

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

> I would say the answer to this is "no". I have read all the follow-up
> emails and do not think they addressed the core problem which I
> will attempt to do here.

I would have to disagree with your argument, again on the basis that you are
assuming a particular approach to key management and interpretation of
certificates that is NOT required by any of the relevant specs.

As a SAML implementer, I am within my rights to ignore certificates as
anything other than key transport conveniences and base all decisions solely
on the public key itself. That means I am NOT required to trust certificates
at all, but can choose to rely only on the keys, and the certificates could
change without any impact on my implementation.

That isn't what Tom was asking about (it's actually kind of the opposite),
but I think it's relevant in a discussion about what somebody MUST do or MAY
do in terms of holder of key.

I think what Tom's proposing is that a PKI existing outside but related to
the SAML deployment could be used to equate certificates with the same
subject name as being equivalent (and thus their keys would be equivalent),
so that the *meaning* behind the IdP's statement remains the same.

And strictly on the basis of the specs, I think he's right. If that's a
problem for some people, then there needs to be a profile saying it's not
allowed.

> Anyone can read the cert, C1, and create a new cert, C2 with the same
> subject name etc. But no one should trust C2, because C2 was not
> contained in anything signed by IdP.

Anyone can't just create a cert because the assumption here is that a PKI is
in place that limits who can do so and what it would contain. To put it
another way, I claim that once you do anything with certificates (and not
just keys), you are implicitly saying that the SAML alone is not your scope,
it has to include the PKI as well.

Personally, I tend to fight such approaches, but I don't think they're
"wrong".

-- Scott