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 Thu, 01 Jul 2004 16:10:17 GMT
The saver is a piece of code in the store.  You'll find it in Saver.java
in the newstore2 source directory.

Basically, the saver is created when XmlBeans needs to turn a piece of
the store into text.  This piece can be a whole document or any piece of
the Infoset.  Note that the saver is used for producing text for
XmlCursor and XmlObject.

The saver has been totally rewritten between v1 and v2.  The v2 saver is
much cleaner.  Let me outline the architecture of the Saver.  First,
there is an object in the new store called Cur which provides low-level
cursor like access to the contents of a store.  The saver defines
another, much simpler, cursor interface call a SaveCur.  The job of the
various SaveCur's is to make the contents exposed by a Cur or another
SaveCur look different.

For example, the PrettySaveCur's job is to take another SaveCur, and
remove/introduce whitespace for the purposes of pretty printing a
document.  The FragSaveCur takes a piece of the store defined to be
between two low-level Cur's and simulate a well formed Xml document.
There are others.

Then, the main Saver class takes a low-level Cur, and creates the right
combination of SaveCurs to produce well formed output.  It also looks at
the various XmlOptions.  The primary job of the Saver class is to
add/remove namespace attributes so that the names of elements and
attributes are preserved properly.

Then there is the TextSaver class.  The TextSaver derives from the Saver
class.  Its job is to produce the actual characters, based on direction
from the base Saver class.  There are a number of abstract methods on
the Saver class which are called for various pieces of the Infoset.

What I think the right way to approach c14n is, is to implement a
CanonicalTextSaver class.  This class would derive from the TextSaver
and would modify how the TextSaver and the Saver produce the text to
achieve c14n output.  The base classes would have to be modified to help
here.  Specifically, dealing with namespace attributes could be tricky.

Take a look and please ask if you have questions about it.

- Eric

