OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: [security-services] FW: comments on draft-dsig-02


Hi,

	I have made all the changes except for the one on P. 221. Do we need this ?
If so, what is the suggested wording ?

	The diff is turned on for easy (or more precisely quick) reading. Depending
on where this document ends up, there are a few editorial changes.

	Phil, where are you with the core spec ? Can you send it to me after your
edits so that I can add the DSig part plus change a few section references ?

	An editorial suggestion : I think the format of this document would be a
good format to follow with *all* our documents. I can help with the format
change if anybody needs help.

cheers
 |
 |  | -----Original Message-----
 |  | From: Mishra, Prateek [mailto:pmishra@netegrity.com]
 |  | Sent: Friday, November 16, 2001 1:25 PM
 |  | To: 'Krishna Sankar'; ''security-bindings@lists.oasis-open.org'
 |  | Subject: comments on draft-dsig-02
 |  |
 |  |
 |  | Hi Krishna,
 |  |
 |  | I presented your draft at the F2F in San Francisco. Your efforts
 |  | in putting together the draft were much appreciated by the
 |  | attendees. We worked thru the draft at a good level of detail
 |  | generating comments which are attached below:
 |  |
 |  |
 |  |
 |  | 98-99, 103-104
 |  | should mention the fact that message integrity of assertions must be
 |  | guaranteed by some means (in addition to obtaining XML from an
 |  | authenticated "originator")
 |  |
 |  | 178, 183
 |  | remove the word "mandatory" --- the signature should apply to
 |  | all elements
 |  |
 |  | 163
 |  | replace "Context" by "Rationale"
 |  |
 |  | 185
 |  | replace "Proposal" by "Rules for SAML Signature Inheritance"
 |  |
 |  | 186-190
 |  | This needs to be changed to normative language. I think the best way
 |  | would be to define the inheritance concept:
 |  |
 |  | Signature inheritance: occurs when SAML message
 |  | (assertion/request/response)
 |  | is not signed but is enclosed within signed SAMLsuch that the
 | signature
 |  | applies (better word?) to all of the elements within the
 |  | message. In such a
 |  | case, the SAML message is said to inherit
 |  | the signature and may be considered equivalent to the case where it is
 |  | explicitly signed.
 |  |
 |  | Do we need consideration "closest enclosing signature" here?
 |  |
 |  | Remove term "SAML domain"
 |  |
 |  | 210-211
 |  | There were several concerns here. First, [Sig] has Canonical XML
 |  | with no comments as mandatory to implement. So the suggestion
 |  | is that we should only say:
 |  |
 |  | "SAML implementations SHOULD use Canonical XML with no comments".
 |  |
 |  | This helps with inter-op as we are strongly pointing to a
 |  | mandatory-to-implement
 |  | feature.
 |  |
 |  | 203
 |  | replace "should use" by MUST
 |  |
 |  | 220
 |  |
 |  | This should be simplified and should just say: SAML does not
 | impose any
 |  | restrictions
 |  | in this area. Therefore, following [sig] KeyInfo may be absent.
 |  |
 |  | 221
 |  | (continued)
 |  | Signers SHOULD use RSA (this needs some detangling). RSA is not
 |  | mandatory-to-implement in [sig] but in practice will definitely be
 |  | implemented.
 |  |
 |  | 5.6 (beging at line 224)
 |  | Replace detailed text by:
 |  |
 |  | Use of signing does not affect semantics of statements within
 | assertions
 |  | in any way, as stated in Section XX of Core.
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |

draft-sstc-dsig-03-diff.doc



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


Powered by eList eXpress LLC