Mailing-List: contact xmlbeans-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: xmlbeans-dev@xml.apache.org
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <4B2B4C417991364996F035E1EE39E2E10D8EF3@uskiex01.amer.bea.com>
References: <4B2B4C417991364996F035E1EE39E2E10D8EF3@uskiex01.amer.bea.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B9954DC1-CB6B-11D8-B0F7-000A95C89D86@akuma.org>
Content-Transfer-Encoding: 7bit
From: David Waite <mass@akuma.org>
Subject: Re: xmlbeans xml security
Date: Thu, 1 Jul 2004 08:34:14 -0600
To: xmlbeans-dev@xml.apache.org

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/