xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Campbell <noahcampb...@gmail.com>
Subject Re: xmlbeans xml security
Date Thu, 01 Jul 2004 07:56:14 GMT
Hi Eric,

c13n (doh!) too much JavaOne :)

I'm still trying to get my head wrapped around the store and how it
behaves.  Just by the name of it, the saver sounds appropriate.

As far as storing some cananoical information in the store, I was
thinking that if the current is arbitrary in the store, then storing
the order of the attributes and possibly the white space.

Noah

On Wed, 30 Jun 2004 21:45:28 -0700, Eric Vasilik <ericvas@bea.com> 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.
> 
> 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/


Mime
View raw message