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.
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.)
2. The signature itself should probably be considered HEAD
information.
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 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.)
> I hope this is okay for a preliminary draft. Please let me know what the
> working group thinks.
Of course, I'm not a member of the working group, so take my comments
with a grain of salt. :-)
----
Evan Kirshenbaum +------------------------------------
HP Laboratories |Ye knowe ek, that in forme of speche
1500 Page Mill Road, Building 4A | is chaunge
Palo Alto, CA 94304 |Withinne a thousand yer, and wordes
| tho
kirshenbaum@hpl.hp.com |That hadden prys now wonder nyce and
(415)857-7572 | straunge
|Us thenketh hem, and yet they spake
| hem so
| Chaucer