Re: Further thoughts on XML Signature on Registry

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Guys,

Based on my understanding we are generally pretty close to a common understanding.
Can either of you summarize what are the remaining issues that we are not aligned
on, and for each issue list what options have been tabled? Maybe we should have a
meeting to discuss the issues identified. I am free today until 5pm. If we can
talk then Sekhar it woulbe nice if you can patch me in at 781-942-7277. Let me
know.

sekhar vajjhala wrote:

> Suresh,
>
> "Damodaran, Suresh" wrote:
> >
> > Here are some further thoughts on vanilla SOAP and ebXML MSG
> > signing for Registry.
> >
> > 1. Envelope:
> > Envelope has the <ds:/> elements as the last element of
> <SOAP-ENV:Header>
>
> I am not sure why you are REQUIRING that <ds:/> element to be
> the last element of <SOAP-ENV:header>. This seems overly
> restrictive.
>
> Q: What are you requiring this ?
>
> Note: ebMS requirement is that if there is more than one XMLDSIG
>       element then the first one must be used by ebMS receiver.
>       This as I understand was to allow for the fact that there
>       may be digital signatures because of SAML assertions (for
>       e.g.)
>
> > This will work for both MSG and vanilla SOAP.
>
> We are not specifying (and cannot specify) what is the envelope
> for ebMS. We can and are specifying what would be in the SOAP
> envelope.
>
> > In the vanilla SOAP we don't need to use <eb:Manifest/> (what this
> > results is in an ability to check conformity with ebXML schemas -which
> > is not reqd anyway). In the ebXML case, use <eb:Manifest/>. Signatures
> > are optional, and is primarily used for source authentication - data
> > integrity
> > is done thru payload signing.
> >
> > 2. Payloads:
> > Payloads of requests to Registry have the RegistryRequest as the first
> > payload.
> > If we design it this way, it will work for both vanilla SOAP and ebXML MSG.
> > It is possible to have the RegistryRequest signed as per Registry.xsd, if we
> > enhance Registry.xsd with <ds:/>.
>
> I was confused about this and I talked to Farrukh about this.
> There is a confusion in terminology here. Payloads are those
> objects which are sent as SOAP attachements. In this sense,
> RegistryRequest itself is not a payload. It is sent in the
> SOAP-Body of the SOAP message. This is the assumption that
> I made in my document.
>
> It was also my understanding from talking to Farrukh that
> you two had decided not to enhance the Registry schema with
> the digital signature. I am personally against that.
> Is this your understanding ?
>
> >  The other payloads need to be signed with
> > enveloping signatures if non-XML, and enveloped signatures if XML.
>
> I am not very clear on exactly what you are proposing.
> I need some more details here.  So let me just summarise
> what I have gathered so far on my side. We can then
> proceed further.
>
> 1. I think we agree that the payload signature is bound
>    to the payload. So putting a signature in the SOAP header
>    is not the correct way to do it.
>
> 2. In order to work with both "ebRS over ebMS" and
>    "ebRS over SOAP", the payload signature would have to be
>    part of the payload itself or somehow be associated with
>    the payload. ebMS does not impose any structure on the payload
>    itself.
>
>    I believe we agree on this.
>
> I have listed several possible ways to associate payload and its
> signatures below ( I have included feedback that I have obtained
> from you and others ). All of the below would agree
>
> 1. Payload and Signature as two separate attachements.
>
>    A payload that is signed could be sent as two payloads i.e.
>    as two separate SOAP ATTACHMENTS ( i.e. two MIME multipart
>    bodies).
>
>    In this case, the signature and the payload are not aggregated
>    at the payload level. Here is an example
>
>    ## - denote my comments
>
>    MIME-Version:1.0
>    Content-Type: Multipart/Related; boundary=MIME_boundary;
> type=text/xml
>
>    ## The following root part contains the message For e.g.
>    ##    SubmitObjectRequest
>    ##
>    ##  The Content-Type MUST be text/xml according to SOAP1.1 spec
>
>    --MIME_boundary
>
>    Content-Type: text/xml;
>
>    <SOAP-ENV: Envelope>
>
>        <SOAP-ENV:Header>
>            ....
>            <ds:..> Digital signature in Header
>            ....
>            </ds:..>
>            ....
>        </SOAP-ENV:Header>
>        ....
>        <SOAP-ENV:Body>
>            SubmitObjectRequest
>        </SOAP-ENV:Body>
>
>     </SOAP-ENV:Envelope>
>
>    ## Payload
>    -- MIME_boundary
>    Content-Type:
>
>    --MIME_boundary
>
>    Content-ID:  ...
>    Content-Type: text/xml
>
>    XMLDSIG for the payload
>
>    --MIME_boundary
>
> 2. Alternately, payload and signature could be aggregated at the
>    payload level i.e. both the payload and the signature are sent
>    as a single SOAP ATTACHMENT which is itself a multipart. For e.g
>    multipart/mixed or multipart/Related. An example of this signature
>    is shown below. I have shown multipart/Related but it could be
>    multipart/mixed as well. I may not have gotten all the details
>    right - but it illustrates the idea.
>
>
>    ## - denote my comments
>
>    MIME-Version:1.0
>    Content-Type: Multipart/Related; boundary=MIME_boundary;
> type=text/xml
>
>    ## The following root part contains the message For e.g.
>    ##    SubmitObjectRequest
>    ##
>    ##  The Content-Type MUST be text/xml according to SOAP1.1 spec
>
>    --MIME_boundary
>
>    Content-Type: text/xml;
>
>    <SOAP-ENV: Envelope>
>
>        <SOAP-ENV:Header>
>            ....
>            <ds:..> Digital signature in Header
>            ....
>            </ds:..>
>            ....
>        </SOAP-ENV:Header>
>        ....
>        <SOAP-ENV:Body>
>            SubmitObjectRequest
>        </SOAP-ENV:Body>
>
>     </SOAP-ENV:Envelope>
>
>    ## Payload and digital signature aggregated together
>    Content-Type: Multipart/Related; boundary=PAYLOAD_boundary;
> type=text/xml
>
>    ## The root part of the body must be the digital signature.
>
>    --PAYLOAD_boundary
>
>    Content-Type: text/xml
>
>    XMLDISG here
>
>    --PAYLOAD_boundary
>
>    Content-ID:  <domainname.example.com>
>    Content-Type: application/xml
>
>    --PAYLOAD_boundary
>
> 3. Another way to aggregate the above is to use multipart/signed.
>    In fact the aggregation noted in 2. is duplicating essentially
>    what multipart/signed does.
>
> I would like to rule out option 3 since multipart/signed may not
> be supported by a SOAP processor which might otherwise support
> MIME.
>
> That leaves 1 and 2. Option 2 is better than 1 because:
>
> a. it seems cleaner
> b. if there is some payload that is signed and some that is not,
>    then signatures have to be generated only for those payloads
>    which need to be signed. With option 1, it is harder to
>    represent this case.
>
> I am inclined to go with option 2 - although 1 would work fine
> as well.
>
> Does anyone have issues with this ? Are there any other
> implementation considerations ?
>
> Q: What did you have in mind with enveloping and enveloped signatures.
>
> BTW, Enveloped signatures as Farrukh pointed out to me is not
> meaningful here since enveloped signatures by definition are
> signatures which are embedded within the content. But content that is
> being submitted can't be expected to have a digital singature in it.
>
> >
> > 3. Contracts:
> > ebXML MSG can refer to a CPAId, whereas vanilla SOAP can refer to a Registry
> > Profile - can we enhance Registry.xsd (<Registry Profile>) to include
> > <ds:KeyInfo>?
>
> I think you are mirroring the ebMS model here. I think this is not
> necessary for the following reason. We have a particular use which
> ebMS does not have i.e. RC2 wants to verify RC1's signature. To solve
> this use case, putting ds:KeyInfo in the Registry profile won't work.
> It has to be transmitted from RC1 to Registry and from Registry to
> RC2. Once we have this mechanism, then we might as well use it
> for RC to Registry Case. At least this is my position right now.
>
> >
> > 4. Positioning: use of vanilla SOAP does not give the sophisticated
> > features (reliable messaging, in particular) of ebXML MSG. ebXML MSG
> > also has some advanced features (security profiles and such) that
> > are useful for a sophisticated user. This message, I hope you agree,
> > should be a basic principle.
>
> Absolutely. I keep referring to ebMS or vanilla SOAP only so we
> can solve the problem of signing of content for both cases.
>
> >
> > Like to thank Farrukh for an enjoyable conversation on the topic.
> >
> > Regards,
> > -Suresh
>
> I would like to hear from some comments.
>
> Thanks !
>
> --
> Sekhar
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard