[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. | | | | | | | | | | | | | | | | | | | | | | | |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC