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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

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

Subject: RE: [regrep-security] FW: [ebxml-msg] XMLDSIG and v1.05 comments


Comments inlined below

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Thursday, October 25, 2001 10:30 AM
To: Damodaran, Suresh
Cc: 'regrep-security@lists.oasis-open.org'
Subject: Re: [regrep-security] FW: [ebxml-msg] XMLDSIG and v1.05


Some comments/responses below.



Damodaran, Suresh wrote:

> Sekhar,
> FYI: My comments on ebXML MSG use of xmldsig
> and response from the editor. I am reposting because
> these would be relevant to our work on Registry xmldsig.
> Cheers,
> -Suresh 
> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Tuesday, October 23, 2001 2:24 PM
> To: Damodaran, Suresh; ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] XMLDSIG and v1.05 comments
> I agree on items 1-5 (some of them are REQUIRED).  Since no one has
> commented, I
> will make these changes.  (Comments anyone?)
> I can see some benefits to item 6 (use of the ds:Signature/Manifest) but I
> am
> concerned that it will cause systems not to be Interoperable if some
> do
> this and some don't.  Anyone have thoughts?
> Regards,
> David Fischer
> Drummond Group.
> P.S.  Mr. Burdett, would you mind capturing these in the change DB?
> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> Sent: Friday, October 19, 2001 3:44 PM
> To: 'ebxml-msg@lists.oasis-open.org'
> Subject: [ebxml-msg] XMLDSIG and v1.05 comments
> I have some comments and change proposals on Section 4.1.3 Signature
> Generation
> 1. Line 1088 suggests that ds:CanonicalizationMethod element is optional
> in ds:SignedInfo. I don't believe it is true. Section 4.3.1 of XMLDSIG
> [1]
> states that "CanonicalizationMethod is a required element that specifies
> canonicalization algorithm
> applied to the SignedInfo element...". Therefore, I propose we restate the
> sentence
> with a "MUST." Para starting 1090 needs to be rewritten too.

I agree. I think that what happened here is that the intent was to say that
the choice of C14N algorithm was optional (up to the parties to
agree upon). Clearly, the element is REQUIRED.

> 2. I also propose we provide a RECOMMENDED algorithm for
> CanonicalizationMethod as
> http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (this one omits comments)
> e.g.,
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

That would be fine, but some consideration should be given to
providing guidance as to what implications there might be in
excluding comments. It may be that the comments are significant...
Both the with and without comments algorithms are REQUIRED to be
supported by conformant XMLDSig implementations, so either
should be acceptable.
I could not think of any interesting comments people will put
on SignedInfo element (actually no comments are put). Nor can
I see any interesting comments put on SOAP:Envelope (item 4 below) - this
will likely be discarded before reaching the actual apps.
Payload algorithm was not within the scope of MS spec, but it is
for Regrep spec. We could go both way for the payload.

> 3. Sentence on line 1100 says that the signature is calculated over the
> Header. I would argue that the signature be calculated over
> SOAP-ENV:Envelope instead of SOAP-ENV:Header. This would include the
> <eb:Manifest> in the SOAP-ENV:Body. Why is this needed? It is possible
> ds:Signature element is eliminated from the message after signature
> validation is done. Beyond that point, the application would look at
> eb:Manifest to locate the resources. Therefore, the integrity of
> element is important. The change from SOAP Header to SOAP Envelope needs
> be made in the whole section.
> 4. Line 1107 talks about the ds:Transform elements. I propose we add
> REQUIRED ds:Transform
> element
> <ds:Transform
> for the SOAP Envelope after the "enveloped-signature" transform. This new
> transform will make sure the SOAP envelope is canonicalized before signed.

I don't believe that this is necesary. It is redundant is it not?
No it isn't. This is for the Envelope, whereas (2) is for SignedInfo.

> 5. Line 1120 suggests that URI attribute need not match the manifest
> reference. I don't know what purpose this serves. I propose we delete
> "However, this is NOT REQUIRED"
> 6. Line 1103: The Type attribute is optional according to the spec. Note
> that if the reference type is
> not manifest [http://www.w3.org/TR/xmldsig-core/#sec-Manifest]  the
> reference (i.e., payload) is required to be
> validated as per XMLDSIG. We may want to give more control to the
> application on validation. Therefore, mention of the manifest Type would
> good. The manifest itself is an ds:Object which is an element of
> ds:Signature. I propose we REQUIRE the type attribute for the Reference
> element of SOAP Envelope with a value of either
> http://www.w3.org/2000/09/xmldsig#Object or
> http://www.w3.org/2000/09/xmldsig#Manifest.

I'm not sure I agree. I don't think that you want to give this
level of control to the application. The purpose of the signature
is to provide for integrity of the message. If the signature validation
fails, it means that the message may have been tampered with in transit.

There is more to it than the obvious here. I don't want to debate this
issue on this list, rather on the MSG mailing list where it will be more
appropriate. Briefly though, you are right, you don't want to mix
signed and unsigned content because it is a security risk. There are however
business and performance reasons that will let people use manifests. I am
suggesting that if they use manifests, MS spec provide a clean way
to use it.

> ----------------------------------------
> [1] XML-Signature Syntax and Processing - W3C Proposed Recommendation
> http://www.w3.org/TR/xmldsig-core/
> Cheers,
> -Suresh
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC