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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

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

Subject: Re: http://saml.xml.org/news/holder-of-key-web-browser-sso-profile

On Tue, Nov 18, 2008 at 1:51 PM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> wrote:
>>> An X509 certicate bind a public key to some identity (or more) assuming
>>> that you do identity based authorisation for example. So one needs the
>>> identity information, this is MORE that the DN.
>> No, in this case, the identity is in the SAML, not the X.509.  In
>> general, the relying party does not trust the issuer of the X.509
>> certificate, but the latter is required at the TLS layer so that the
>> presenter can prove possession of the private key.  It is this
>> proof-of-possession step that makes the profile work.  The identity in
>> the certificate does not come into play.
> If this is the case, then the identity provider must have established a
> its own association of an public key and some identity. Yes, that can
> work, you register an some id is established using whatever X509 cert.
> So, assume that when you register, the id provider just takes the ids
> in your certificat. That could be a registration policy of some id provider.

No, and in fact you've raised a most important point (which apparently
we need to explain better in the profile document).  The
proof-of-possession step and the authentication step are totally
separate.  In HoK Web Browser SSO, proof-of-possession is via TLS and
authentication is by some other means, typically username/password via
a web login form.

> I see the statement in line 380ff  of the web SSO profile saying something
> that Nameid references from the certficate SHOULD NOT be used.
> I am not sure that this is appropriate.
> It is a matter up to the identity provider to determine the identities.

Well, I've commented on that particular requirement, and will continue
to comment on it until it reads correctly.  That said, the
<saml:NameID> element in the assertion MUST agree with the
<saml:NameID> element in the request (if any).  Other than that, you
are correct that the <saml:NameID> issued by the IdP is a matter of

> So saying that they certficate IDs should not be used is a restriction
> that first cannot be verified and it can happen that it matches exactly
> the database of the id provider.

I basically agree with you, and I've commented as much.

> I agree that the profile is not specifically treating x509 id based things.
> It is more general, that's good, but taking ids from a cert is just a
> subset, and I do not see why it is almost excluded.

I agree this needs to be clarified in the profile document.  The point
that the editor is trying to make, I think, is that the certificate is
not trusted in general, so pulling the subject DN out of the
certificate and binding it to the assertion is not appropriate.

> There is one security thread which is important on the othre hand.
> There seem to exist some CAs that are certified by some of the global
> CAs that are installed in browsers in MS registries etc. which on the fly
> are creating SSL certificats (both for servers and clients).

That feature could be leveraged by this profile, yes.

> Instead of saying SHOULD NOT use information from the cert should
> be added a 'automatically' or something explaining that the ID has to
> be carefully be established .

That's exactly what we don't want.  We don't want to assume a trust
relationship between the SAML entity and the X.509 issuer.  If there
is such a relationship, that's okay, and we should address this
possibility in the Security and Privacy Considerations, but that
scenario should not come up in the body of the document.  Such a trust
relationship is out of scope.

> I am little bit brainstorming, this also tells something about me :-)

Yes, I know :-)  I'm beginning to believe that folks with a preference
for X.509-based PKI will find this profile somewhat confusing.  We
need to nip this in the bud, perhaps in the introduction.


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