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

[Hal Lockhart <hal.lockhart@entegrity.com>]

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

Amir Herzberg wrote:
>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?

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

Note that to protect the contents of an assertion from modification, in addition to merely authenticating the Asserting Party, it is necessary to use some sort of signature over the contents. The TC felt that XML dsig, which provides for both symmetric and assymetric crypto mechanisms, was sufficient for this purpose.

> 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.

I don't understand why. SAML currently allows Asserting Parties (AP) to make assertions about 1) Authentication acts, 2) User Attributes and 3) Authorization Decisions. SAML does not provide a binding between users and keys, as there are a number of other mechanisms, e.g. X.509 certificates, already in existence for this purpose. 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.

>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).

I am not sure I understand your use case, but you appear to be trying to use SAML to establish a trust relationship. 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?

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. Presumably it could forward this certificate chain in some standard from, such as CMS.

If you are looking for a standard that converts all of PKI to XML, that is not a goal of SAML.

Regards,

Hal