RE: Irvine Minutes and ost-FTF syntax proposal

Hi Joseph,

No problems. Replies inside.

============================================================================
====
At 12:59 99/09/02 -0700, John Boyer wrote:
 >1) I believe the WG decided that objectlocation would be a URI *without*
 >fragment

It states that in one point, perhaps you are referring to something earlier?
(People should feel free to annotate the notes so I know excactly which text
they are referring to.)

<John>
I cannot find where it states this.  The word 'fragment' does not come up on
word search, # only appears in the ref list, and the only instance of URI
that says anything about partial document says that moving the problems to
XPtr means that we can move the exclusion notion from core syntax.

Perhaps I misunderstood what that meant.  Did you just mean that we could
punt the problem of having to make up a syntax for exclusion?  Please
clarify.
</John>

_
Consensus. The reference from SignedInfo will just be a URI. This can then
  point to a manifest or package which can use Xlink/Xptr/Xpath as
appropriate.     This means you don't have to worry about Xptr in the core
signature syntax.

<John>
Actually, this wasn't my interpretation of what was said at the FTF nor is
it reflected in the post-FTF Solo syntax.  The signedinfo contains a
signedobjectreference, which includes a transformations element, which
includes the exclusion functionality (which we are proposing would use some
form of Xptr).  Also, this is why I've been under the impression that this
would be part of core syntax.
</John>
_

I added "without fragID" to be clear. However, I think we need it to be a
URI or fragmentID (to a packaged chunk of XML in the same document.) Right?

<John>
I think that we need some way of indicating partial documents so we can
indicate, for example, the packaged chunk of XML in the same document, but
we seemed to get into muddy waters when we allowed fragmentID to be part of
the URI rather than using the Xptr transform (which can do inclusion as well
as exclusion logic).

So, we can leave it without fragID because (and as long as) the
transformations stay a part of signedobjectreference.

As a quick reminder, if you go back to fragID, here are some problems to be
faced
1) every signed XML app will have to be a validating XML app since the DTD
must be processed to figure out the ID.
2) if you c14n the signed content and the DTD disappears, then since you
lose information about which element is the ID, every once in a while a
nasty security hole will open if a non-id attribute contains the same value
as the ID attribute.
3) A fragId indicates an element based on the value of an attribute whose
name is defined in the DTD.  By comparison, an XPtr can identify the element
based on the value of an attribute whose name appears in the signed XPtr;
further, the element can be more specifically identified as being the one
having a particular attribute with a particular value, plus a particular tag
name, plus a particular ancestry, etc.  Which is more secure?
4) Asymmetry between direct signature and indirect signature via manifest.
A manifest method would have powerful means of filtering the XML, but
requires the app to validate the document itself.  The direct signing method
validates the actual object being signed, but if you removed XPtr, it would
not have very powerful means of filtering.

As the Solo syntax proposal stands now, there is symmetry, harmony, ebony
and ivory <smile/>
</John>

 >2) I believe the WG decided that the 'exclusion' element would be changed
to
 >something like 'extract'.

I honestly don't recall. I'll note that in the notes as reference as we
tweak names of our elements as we move forward.

<John>
It was a quick name change Don made on the whiteboard in response to the
suggestion that Xptr could do inclusive logic as well as exclusive (so the
element name exclusion was inaccurate).
</John>

 >3) I believe the WG decided that XPointer or some subset of it would
 >comprise the content of 'extract' (as long as it does not change radically
 >in the future).  If this is true, then its DTD entry should be changed
from
 >ANY to PCDATA.

Why do we need an "extract" element anway? If we are using XPtr, it would
just be part of the manifest reference, no?

<John>
Actually, that's a great question!  I was all in favor of this approach
myself until Milt Anderson burst our bubble (and rightly so!) by pointing
out that it may be necessary to do transforms such as base64 decoding before
we apply the Xptr.  Kudos Milt!
</John>

 >4) I do not believe that the WG decided to punt the notion of exclusion
from
 >the core syntax as suggested by the minutes, nor do I believe any decision
 >has been made as to what if anything should be made optional.

Since the core syntax only uses a URI, any other references would be part of
the manifest/package and should be defined there, right?

<John>
No.  Answered above.  The core syntax includes signedobjectreference, which
for many reasons including symmetry puts the Xptr material into the core
syntax.  This is part of why I think we should go over XPath in detail to
see if there is some way to reduce the complexity.
</John>

 >5) There is a point in the minutes which says "Boyer raises unrelated
point
 >that if the canonicalizer strips out the DTDs, you won't know which
 >attributes are IDs anymore."  I do not tend to bring up 'unrelated'
points,
 >so I hope we can refrain from terms like this going forward.

Its orthogonal to the point directly above though its highlighted because
its a good point we need to investigate. I hope people are willing to give
me the benefit of the doubt and assume incompetence instead of malice in
meeting minutes that haven't yet been reviewed by anyone. <smile>

<John>
Hopefully it should now be evident that it was not unrelated because of the
issues I raised about the relative security of fragment IDs compared to
Xptrs.  Also, I didn't assume malice, so I hope you're not offended; I just
preferred a more neutral wording so that it would not be taken the wrong
way.  Finally, I really didn't know who wrote which specific sections of the
minutes, and since I didn't (nor am I any good at it), any comments I've
made about minutes wording should be taken with a grain of sugar.
</John>

 >6) The minutes show a suggestion by Peter Norman to put a dsig:exclude
 >attribute in those objects that should be excluded from a signature.  The
 >group countered that this would not work for multiple signatures.  It is
not
 >in the minutes, but Joseph reiterated this point the next day because it
 >seems clear that multiple exclude attributes could be used to declare
which
 >signatures the element should be excluded from.

Again, I'm not sure what text you are referring to, but it does say:

Norman: can we do this in a simpler way, with a dsig:exclude attribute?
Which 	requirements does Xptr meet that can not be met through an easier
method? 	Group: The insertion of dsig:exclude is problematic when you have
multiple 	signatures, how does which signature know which dsig:exclude
belongs to it.

I added

        Boyer also asserts this adds security problems in that it requires
modifications
        to the signed document. (see Boyer 1990902 for more.)

<John>
Actually, the biggest problem is not that it requires but rather that it
allows modifications.  One can add new elements with impunity by putting an
attribute that allows them to be dropped from all signatures.  This really
gums up the works for document processing because it implies more work to
determine whether the parts necessary for each stage of a system have really
been signed by the appropriate people.  They are there, and all signatures
validate, but did the important pieces really get signed and are there
unsigned claims being made in those documents that might confuse application
logic?  This would be the source of more than a few new stories about
application security holes.  Furthermore, those who make application
development environments would be able to do very little about this other
than incur greater costs in educating their user/developers about things
they can do but shouldn't.  This is really just another manifestation of the
document closure issue.

Peter Norman's actual suggestion was actually more sophisticated.  He
proposed having a special element to mark regions to be signed by each
signature.  The marker elements would be dropped out of the signature, but
they bracket the regions that should be signed.  However, since this is a
positive (inclusive) method, rather than an exclusive one, it still loses
the document closure battle. (In partial answer to the question of what do
the Xptrs do that the proposed idea doesn't do).

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

</John>
_________________________________________________________
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Tuesday, 7 September 1999 15:08:33 UTC