RE: Irvine Minutes and ost-FTF syntax proposal

1) I believe the WG decided that objectlocation would be a URI *without*
fragment

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

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.

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.

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.

My point was directly related to the discussion of using XPointers for
solving the partial document problems, and it became the subject of much
debate the next day (not in minutes).  I believe the WG decided the debate
in my favor due to the following:  If a c14n algorithm strips out the DTD,
then it also strips out information on the attribute used for unique id
purposes.  This destroys the meaning of a URI#fragment (see #1 above).
Xpointer does not have this problem since it tests specific attributes for
values without regard for whether they are considered to be identifier
attributes in the document.

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.  However, my response is
also not recorded.  It is too easy for application security holes to emerge
by this method since we are able to add elements that would be processed by
the application but which would exclude themselves from all the signatures.
We should not be able to make such modifications to the signed document.
The 'extract' feature is preferrable because it explicitly declares what
must be extracted from a resource, and this declaration is signed.  Hence it
is possible to argue that the possible addition of elements excluded could
not possibly have affected a given application because we know the exact
characteristics of those elements.

Incidentally, this is another good argument for using XPointer instead of
URI#fragment.  In the example of my presentation (to be posted shortly), I
was able to identify that elements should only be excluded if they had A) a
certain tagname, B) a certain attribute, and C) a certain chain of
ancestors.  All of these must be true in order to construct exclusion
without creating a security hole.

7) In making my point that manifest attributes and signed attributes should
just be treated as special instances of signed object, I did not get a
chance to point out that the only reasonable suggestion for why we needed
them came from Milt Anderson (the minutes state that Milt is going to get
back to us on this).

Milt suggested that signed attributes were required so that smart cards
could record their security characteristics in the signature.  I did not get
around to this in the meeting, so I will say it now:  It seems that such
hardware should have just as easy a time adding that information as a signed
object as long as the software also added a reference to it in the signed
info.

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

Received on Thursday, 2 September 1999 16:01:09 UTC