> -----Original Message-----
> From: Noah Campbell [mailto:noahcampbell@gmail.com]
> Sent: Thursday, July 01, 2004 7:48 AM
> To: xmlbeans-dev@xml.apache.org
> Subject: Re: xmlbeans xml security
> 
> My point exactly.  The store won't turn into a cananical
> representation of the xml schema because you'll lose infoset fidelity.
> 
> Sandboxes are fine my be.  Please post to the list when it's there.
> 
> This functionality will also have to be available through XMLObject
> since you might be required to cananocalize an arbitrary element or
> document because it could be a general purpose c14n function on an
> opaque xml document or it could be an anyType element where no hints
> from the store (or output of the saver) will be available.
> 
> Where can I find the saver interface?
> 
> Noah
> 
> On Thu, 1 Jul 2004 08:34:14 -0600, David Waite <mass@akuma.org> wrote:
> > On Jun 30, 2004, at 10:45 PM, Eric Vasilik wrote:
> >
> > > I don't think the store is the right place to deal with c14n (you
> > > mention c13n, I assume you mean c14n).  The store deals with
storing
> > > the
> > > XML Infoset.  The saver is responsible for turning the contents of
a
> > > store into a stream of characters (which can, then, be turned into
a
> > > stream of bytes via encoding).
> > >
> > > Because the store can be mutated, trying to keep it canonicalized
> > > dynamically would be a nightmare.
> >
> > Sure, but I'm wondering if the store could be optimized in how it
gives
> > that information to the saver.
> > Keep in mind that I don't know which of these already exist, or even
> > how appropriate they are; I'm still not finished reviewing
newstore2.
> > I am only proposing that if any of these are valid, they be tried
and
> > benchmarked in the sandbox.
> >
> > * putting attributes in sorted order rather than sequential order.
> > * easier determination of the 'namespace axis', although much of
this
> > could/should be done via a symbol tracker in the store. In
particular,
> > the ability to summarize namespace declarations from the root to an
> > ancestor, or between an ancestor and descendant
> > * easier determination if xml: namespaced attributes were declared
on
> > an element, same basic rules as the namespace axis.
> > * normalizing character and entity references as well as line breaks
> > (should already be done by the sax parser)
> > * access to schema for default attribute values, although I don't
know
> > if the store has his sort of access up
> >
> > -David Waite
> >
> >
> >
> > >
> > > What type information, of which you speak, is associated with
c14n?
> > >
> > > - Eric
> > >
> > > -----Original Message-----
> > > From: Noah Campbell [mailto:noahcampbell@gmail.com]
> > > Sent: Wednesday, June 30, 2004 7:37 PM
> > > To: xmlbeans-dev@xml.apache.org
> > > Subject: Re: xmlbeans xml security
> > >
> > > c13n specifies how to handle white space, attribute ordering,
> > > stripping namespaces, etc.  As far as representation of the actual
> > > byte stream is just needs to be unique, not necessarily infoset
> > > complete.
> > >
> > > The store could pre-optimize for c13n and store space tokens in
the
> > > recommended c13n spec (again I'm not familar with the store so
please
> > > correct me, I want to know how it works).  That way the type
> > > information can be extracted in c13n order and potentially speed
up
> > > the process (since it 'll be compiled on the schema compliation
> > > instead of when it processed).
> > >
> > > Again, this would optimize well defined schemas minus the anys.
The
> > > cursor would have to be able to flip into c13n mode while it's
reading
> > > the doc.
> > >
> > > Noah
> > >
> > > PS.  What's the different between the xmlstore Cursor and
newstore2
> > > Cursor?
> > >
> > > On Wed, 30 Jun 2004 16:05:59 -0700, Christopher Fry <cfry@bea.com>
> > > wrote:
> > >>
> > >> Hey Eric,
> > >>
> > >> The output of canonicalization is defined to be a set of utf-8
bytes.
> > >> See the canonicalization spec:
> > >> http://www.w3.org/TR/2001/REC-xml-c14n-20010315.  One area that
might
> > > be
> > >> tricky for the saver is roundtripping namespace prefixes.  Most
> people
> > >> actually use exclusive canonicalization:
> > >> http://www.w3.org/TR/xml-exc-c14n/ .  One thing to note is you
can
> > >> actually canonicalize a document in a streaming fashion (you only
> need
> > >> local information and a stack to implement it).
> > >>
> > >> Most people are actually using exclusive canonicalization in
XML-Sec
> > >> impls.
> > >>
> > >> Here is a section from the original canonicalization spec:
> > >>
> > >> The document is encoded in UTF-8
> > >> Line breaks normalized to #xA on input, before parsing
> > >> Attribute values are normalized, as if by a validating processor
> > >> Character and parsed entity references are replaced
> > >> CDATA sections are replaced with their character content
> > >> The XML declaration and document type declaration (DTD) are
removed
> > >> Empty elements are converted to start-end tag pairs
> > >> Whitespace outside of the document element and within start and
end
> > > tags
> > >> is normalized
> > >> All whitespace in character content is retained (excluding
characters
> > >> removed during line feed normalization)
> > >> Attribute value delimiters are set to quotation marks (double
quotes)
> > >> Special characters in attribute values and character content are
> > >> replaced by character references
> > >> Superfluous namespace declarations are removed from each element
> > >> Default attributes are added to each element
> > >> Lexicographic order is imposed on the namespace declarations and
> > >> attributes of each element
> > >>
> > >> -Chris
> > >>
> > >> -----Original Message-----
> > >> From: Eric Vasilik
> > >> Sent: Wednesday, June 30, 2004 3:59 PM
> > >> To: xmlbeans-dev@xml.apache.org
> > >> Subject: RE: xmlbeans xml security
> > >>
> > >> I need a better understanding of what canonicalization means.
But, I
> > >> would think that one should be able to take an arbitrary store
and
> > >> persist it in a canonical manner.  If the state required to
perform
> > > this
> > >> is not on the order of the size of the document being saved, then
the
> > >> saver should be able to be modified to perform this.  The
advantage
> of
> > >> this would be that the store would not be modified for the sake
of
> > >> generating a canonical form.
> > >>
> > >> If we go this direction, then I recommend creating a new saver
option
> > >> and modify the saver to obey it.
> > >>
> > >> Question, is a canonical form always a byte stream, or can a DOM
be
> in
> > >> canonical form?
> > >>
> > >> - Eric
> > >>
> > >>> -----Original Message-----
> > >>> From: David Remy
> > >>> Sent: Wednesday, June 30, 2004 3:48 PM
> > >>> To: xmlbeans-dev@xml.apache.org
> > >>> Subject: RE: xmlbeans xml security
> > >>>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: David Waite [mailto:mass@akuma.org]
> > >>>> Sent: Wednesday, June 30, 2004 12:37 PM
> > >>>> To: xmlbeans-dev@xml.apache.org
> > >>>> Subject: Re: xmlbeans xml security
> > >>>>
> > >>>>
> > >>>> On Jun 30, 2004, at 11:04 AM, David Remy wrote:
> > >>>>
> > >>>>> David (Waite),
> > >>>>> I got the chance to meet with Noah Campbell for dinner Mon
night
> > >> at
> > >>>>> JavaOne and he expressed an interest in contributing in the
are
> > > of
> > >>> xml
> > >>>>> security.  I wonder if we should start a sandbox in cvs with
a
> > >>> security
> > >>>>> directory that we could use to start experimenting on xml
> > > security
> > >>> over
> > >>>>> xmlbeans.  Unless someone has an issue with that I will go
ahead
> > >> and
> > >>> do
> > >>>>> it (specifically under xml-xmlbeans create a subdirectory
called
> > >>>>> sandbox and then a security directory under it).
> > >>>>
> > >>>> This sounds good to me, although I would suggest we try to
> > > structure
> > >>
> > >>>> the sandbox so that we can keep up-to-date with v2 as easily as
> > >>>> possible. In particular, it would be nice to branch newstore2
if
> > > we
> > >>> are
> > >>>> adding options for c14n.
> > >>>
> > >>> i was thinking we would first look at doing the work on top of
the
> > > xml
> > >>
> > >>> store and look at what requirements might come up when doing an
xml
> > >>> security implementation.  i am not positive changes would be
> > > required
> > >> in
> > >>> the store itself for c14n, after more thought it might actually
be
> > > an
> > >>> option on the saver or a different saver implementation (eric,
what
> > > do
> > >>
> > >>> you think?).
> > >>>
> > >>>>
> > >>>>> Perhaps we should get started on an XML Sig implementation
and
> > > see
> > >>> what
> > >>>>> hurdles we run into.  I *believe* at some point we are going
to
> > >> want
> > >>> an
> > >>>>> option on the xml store to keep things in the store
canonically
> > > so
> > >>> that
> > >>>>> the big c14n copy to create and validate signatures can be
> > >> avoided.
> > >>> In
> > >>>>> the meantime though we could get started and therefore define
> > > any
> > >>>>> requirements that the store might get.
> > >>>>
> > >>>> My understanding is that there is no true 'canonical form',
since
> > >>>> canonicalization is just part of the transformation chain, and
> > >>>> canonicalization (especially exclusive canonicalization) can
> > > differ
> > >>>> based on the starting reference point(s).
> > >>>
> > >>> yep, you are right, no such thing as 'load' canonicalized.
> > >>>
> > >>>> I think the approach should
> > >>>> be either to create a new store, or add options on the existing
> > >> store,
> > >>>> to make creation of the canonicalized format as efficient as
> > >> possible.
> > >>>
> > >>> agreed.
> > >>>
> > >>>>
> > >>>>>
> > >>>>> It only makes sense to have a security implementation in
> > > xmlbeans
> > >> if
> > >>> we
> > >>>>> can take advantage of the xml store to improve efficiency,
> > >> otherwise
> > >>> we
> > >>>>> should leave it to apache xml sec ...
> > >>>>
> > >>>> We probably should cannibalize as much of xmlsec as possible
> > > within
> > >>> the
> > >>>> sandbox while experimenting, then figure out how to integrate
with
> > >> it
> > >>>> as a separate project before leaving the sandbox.
> > >>>
> > >>> yep, i would think that would be the objective for the sandbox
> > > effort.
> > >>
> > >>> since v2 will have a native dom implementation i assume xmlbeans
> > > would
> > >>
> > >>> play well with xml sec pretty close to as is (is that a
reasonable
> > >>> assumption?).  if there are special optimizations we can do then
we
> > >>> would have to determine whether xml sec would want to/be able to
> > > take
> > >>> advantage of these optimizations (xml sec is patched to take
> > > advantage
> > >>
> > >>> of xmlbeans capabilities when present) or if they are unique to
> > >> xmlbeans
> > >>> (xml security becomes a feature of xmlbeans).
> > >>
> > >>
> > >>>
> > >>>>
> > >>>> -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/
> > >>
> > >>
> > >
> > > -
--------------------------------------------------------------------
> -
> > > 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/


- ---------------------------------------------------------------------
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