[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!
Powered by eList eXpress LLC