W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

Processing Instructions Section / One pass processing

From: <dee3@us.ibm.com>
Date: Fri, 17 Dec 1999 15:28:13 -0500
To: w3c-ietf-xmldsig@w3.org
Message-ID: <8525684A.0070A3E0.00@D51MTA05.pok.ibm.com>
There is currently a dummy section 4.3 in the draft on processing
instructions.  I suggest it be changed to

"4.3 Processing Instructions

No use is made by this specification of XML Processing Instructions.  Note
that Processing Instructions inside SignedInfo will be signed unless a
customized CanonicalizationMethod is used that discards them. They are
retain after any CanonicalizationMethod (including none) specified herein
has been applied.  The same is true of Processing Intructions appearing in
any other signed XML unless a canonicalization or Transform is used which
drops them out.  When signed, changes to Processing
Instructions inside SignedInfo will cause signature failure."

Originally, I had thought that one pass processing info would be best
represetend by a processing instruction. However, the content of a PI is
just a string and is not parsed as XML, so to put the
information you want inside one might require an extra explicit call to
your XML parsr.  Using a PI might still be an advantage if
we had a standard canonicalization that was like the W3C XML
canonicalization but which dropped PIs.  In addition, PIs can be
inserted into valid documents without having explicity DTD provision...

In any case, below is the simple element form of my current ideas in this
area with the Processing Instruction changes indicated by deleting materila
in curly braces {} and adding material in square braces [].

"{4.5 One Pass Processing} [4.3.1 One Pass Processing Instruction]

For some applications it would be useful to be able to stream through data
in a single pass remembering only relatively small amounts of extracted or
calculated information.  If this data is to be digested, the digest
processing must be known in advance so that it can be performed as the data
streams by.  Otherwise, it would be necessary to store all of the data and
go back if/when it is determined that all or part of it needs digesting.

The syntax for the OnePass {element}[Processing Instruction] is shown
below.
It hints that the signature application should, starting right after the
end
of the OnePass {element}[Processing Instruction], apply theindicated
DigestMethod to the XML data following.  If Transforms are present, the
data
must be first modified according to those
Transforms before digesting.  If an area of XML needs to be digested in
several ways for different signatures, this is indicated by including
multiple Processing elements.  OnePass disgesting stops just before an
empty OnePass {element}[Processing Instruction].

{<OnePass>}[<?OnePass]
   <Processing>
      (DigestMethod)
      (Transforms)?
   </Processing>*
{</OnePass>}[?>]

[Note that no DTD or Schema provisions need be made for Processing
Instructions even if a validatig parser is used; however, an explicit
XML parser call on the content of the Processing Instruction may be
needed to implement OnePass.]{Note that DTD and/or Schema provision
for OnePass elements will be needed if a validating parser is even
going to be used.}

The one pass feature is a purely optional to use and
optional to implement hint.  It can be ignore by applications, can indicate
the wrong DigestMethod, or the like, without causing any formal error or
error reporting to the user.  Of course, under those circumstances, an
application that needs to do one pass processing to avoid having to retain
bulky data will be unable to verify a signtature which requires that data
to be digested the way that application wanted.

OnePass can be partially implemented.  For example, a simple OnePass
implementation might ingore OnePass {elements}[Processing Instructions]
that have a Transforms element present or the like.

No provision is made for one pass processing of data which includes
OnePass {elements}[Processing Instructions] that are to be considered
data rather than one pass feature invocations."


Thanks,
Donald

Donald E. Eastlake, 3rd
IBM, 17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668
Received on Friday, 17 December 1999 15:30:42 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT