I'd suggest that clearsigning is aimed more at applications which will
present the signed document to users as it was received "on the wire",
so that they can read it usefully even with the signature in place.
For that purpose the important thing is to know exactly how the signature
will be verified so that signers can create valid documents. I think
we agree that the spec is adequate for this purpose.
For data interchange, you want to start with a document on one machine
and sign or encrypt it, send it to another machine and verify/decrypt,
getting back the same document. For that purpose the binary formats
work well.
The problem arises if you want to clearsign but still get data
interchange. The sender needs to know not only how the data will get
verified, but also how it will be stored if the signature is stripped
away. We didn't spec this because it didn't seem to fit that well into
the clearsign model, which is oriented around presenting data with the
signatures in place.
So what are the rules for storing a clearsigned message, with signature
stripped away? Would we just want to store the byte stream that
was hashed (the portion of it that was from the message and not the
signature bytes)? Or would we want to switch to native line terminators
when we store? Would we strip or keep trailing whitespace when we store?
If we did spec this, it would then by implication tell a sender how
to at least approximate data interchange. Problems might arise if line
terminators are getting changed. And if we strip trailing whitespace when
we store, then it would be impossible to send a document with trailing
whitespace and have it be received that way. OTOH the reason we strip
trailing whitespace for verification is because some mail systems corrupt
that part, so retaining trailing whitespace on store will not guarantee
data interchange either.
In short, clearsigning is not really appropriate for data interchange
because of how many ways the message could be corrupted in transit.
But if we do spec it, I would definitely NOT then put in the spec that
a sender was FORCED to offer a data interchange option! That is far,
far outside anything we should be imposing on an implementation, in a
data format spec.
Hal Finney