Digital Signature Usage in X.509 Subject Attribute Query Specifications

[Anil John <aniltj@gmail.com>]

All,

In looking over the usage of digital signatures between the "SAML v2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems" [1] and the "SAML v2.0 Deployment Profiles for X.509 Subjects" [2], came across a difference and am hoping to get a bit of background on the difference.

In [1] Encrypted Mode (Request), the <samlp:AttributeQuery> element MUST be signed.
In [2] Encrypted Mode (Request), the <samlp:AttributeQuery> element MUST be signed.

So their usage in the Request is for all intents and purposes identical.

In [1] Encrypted Mode (Response), both the <saml:Assertion> AND the <samlp:Response> MUST be signed.
In [2] Encrypted Mode (Response), the <saml:Assertion> MUST be signed, but the <samlp:Response> MAY be signed.

Could anyone provide a bit of background on the optional signing of the <samlp:Response> in [2]?

I am asking from the perspective that we are in the process of refining a profile for querying for the Backend Attributes of PIV Card Subjects over SOAP, and have chosen to keep the delta between it and the above profiles as small as possible in the interest of minimizing implementation issues.

The follow-on question I would have to the above is related to a "NIST 800-95, Guide to Secure Web Services" [3] recommendation. In section 3.5.3.6, the following is recommended to mitigate replay attacks:

"Signing the entire message rather than the assertion itself, using WS-Security in a SOAP response or SSL/TLS in a HTTP response.  This way, an attacker must resend the whole message to be successful"

To that end, one of the options that we are considering re: Digital Signature usage is the following (Given that the attribute query is over SOAP):

- The <samlp:AttributeQuery> element in the Request MUST be signed
- The <saml:Assertion> element in the Response MUST be signed (before Encryption takes place)
- The entire SOAP Request and Response messages MUST be signed using WS-Security.

Are there any potential issues with this approach we should be watching out for?

Regards,

- Anil

[1] SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems, OASIS
[2] SAML v2.0 Deployment Profiles for X.509 Subjects, OASIS
[3] http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf