Re: Further thoughts on XML Signature on Registry

[sekhar vajjhala <sekhar.vajjhala@Sun.COM>]

Farrukh Najmi wrote:
> 
> 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.

Farrukh,

I spoke to Suresh on the phone. I think there is no major disagreement.
Here is a short list of issues (none of them is major):

1. <ds:> element in the first or last element in SOAP-header
   I will check this and clarify it.

2. Suresh is still of the opinion RegistryRequest can/should be carried
   in payload. I can talk to you about this.

3. Registry profile may need to have certificate information. 
   This is the current business model. I agreed to think
   about this (whether we need from the point of view of
   establishing trust).

None of the above are major issues.

So I will start work on the next rev of my document. I will try
to have this done by COB tomorrow or latest by Friday.

Sekhar

> 
> 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

-- 
Sekhar