This still seems more an access-control issue than a content issue. I
don't think that it can be easily worked into the HTML model.
> >Some notion of signature sounds useful, but I don't think that this is
> >the way to do it. I'd propose the following guidelines:
> >
> > 1. If sections of a document can be signed, then *any* section
> > should be able to be signed. This implies associating a
> > signature with an ID. (This would allow RANGEs to be signed
> > as well.)
>
> Like I said I don't understand everything to do with HTML. What are IDs and
> RANGEs?
HTML 3.0 allows you to add an ID attribute to (almost) any tag. Thus
if you had a quote specified as
<bq id=nonsense> ... </bq>
then you would be able to sign just the quotation by associating a
signature with the id "nonsense". The RANGE element is a head element
which allows you to mark arbitrary ranges of the document (even if
they don't properly fit in the tree). You say
<head> <range id=r1 from=r1start until=r1end> </head>
<body> ... <spot id=r1start> ... <spot id=r1end> ... </body>
> > 2. The signature itself should probably be considered HEAD
> > information.
>
> That's a possibility but current public-key systems all place the key at
> the end of the text and I think it would be a good idea to keep it that
> way. That's why I laid out the tag the way I did.
Since the actual signature text is almost certainly something which
will not be presented to the user, it doesn't really matter where the
information goes. (If a browser needed to use an external program to
verify the signature, it would, of course, use a file in that
program's format.) By placing the signature in the head, you have the
ability to add or remove signatures without changing the document's
content and also without invalidating other signatures.
> > 3. It should be possible for a document to contain multiple
> > sections/ranges signed by different entities (to allow a
> > document by one author to include signed sections of documents
> > by others).
>
> I've never actually had the need to make multiple part files, but are
> 'entities' different areas defined by <BODY></BODY> tags?
Entities are defined by any pair of tags. If this guideline is
followed, it would be possible for a signed document to include a
quotation or excerpt signed by someone else. It would also be
possible for a document to include a petition to which multiple people
could add their verifiable signatures.
> >I don't see that any of the current head entities could be used for
> >this, so as a straw man, I'd suggest something like
> >
> > <!ELEMENT SIGNATURE - - (#PCDATA)>
> > <!ATTLIST SIGNATURE
> > for ID #REQUIRED -- section or range signed
> > form NAME #REQUIRED -- algorithm (i.e., PGP) (perhaps NOTATION?)
> > signer %URI #REQUIRED -- the identity (key) of the signer
> > %url.link; -- allows MD attribute on key.
> > >
> >
> >The SIGNER attribute would point to the public key of the signer. (It
> >might be nice to make this optionally inline.)
>
> Since the browser will have to access an external program anyways,
Why? I would certainly expect that if this became part of the
standard, that the most common signature algorithms would be built
into common browsers.
> it seems to make sense to have the public-key just one of the keys
> on the user's keychain in their encryption directory. Perhaps a
> separate WWW keychain could be created. The browsers would have to
> find interesting ways to deal with keys, such as a method for
> retreiving keys and placing thwem on your keychain.
The problem is that (unlike an email message) there is no way to know
who's public key to use for a web page. Also, this would allow you at
most one signer per document. If all you are looking for is a
verification that the document was not altered en route, then all you
need is the signature of the web server itself, and this is clearly
better done by a lower level such as S-HTTP or SSL. If you want to be
able to serve documents which include binding "agreement signatures"
like print documents, then I think that you need to be able to point
to the individual doing the signing.
----
Evan Kirshenbaum +------------------------------------
HP Laboratories |Never ascribe to malice that which
1500 Page Mill Road, Building 4A |can adequately be explained by
Palo Alto, CA 94304 |stupidity.
kirshenbaum@hpl.hp.com
(415)857-7572