Re: embedding public-key cryptography into HTML

Philip Trauring (
Thu, 6 Apr 95 20:45:42 EDT

>I'm not sure that I understand how you could fit CRYPT into SGML since
>the content would have to be decrypted (via some externally provided
>key?) before it could be checked for conformance.

The same way you would need an external program to check the signature you
could use it to decrypt full or partial pages. This perhaps is not as
useful as signatures butwhen adding signatures it seems to make sense to
add in encrytpion which could have uses in groups that need wide-area
distribution to limited groups.

>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

> 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.

> 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?

>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
> 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
>; -- 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, 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

BTW, could someone point me to a site that explains all the !ELEMENT and
!ATTLIST type stuff. Thanks.


Philip Trauring
Brandeis University MB1001
P.O. Box 9110 "knowledge is my addiction,
Waltham, Ma 02254-9110 information is my drug."
(617) 736-5282 ['94/95]

WWW home page: