RE: [security-services] [XML Signature]SAML profile of XML Signat ure

[George Robert Blakley III <blakley@us.tivoli.com>]

All,

>I think we need to be more specific about how the signature applies to the
>SAML data. I'd like to see the text specify one of:
>
>The signature MUST cover all elements of the SAML data (rather than just
the
>mandatory elements).
>
>or
>
>The RP MUST only rely on the portions of the SAML data that are covered by
>the signature.
>
>I prefer the first alternative, but can live with the second.

I agree with Irving on all points here; we need to be completely specific
on how the signature applies,
and I very much prefer the first alternative.

--bob

Bob Blakley (email: blakley@us.ibm.com   phone: +1 512 436 1564  fax: +1
512 436 1919)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.


Irving Reid <Irving.Reid@baltimore.com> on 10/30/2001 11:22:23 AM

To:   "'Krishna Sankar'" <ksankar@cisco.com>,
      "'security-services@lists.oasis-open.org'"
      <security-services@lists.oasis-open.org>
cc:
Subject:  RE: [security-services] [XML Signature]SAML profile of XML Signat
      ure



A few comments on Krishna's draft 0.002, sent out on Oct. 24/2001
(
http://lists.oasis-open.org/archives/security-services/200110/msg00135.html
):

In another message, I point out that the discussion of SAML messages
inheriting signatures (or other forms of authentication) from context
probably belongs in the Core. Aside from that, I have a specific comment
about lines 177-183 (Section 4.1).

I think we need to be more specific about how the signature applies to the
SAML data. I'd like to see the text specify one of:

The signature MUST cover all elements of the SAML data (rather than just
the
mandatory elements).

or

The RP MUST only rely on the portions of the SAML data that are covered by
the signature.


I prefer the first alternative, but can live with the second.


Line 208-211: I'd prefer the Canonical XML _without_ comments.

Lines 226-227: (if the multiple-statement assertion format survives in
Core)
No relationship is implied between the statements in a multiple statement
assertion. The semantic meaning is the same as if a separate assertion is
issued for each statement, and each assertion is signed using the same
method and key.

Lines 229-232: Similar wording change. Also, in line 232, s/sane/same/

 - irving -



-----------------------------------------------------------------------------------------------------------------

The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for
direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>