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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: RE: [dss] XMLData opaqueness ?


Hi,

  I am bringing this up because this is exactly what my parser is doing
(with encoding=None) when I build the XML request document. Because I am
building by setting node content, the library (libxml2) knows what is
structure and what is content. When I serialize the parsed object in order
to prepare to send it to the DSS Server, it substitutes the escapes only in
the node containing the XML content.

  My server happily parses the request (with the XML in the XMLData node).
Then again I am using the same library on both sides.

  Rich ... Is escaped HTML valid in a UTF-8 encoded XML document ? Is the
referenced escaping OK ?

Cheers,
Ed 

-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] 
Sent: April 5, 2005 11:56 AM
To: ed.shallow@rogers.com
Cc: 'OASIS DSS TC'
Subject: Re: [dss] XMLData opaqueness ?

Ed,

Your suggestion is to escape all the '<' and '>' so that in plain words,
within <XMLData> there is not xml any more but a String coming from the
serialization of a XML document or subtree where '<' and '>' have been
escaped...
I have a doubt: are we sure that any parser would be able to correctly undo
the escape operations? I mean, what if within the original XML document
there are '<' or '>' escaped documents as text (ie, as characters of the
text content of certain elements)?
Are we sure that the parser at the receiver will be able to distinguish
which escaped characters will have to unescape?

Juan Carlos.

Edward Shallow wrote:

