[Animl-develop] Re: XML-DSig, Container Tags

[Burkhard S. <b_...@us...>]

Hi Anh Dao and Maren,

the ds:Reference mechanism is the right way to go. That way you can 
point to the item(s) you want signed.

I spent some more time to think whether we really need the container 
tags (XYZSet). The following example came to my mind. Let's assume we 
have a VectorSet vs1 containing two Vectors v1 and v2 -- like this:

Scenario 1 (with XYZSets):

<Page>
     <VectorSet id="vs1">
         <Vector id="v1"> ... </Vector>
         <Vector id="v2"> ... </Vector>
     </VectorSet>
     ...
</Page>


Scenario 2 (without XYZSets):

<Page>
     <Vector id="v1"> ... </Vector>
     <Vector id="v2"> ... </Vector>
     ...
</Page>

Now the question is: Is a signature over [vs1] in scenario 1 equivalent 
to a signature over [v1, v2] in scenario 2? The surprising answer is "no".

In both scenarios, the signatures prevent the modification of the data 
in v1 and v2. But in scenario 2, we could easily introduce another 
Vector v3 without invalidating the signature - because v3 is outside the 
scope of the signature:

<Page>
     <Vector id="v1"> ... </Vector>
     <Vector id="v2"> ... </Vector>
     <Vector id="v3"> ... </Vector>
     ...
</Page>

In scenario 1, doing this would make the signature invalid (which is the 
desired behavior).

So taking out the container tags (XYZSets) would significantly weaken 
the security of our digital signature mechanism: It allows data to be 
added without the ability to detect it (unless you sign the entire 
surrounding element - which will not always be possible). This will make 
the 21 CFR Part 11 folks very unhappy.

Therefore I would tend to leave the container tags in.

Best wishes,
Burkhard


Anh Dao Nguyen wrote:
> 
> Hi Maren,
> 
> I have developed a small digital-signature-signing and –verification 
> program which allows signing numerous data objects (elements) all at 
> once. If the purpose for creating the “XYZSet” containers was to be able 
> to sign several elements of similar type at one time, then it would be 
> unnecessary. You are right, we theoretical can remove all the 
> Set-containers from the Core Schema.
>  
> At the beginning stage of the application development, I used 
> “Object”-element-concept (according to the paragraph 2.3 of the 
> DSig-Specification) to sign multiple data objects. That means the data 
> being signed must be accommodated within the “Object” element.
>  
> For instance:
> ….
> <Sample derived="false" *id="signitem1"* sampleID="SRM936">
>                          …
> </Sample>
> …….
> <Signatures>
>              <Signature Id="sig0">
>                     <ds:SignedInfo>
>                           <ds:Reference URI="*#signObject1*">
>                            …
>                            </ds:Reference>
>                     </ds:SignedInfo>
>                     <ds:*Object* Id="*signObject1*">
>                            <Sample derived="false" *id="signitem1"* 
> sampleID="SRM936">
>                                             …
>                            </Sample>
>  
>                     </ds:Object>
>              </Signature>
> </Signatures>
>  
>  
> As everyone already knew, each ID must be unique within an 
> AnIML-document. Therefore I had to remove the original data of the 
> signed element (outside of the signature element) from the AnIML file. 
> Otherwise, we would have double ID in the AnIML file (id=”signitem1”). 
> Finally, I decided to utilize “Reference” element within the “SignInfo” 
> element to refer to the signed data by using “URI” attribute (see the 
> attach file). 
>  
> ….
> <Sample derived="false" id="*signitem1*" sampleID="SRM936">
> …
> </Sample>
> …….
> <Signatures>
>              <Signature Id="sig0">
>                     <ds:SignedInfo>
>                           <ds:Reference *URI="# signitem1"*>
>                            …
>                            </ds:Reference>
>                     </ds:SignedInfo>
>                    
>              </Signature>
> </Signatures>
>  
> 
> Anh Dao
> 
> 
> 
> 
> At 05:57 AM 1/26/2005, Mar...@wa... wrote:
> 
>> Hi Mark,
>>
>> > But let's go on and see if we can make a better hierarchical model.
>> OK. I had a look at the XML-DSIG Specification
>> (http://www.w3.org/TR/xmldsig-core/) yesterday, and it looks like we can
>> get rid of the "XYZSet" containers in the Core Schema:
>> The idea of these was, as far as I remember, to be able to sign several
>> elements of the same kind at once.
>> XML-DSIG has an element called "Signature" with several children. The one
>> that tells you what you are signing is "SignedInfo/Reference", which has
>> an optional "URI" attribute where you state the URI of the object you're
>> signing. Now, paragraph 2.3 of the Spec says that you can include 
>> multiple
>> "Reference" elements within "SignedInfo" to sign multiple data objects.
>> Judging from this, we don't need the containers any more. I made a new
>> core schema based on animl-core 1.05 where I took the container elements
>> out:
>>
>> By the way, I am not sure any more whether this is the version with the
>> corrected references or not. Maybe Anh Dao can help clarify this.
>>
>> However, I'm wondering whether we really need the possibility to sign
>> single elements in the AnIML file, or whether it would suffice to be able
>> to sign the whole document. Any thoughts on that?
>>
>> BTW, The technique schema remains untouched by the changes I made.
>>
>> I have some more questions/suggestions about schema details:
>>
>> - In the Technique Schema, we have an attribute "maxOccurs" and an
>> attribute "modality". It would be more consistent to replace "modality"
>> with "minOccurs" (=0 or 1).
>>
>> - What is the exact meaning of the attributes "inheritable" and
>> "upwardsInherited"? These seem rather technical to me; what do we need
>> them for?
>>
>> - What is the benefit of assigning "consumed" or "produced" to a sample?
>>
>> - Parameters are usually not stored as binary data. Is it useful to have
>> float and double data types for them? Storing non-binary data as 
>> floats or
>> doubles incurs a loss of precision as the decimal numbers are converted
>> internally to the closest binary number, which is not always exact. We
>> might want to be able to use the XML datatype xs:decimal as well.
>> Another issue (which we probably can't solve in XML) is that you cannot
>> specify how high the precision of your data is. "1.200" is something
>> different from "1.2" as the two zeroes tell you that the precision is
>> three decimal digits. From what I've found in an XML book, however, it
>> looks like XML views the trailing zeroes as "non-significant".
>>
>>
>> > I don't think I had a response on the need for the concept of an
>> > "analysis" in AnIML
>> I'm going to look into this soon. Maybe Mark Mullins can tell us about 
>> his
>> experiences implementing AnIML?
>>
>>
>> Maren.
>>
>>
>> Mit freundlichen Grüßen / Best regards
>>
>> Dr. Maren Fiege
>> Product Manager
>>
>> --------------------------------------------------------------
>> Waters Informatics
>> Europaallee 27, D-50226 Frechen, Germany
>> Tel. +49 2234 9207 - 0 Fax. +49 2234 9207-99
>> Reply to: mar...@wa...
>> http://www.creonlabcontrol.com <http://www.creonlabcontrol.com/>
>> http://www.watersinformatics.net <http://www.watersinformatics.net/>
>> --------------------------------------------------------------
>> ===========================================================
>>
>> The information in this email is confidential, and is intended solely 
>> for the addressee(s). Access to this email by anyone else is 
>> unauthorized and therefore prohibited.  If you are not the intended 
>> recipient you are notified that disclosing, copying, distributing or 
>> taking any action in reliance on the contents of this information is 
>> strictly prohibited and may be unlawful.
>>
>> ===========================================================