Re: signature/encryption tags -> follow-up

Craig Hubley (craig@passport.ca)
Tue, 11 Apr 95 01:25:00 EDT

> >On Mon, 10 Apr 1995, Philip Trauring wrote:
> >> Integrating a signature tag is the only way to provide real document-level
> >> security in WWW documents.
> >...
>
> What I meant was that within the framework of HTML it is the only way to do
> it. Implemnting this functionality outside of HTML proper is possible, but
> it is more complicated for the user and harder for the document author to
> create signed documents.

Yes but as previous posters have noted there will be other signature tools
and technologies. A <SIGN> tag with an attribute identifying the type of
signature it is, is not necessarily the worst way to deal with this but 'not
necessarily the worst' does not add up to 'worth adding to the standard for'
if there are other ways to do it. Of course it is 'more complicated and
harder' but that is the problem of authoring software and signature software
not the HTML committee. Convenience of the software developer is not the
major factor... it is convenience of the user, and to some degree the software
administrator and integrator (especially in early acceptance) that decides
what standards are adopted. Those who need signatures will add signatures.

There are three notes I would like to add to this debate:

0. (more of an assumption) HTML must remain SGML-compatible and should thus
adhere not only to its syntax but also to its precedents, prior design
decisions, and general character wherever possible. The advantage of
compatibility with all prior work on SGML-compliant markup languages in
terms of tool support, standards support, and pre-existing consensus is
considered to outweigh any specific advantage that could ever be gained
in allowing HTML extensions to be standardized that break SGML compliance
(note that this applies both to 'signature tags' and to 'character sets').

1. SGML/HTML is an in-bandwidth tagging format, that is, it puts its tags in
the same stream of symbols as the content. An analogy is the way that
analog telephone service (POTS) puts touch or pulse tones into the same
stream as your voice. Modern digital services (e.g. ISDN) carry signals
on a separate channel to prevent forgeries etc. and are thus 'out of
bandwidth'. Similarly, SGML/HTML additions to support MIME types etc.
are 'out of bandwidth' because they specify names of external resources
and expect them to be integrated into a neat presentation by a browser
(whereas an in-bandwidth solution would have, say, put the resource into
the stream in UUencoded format, the way GIF files and PGP signatures are
embedded in e-mail - however this solution was not adopted in SGML/HTML)
Although 'out of bandwidth' solutions are generally harder to implement
because they require integrating multiple programs looking at multiple
streams and some means of specifying how they fit together, they work
very well. SGML has hitherto used out-of-bandwidth methods for anything
in binary form, HTML has followed this tradition so far (e.g. MIME types)
and I see nothing about a signature that requires any other approach:

2. A signature can be considered similar to any other MIME type in that it
is information that is
- not directly human readable (i.e. must be generated/read by a program)
- potentially quite large (i.e. with a large key it could be 100s of bytes,
and generally will expand as key sizes expand to potentially several K)
- not of interest to all readers (i.e. as graphics are often 'turned off'
by many readers, authentication/signatures are often of interest only
to those who intend to act directly on the information in some binding
way
- not directly useful in processing other information on/in the page
Furthermore, a signature requires conciousness of the other MIME-based
contents of the page anyway, otherwise there is no guarantee that I did
not replace your harmless clickable map of New Jersey with one of Senator
Exon in his underwear... the signature must somehow verify that contents
of referents (URLs, GIFs, etc.) at least have the same names as when the
file was written... more robustly it could guarantee checksums on the first
level referents down the tree... but in any case the signature software
MUST ALREADY BE CAPABLE of parsing tags for these... asking it to *generate*
one does not seem like too much trouble, given that.

3. That said, the reasons that PGP signatures and UUencoded attachments and
SMTP/NNTP headers of the form "Reply-to: craig@passport.ca" have caught
on have much to do with the fact that they are in-bandwidth and stick with
the file no matter what, regardless of where it moves. Today's antiquated
file systems impose very major overhead on multiple-file implementations
of a given data structure. Perhaps there needs to be a way, in SGML/HTML,
to include the entire content of what would otherwise be a small MIME file,
such as a PGP signature or UUencoded addition, in-bandwidth to the content.

My most profound apologies if this already exists.

Comments invited on the above, as always. I don't have a specific solution
to the signature tag debate but I think that if you want to include *any*
non-human-readable information in a document conforming to *any* SGML-
compliant markup language, including HTML, the SGML Gods intend that that
be done out-of-bandwidth. If this is not humanly possible, as I might grant
that the signature situation may warrant, any means of including non-human-
readable information in a document requires not just a new tag type but the
proposal of a way to handle such 'embedded MIME' types in SGML in general.

Any proposals to solve this latter problem will also provide a solution to
the 'in-bandwidth-signature' problem while making SGML-compliant equivalents
to SMTP, NNTP, UUencoded attachments relatively easy to define & standardize.

I for one would find this very handy, I'd love to SGML-ize my archives
of saved news and mail, and never-decoded UU-files, and generate an HTML
web of the results. Existing file formats that rely on in-bandwidth-encoded
non-human-readable information, which are legion, would benefit from a fairly
mechanical methodology for translating such formats into SGML DTDs, as well.
This latter benefit is potentially huge, as we have learned working with our
clients who have huge investments in non-SGML-compliant formats. Comments
on this issue are invited by e-mail.

Sorry if the issue of 'finding-general-SGML-solutions-to-problems-that-first-
rear-up-their-ugly-heads-in-the-context-of-HTML-but-have-major-benefits-for-
general-solution' has been done to death. Just had to say it again.
--
Craig Hubley Business that runs on knowledge
Craig Hubley & Associates needs software that runs on the net
craig@passport.ca 416-778-6136 416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5