>Folks,
>
>   With respect to passing in content inside the XMLData element (on 
>either a Verify or Sign) do you believe it would be legitimate to 
>ensure opaqueness of the content by escaping all the <'s and >'s ?
>
>   For example replace all < with &lt; and all > with &gt;
>
>   See attached for an explicit example.
>
>   In fact my XML library (Gnome libxml2) is doing exactly this when I 
>invoke the serialize() method on the parsed xml tree object.
>
>   This in fact allows an implementation to support an xml declaration 
>line (i.e. <?xml version="1.0" encoding="UTF-8"?> ) which might be 
>inside the content (and whose encoding may be different from the request's
e.g.
>ISO-8859-1 or UTF-16) without causing parsing problems.
>
>   Is anyone else having similar challenges ?
>
>   Browsers accept this escaped nesting.
>
>Ed
>  
>
>-----------------------------------------------------------------------
>-
>
><?xml version="1.0"?>
><VerifyRequest>
>    <InputDocuments>
>        <Document ID="" RefURI="" RefType="">
>            <Schema></Schema>
>            <XMLData>&lt;?xml version="1.0" encoding="UTF-8"?&gt; 
>&lt;a&gt;
>        &lt;b&gt;
>                &lt;c&gt;
>                        &lt;c1 MimeType="text/plain"&gt;This is the
data&lt;/c1&gt;
>                        &lt;c2 MimeType="text/plain"&gt;This is the
data&lt;/c2&gt;
>                        &lt;c3 MimeType="text/plain"&gt;This is the
data&lt;/c3&gt;
>                &lt;/c&gt;
>        &lt;/b&gt;
>        &lt;d&gt;
>                &lt;d1 MimeType="text/plain"&gt;This is the data&lt;/d1&gt;
>                &lt;d2 MimeType="text/plain"&gt;This is the data&lt;/d2&gt;
>        &lt;/d&gt;
>        &lt;e&gt;
>                &lt;f&gt;
>                        &lt;f1 MimeType="text/plain"&gt;This is the
data&lt;/f1&gt;
>                        &lt;f2 MimeType="text/plain"&gt;This is the
data&lt;/f2&gt;
>                        &lt;f3 MimeType="text/plain"&gt;This is the
data&lt;/f3&gt;
>                &lt;/f&gt;
>                &lt;Signature
xmlns="http://www.w3.org/2000/09/xmldsig#"&gt;
>                        &lt;SignedInfo&gt;
>                                &lt;CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/&gt;
>                                &lt;SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/&gt;
>                                        &lt;Reference URI=""&gt;
>                                                &lt;Transforms&gt;
>                                                        &lt;Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/&gt;
>                                                &lt;/Transforms&gt;
>                                                &lt;DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/&gt;
>
&lt;DigestValue&gt;pgu/Uz5BP+zLoBBrBgw53jd6HkQ=&lt;/DigestValue&gt;
>                                        &lt;/Reference&gt;
>                        &lt;/SignedInfo&gt;
>
&lt;SignatureValue&gt;ZdzhD7MgikUel39mWp3nmG3whg/WzmevyEYDM7ZU/HREssF0CayKdM
uDqjktSf81YLxJPheYQh4VobTmUyu8CMST6Eu5ltrEQk3Z9004cDQvLC1/i9Vf4DEnpHdocGH0no
92t2EH0ompmAQV02+uAffKO78/Dxi1qmKnvr7iZK0=&lt;/SignatureValue&gt;
>                        &lt;KeyInfo&gt;
>                                &lt;KeyName/&gt;
>                                &lt;X509Data&gt;
>                                
>&lt;X509Certificate&gt;MIIEUDCCAzigAwIBAgIBJTANBgkqhkiG9w0BAQUFADCB8zEL
>MAkGA1UEBhMCQ0Ex 
>EDAOBgNVBAgTB09udGFyaW8xDzANBgNVBAcTBk90dGF3YTEgMB4GA1UEChMXQ2Fu
>YWRhIFBvc3QgQ29ycG9yYXRpb24xGjAYBgNVBAoTEUZvciBUZXN0IFVzZSBPbmx5
>MR0wGwYDVQQLExRFbGVjdHJvbmljIFBvc3QgTWFyazE2MDQGA1UEAxMtQ2FuYWRh
>IFBvc3QgQ29ycG9yYXRpb24gQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSwwKgYJKoZI
>hvcNAQkBFh1TZWN1cml0eU9mZmljZXJAY2FuYWRhcG9zdC5jYTAeFw0wNDA2MDgy
>MDQwMzlaFw0wOTA2MDcyMDQwMzlaMIHVMQswCQYDVQQGEwJDQTEQMA4GA1UECBMH
>T250YXJpbzEPMA0GA1UEBxMGT3R0YXdhMSAwHgYDVQQKExdDYW5hZGEgUG9zdCBD
>b3Jwb3JhdGlvbjEaMBgGA1UEChMRRm9yIFRlc3QgVXNlIE9ubHkxHTAbBgNVBAsT
>FEVsZWN0cm9uaWMgUG9zdCBNYXJrMR8wHQYDVQQDExZFZHdhcmQgUGF0cmljayBT
>aGFsbG93MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmRzaGFsbG93QHlhaG9vLmNhMIGf
>MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwTN93TVLfN4UiHzo714UsPDXQlb/p
>VNUMXPzSQnEgQe8HuAn7PU2HR5hY8vmE3V8K2w9h5oqzybuUzwASTA0Pp4IDus43
>/aYDzqMD0d3FfS8a+w64Vdmzky+AHxM0I5kvzmJ7NXyvZc6lweW5WNDqY/vUzHG5
>XTmP4av7Z6rz2wIDAQABo4GOMIGLMAwGA1UdEwQFMAMCAQAwHQYDVR0OBBYEFPQ8
>gj6eGzywxxOG4Q0mJcHLOibPMB8GA1UdIwQYMBaAFDlJBm7JMYyBXc1i6V4IYkQv
>K3pqMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jYTEudXB1LmludC9tYXN0ZXIu
>Y3JsMAsGA1UdDwQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAa/QccSERNizFPuFX
>91xgk3Gonlkiyaan4ZiGuD10q5608dD3DaQmcRW5vCyD3yuix+uIO5GZFpheN3OB
>+gbs0EDMRWZHupVja2Meghb/e3XOAYilLnTkHPfdycNsCz+AL5fyEAHvQoAo9kV5
>LVG2SrDmJ+fcsiKnCTAsKFExCPuqSYUKy8sw5+C3UxHqz0a7bVg9sQvPSGAy0U6Y
>xiPrPUBwlFR2uVmkQbRnZD3/m6Ypxajyq5Klie72TAwP4RuB3NQnhDclDuTrJ6b3
>AKYNb3RKmwJXRl9rC5IUrQ4jByzBNMilqoX6zKxB+1+GcH5WvuKVQwElbwVPHkpM
>EwZOBg==&lt;/X509Certificate&gt;
>&lt;X509SubjectName&gt;emailAddress=edwardshallow@yahoo.ca,CN=Edward 
>Patrick Shallow,OU=Electronic Post Mark,O=For Test Use  Only,O=Canada 
>Post Corporation,L=Ottawa,ST=Ontario,C=CA&lt;/X509SubjectName&gt;
>&lt;X509IssuerSerial&gt;
>&lt;X509IssuerName&gt;emailAddress=SecurityOfficer@canadapost.ca,CN=Can
>ada Post Corporation Certificate Authority,OU=Electr onic Post 
>Mark,O=For Test Use Only,O=Canada Post 
>Corporation,L=Ottawa,ST=Ontario,C=CA&lt;/X509IssuerName&gt;
>&lt;X509SerialNumber&gt;37&lt;/X509SerialNumber&gt;
>&lt;/X509IssuerSerial&gt;
>&lt;/X509Data&gt;
>                        &lt;/KeyInfo&gt;
>                &lt;/Signature&gt;
>        &lt;/e&gt;
>&lt;/a&gt;
></XMLData>
>        </Document>
>    </InputDocuments>
>    <NodeName></NodeName>
></VerifyRequest>
>
>  
>
>-----------------------------------------------------------------------
>-
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that 
>generates this mail.  You may a link to this group and all your TCs in 
>OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>





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