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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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


Subject: RE: [ebxml-dev] Response to Damian



Thanks Duane for responding to Damian's questions. 
I will follow up on the following one.

>> One more issue. What if the one client digitaly sign CPP, and put
>> signature to CPP XML in tag tp:Signature. Then client put CPP in our 
>> repository. We divide it and put all values to tables. When second 
>> client want to download the first client CPP, we will get values from

>> tables, and put to XML. But then the signature won't meet the CPP XML

>> file :(

The signature over the CPP really only enables trusting the CPP as "data
originating from" the signer.

If you reassemble the CPP from the bits you have stored in tables, there
could, of course, be problems. XMLDsig, however, has defined several
transforms for use in signatures that might allow reassembly in such a
way that the signature would
check out. I have not seen any requests before concerning this
reassembly question, so I will forward your issue to the OASIS TC to see
what, if anything, it could do to encourage white space usage,
transforms on signatures, etc that
would help make this work.

>> So if I think properly, we must not divide signed CPP? If we get 
>> signded CPP we must store it in one field in table?

The easiest resolution IMO would be to store the original somewhere just
for the purpose of checking the signature or sending it out to others,
and then populate your tables as needed by pulling stuff out of the DOM
tree using your preferred API. This costs a little in storage but saves
a lot of headaches in coding and elsewhere.



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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC