xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Vasilik" <eric...@bea.com>
Subject RE: xmlbeans xml security
Date Sat, 03 Jul 2004 03:47:26 GMT
Hmmm ... At the moment, the architecture of the saver is not sensitive
to the schema type associated with the instance.

The design of XmlBeans is such that the XML Infoset (the store) as
exposed by the XmlCursor/DOM is not influenced by the schema type of the
instance.  However, when one accesses the instance via XmlObject, in
particular the generated XmlObjects, then the schema comes into play.
For example, values for default attributes will be present.

The goal is to keep the fidelity of the XML as it was parsed in.  If
c14n is sensitive to the schema type of an instance, then an
implementation based on the saver is probably not the right place to
start.

I would recommend writing the c14n serialization using XmlCursor.  One
can navigate to the XmlObject for an element and interrogate the Schema
type, looking for default attributes, for example, and including them in
the serialization.  This assumes that the instance is valid with respect
to the schema.  Does c14n require that the instance is schema valid?

Also, it seems that the handling of namespaces is significantly
different for c14n than the current saver handles them.

You will have total control over the serialization this way and, the
c14n serialization can be written as a utility on XmlBeans as opposed to
being in XmlBeans.  The XmlCursor interface is meant to enable high
performance access to the store.  

Also, there are two other alternatives to using XmlCursor.  In the v2
codebase, there is a low-level cursor access to the store which you
could use, but the c14n implementation would then become an internal
feature of XmlBeans.   This approach would probably yield the highest
performance c14n implementation.

The other approach would be to use the implementation of the live DOM on
the v2 store.  Is there an open source implementation of c14n which is
implemented on top of a DOM?  Could we use it instead of doing it again?

- Eric

-----Original Message-----
From: Berin Lautenbach [mailto:berin@wingsofhermes.org] 
Sent: Friday, July 02, 2004 4:04 PM
To: xmlbeans-dev@xml.apache.org
Subject: Re: xmlbeans xml security

Eric,

The spec was written before Schema was really out there and therefore 
default attribute handling only referenced DTDs.  And you are correct - 
any default attributes must be represented explicitly in the canonical 
form.  My understanding is that is true whether they come from a schema 
or a DTD.  Given the intent of c14n, that makes sense - it's supposed to

give you the input to a digest algorithm algorithm, where the digest is 
changed if anything about the document changes.

I've implemented C14n for the C++ xml-security version, and the Java 
variant has just gone through some significant reviews for performance 
reasons.  Given the recent work, there may be some input that we can 
provide from the xml-security project.

Cheers,
	Berin

Eric Vasilik wrote:

> Are you saying that c14n says that the canonicalized form for a
document
> must include defaulted attributes that were specified by an XmlSchema?
> That is to say, if an element does not have attribute x, but the
> XmlSchema it is bound has a default attribute value for x, the
canonical
> form must include that attribute?  The spec seems to suggest that the
> default attrs specified in a DTD must be included, but, that's a
parsing
> issue for XmlBeans, and is irrelevant when producing the canonical
form
> for a loaded document in Xmlbeans.
> 
> Right now, the saver does is not influenced by the schema associated
> with the instance being saved.
> 
> - Eric
> 
> -----Original Message-----
> From: David Waite [mailto:mass@akuma.org] 
> Sent: Thursday, July 01, 2004 2:48 PM
> To: xmlbeans-dev@xml.apache.org
> Subject: Re: xmlbeans xml security
> 
> 
> On Jul 1, 2004, at 3:30 PM, Noah Campbell wrote:
> 
> 
>>I'll assume that BEA's impl is not available for general consumption.
> 
> 
> I dunno what BEA's impl looks like :)
> 
> 
>>In regards to the current xmlstore, aren't the namespace names
>>synthetic anyway?  I mean, you don't need to rely on the name except
>>for its ability to link an element, etc to a namespace.  If someone is
>>passing information through the namespace name then this might be
>>considered a potential leak if full infoset is preserved.  This is
>>probably contrieved and sorta silly but it is still something to
>>consider.
> 
> 
> In normal XML, sure. When you start canonicalizing xml, namespace 
> prefixes matter, because qname types require schema awareness on some 
> level to identify. If your canonicalized form allowed arbitrary 
> prefixes to be chosen, someone could conceivably change the meaning of

> a document by putting a qname value in a different namespace.
> 
> The only real awareness of a schema or dtd used by canonicalization is

> expansion of attribute default types. I believe all the 'secure' 
> messages (ws-security, saml) avoid default namespaces so they don't 
> encounter this really ugly side-effect.
> 
> The issue is that when you parse in xml, it uses a qname and stores
the 
> namespace URI and the local name, but not the prefix. If you get a 
> signed document in which declares a namespace both with a prefix and
as 
> the default namespace (perfectly valid) this breakage of infoset 
> fidelity will cause the canonical form to differ where the saver chose

> a different namespace than was originally used, thus you will get a 
> different hash out, and have very little idea what happened.
> 
> 
>>(a silly side channel attack for example)
>>
>><element xmlns:thePassphraseIsCheese="http://t.l.d/secureMessage">
>>      <thePassphraseIsCheese:passphraseProtectedElement>
>>               09832jkfadilafj#$@#rkfdali9fdalksdjf93aldkfja093ajfd
>><thePassphraseIsCheese:passphraseProtectedElement>
>></element>
>>
> 
> Yes, fire the developer who did this ;-)
> 
> The issue is that the W3C allowed content to become dependent on 
> namespaces, as if namespaces weren't tricky enough as is. XPath 
> expressions and QName values in attributes and text nodes makes the 
> namespaces important, as a transformation that changes the namespaces 
> now needs to understand the context of the document which they are 
> placed on. So while you could make a filter which replaced the prefix 
> above with 'x0', it would need to know the schema, and would have to 
> filter _after_ canonicalization and any validation associated (such as

> xml-dsig)
> 
> -David Waite
> 
> 
> -
---------------------------------------------------------------------
> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> 
> 
> -
---------------------------------------------------------------------
> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> 
> 
> 

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message