Re: Further thoughts on XML Signature on Registry

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

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