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)


Hal said, 

> In the case of both Subject and Issuer, it is necessary to confirm
that
> the information refers to or is asserted by, the party in question.
> However, SAML assumes that an Issuer will either digitally sign the
> assertion or will use some means outside of SAML (e.g. TLS session,
> physically secure network) to provide the Relying Party with assurance
> that the Assertion is authentic.
I agree that issuer confirmation of the assertion, by signature or
otherwise, should be confirmed outside of SAML. The same actually holds
for the Subject. However, as you explained well in the rest of your
note, SAML does provide syntax to carry subject confirmation
information, to allow different applications to confirm the
correspondence between the Subject of the SAML assertion and a specific
entity (e.g. the entity who submitted a signed request). My question is:
why not provide similar syntax (elements) for the Issuer? 

It may help if I demonstrate some scenario where the application can use
the confirmation info of the Issuer (e.g. public key). Consider a web
server that accepts an SSL connection using client authentication, and
allows any certificate authority (CA). After the SSL handshake is
complete, the server wants to send the received certificate as a SAML
assertion to the application. When the CA is not known, the application
should determine if this CA is trustworthy or not. For that, the
application needs the information about the CA, including its public key
(clearly we can't just identify it only using the name it selected for
itself). 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). 

Regards, Amir Herzberg
See http://amir.beesites.co.il/book.html  for lectures and
draft-chapters from book-in-progress, `secure communication and commerce
using cryptography`; feedback welcome!



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


Powered by eList eXpress LLC