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] | [Elist Home]


Subject: RE: [security-services-comment] Specifying Issuer (vs. Subject)


I asked,

> > why not provide similar syntax (elements) for the Issuer?

Hal replied,

> I guess the simplest answer to your question was that this was not
among
> the usecases submitted, so it was not given any consideration.

That's understandable. But I assume you're open to suggestions on
possible improvements to SAML which extend its functionality and range
of applications (unless I misunderstand here and just waste our time). 

<skip>
> If an AP wishes to take some of the
> information from an X.509 certificate and use it to construct an
Attribute
> Assertion, this is certainly legal, although not clearly useful.

One use is to simplify the relying application, by providing it with a
uniform assertion, derived from multiple kinds of credentials - X.509
certificates, attribute certificates, database lookups, ... See details
in
http://amir.beesites.co.il/Papers/PKI/Credentials%20Framework%20Journal.
pdf

> I am not sure I understand your use case, but you appear to be trying
to
> use SAML to establish a trust relationship. 

Definitely not. I'm trying to use SAML as a format for an a security
assertion. Part of this assertion is information about the issuer. This
in turn may be used by a relying application to make its trust decisions
(and in particular to request certificates for the issuer). 

> This was determined to be out
> of scope for SAML at a very early stage. Again the reasoning is that
there
> are a variety of other mechanisms available designed for this purpose.
> >Notice most web servers don't directly support this scenario
> > (of accepting certificate from unknown CA) but some do (and we can
> > workaround others to support this very important mode).
> This seems like a rather undesirable feature. Doesn't accepting a
trusted
> key from an unknown party on the fly pretty much negate the value of
> cryptographic authentication?

Initially it may appear so, but in many cases, there is value in
authenticating first, even before knowing that the other party is valid,
and only then gathering the necessary info to determine validity. 

> In any event, it seems to me that all the information you seek would
be
> available to the party establishing the original SSL connection, in
the
> form of the certificate chain used to authenticate the other party.

Yes, the info is in the certificate chain, but of course it doesn't make
sense to use both this and SAML. 

<skip>





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


Powered by eList eXpress LLC