ietf-openpgp
[Top] [All Lists]

Handling 8-bit cleartext signatures - a proposal (Was: Re: OP an

1997-12-06 13:08:59
-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 04 Dec 1997 10:57:28 -0800 Jon Callas <jon(_at_)pgp(_dot_)com> wrote:

At 09:22 PM 12/4/97 +0400, Maksim Otstavnov wrote:

Besides, it has nothing to do with PGP/MIME. PGP/MIME is a separate
question currentely not discussed by this WG according to its
agenda. (right?).

No, PGP/MIME (a.k.a. OP-MIME, or RFC 2015) is covered by this
working group.
   
The OP is to obsolete rfc1991, not 2015, right? Ascii-armor is
currently defined in 1991, not 2015. So I just wish OP rfc to 
contain 
both a concept of "8-bit text" and definition of actions order for
plugins/glues producing _non-PGP/MIME_ messages. Just so little ;)

This working group has two things under its charter (presently) --
the
OP-FORMAT document and RFC 2015. So each are relevant, we just have
two
documents.

...But a new PGP(OP?)/MIME is not scheduled yet... Handling clearsigs
_does_ belong to OP draft domain currently and all ambiguities imho
should be fixed before it starts on its standard track.

I apologize if a subject of my previous postings was ambiguos. The
exact problem I face is that pgp 5.0i users in Russian environment
suffer a set of complications derived (I believe) from the fact that
8-bit text clearsigning is performed differently in different cases.

For example, I apply a procedure (recommended by PGP 5.0 manual) for
clearsingning msg to be sent with an _unsupported_ MUA (eg MS Internet
Mail). The MUA operates in a Windows native codepage (so called
"Windows-cp1251") and PGP produces a clearsign of this codepage
rendering of the plaintext. Then I send a message. Before sending, the
message (mime, 8-bit, plaintext) is usually converted to
cross-platform standard, KOI8-R (RFC 1489, officially registered with
RFC 1700, also registered by the POSIX WG15 character set collection,
the latest Registered Charsets List from IANA and by IBM  as CP878)
either as 8-bit or printed-quotable. 

If a receiving MUA isn't Win-based, the message normally never 
returns to the native Win cp, so signature can't be verified.

Furthermore, a _supported_ plugin developer currently not bound 
(nor even advised) by any document to a particular _order_ of 
performing both conversion and PGP-clearsigning a single message. So,
it may happen that a message clearsigned with one plugin won't be
verified by an other one, even on _the same_ platform.

(I don't know for sure how current 5.0 MUA plugins (I am aware of the
four - Eudora, MS Exchange/Outlook, Mail'97, and QDPGP 1.60 for
Pegasus for 32-bit Windows) handle the two operations of a single
message).

In recent days I've been trying to figure how OP would fix the 
problem. The following proposals are the result (I browsed through the
entire archive of the OP list and found no proposals which would
contradict these; pls advise me if I'm wrong). I am not overall happy
with them, for clipboard clearsigning remains a problem, but it would
at least make all OP-compliant applications ("supported MUAs")
intercompatible over 8-bit clearsigned texts.

Suggestions? Comments?


- -----cut here-----
2.6 Cleartext signature framework

Sometimes it is necessary to sign a textual octet stream 
Proposal:
, consisting either of 7-bit or 8-bit textual octets, 
without ASCII
armoring the stream itself, so the signed text is still readable
without special software.  In order to bind a signature to such a
cleartext, this framework is used. (Note that RFC 2015 defines
another way to clear sign messages for environments that support
MIME.)

Proposal:

2.7 Handling 8-bit cleartext signatures

Sometimes it is desirable to perform cleartext signature over a 8-bit
textual octet stream. In certain environments performing of other, not
defined in this document, conversion ("Non-OP conversion") of a 8-bit
textual octet stream is also required (e.g. for handling non-English
messages in a cross-platform environment).

If an OP application allows handling 8-bit textual octet stream it
MUST apply cleartext signature and perform a non-OP conversion of a
single 8-bit textual octet stream in the following way.

2.7.1 Producing 8-bit cleartext signature

- - perform non-OP conversion of the original textual octet stream 
  (producing either 8-bit or 7-bit output) required by a specific
  environment; then

- - apply cleartext signature framework (defined in 2.6 of this
document) 
  over the product of such conversion.

The product of the two consequential procedures described 
hereabove is either 8-bit or 7-bit textual octet stream,
depending on specific environment requirements.

An OP application SHOULD mark an outgoing message produced in 
a way defined hereabove with either the following headers:

%  MIME-Version: <x.x>
%  Content-Type: text/plain; charset=<y>
%  Content-Transfer-Encoding: <z>bit

or the following headers:

%  MIME-Version: <x.x>
%  Content-Type: text/printed-quotable; charset=<y>
%  Content-Transfer-Encoding: 7bit

where 
- - <x.x> is a version of MIME supported by the OP application;
- - <y> is a registered charset corresponding with the semantics of
the 
  output of the non-OP conversion applied; 
- - <z> is either "8" or "7" depending on the octet width of non-OP 
  conversion.

2.7.2 Verifying 8-bit cleartext signature

- - verify cleartext signature; then

- - perform non-OP conversion of the message in accordance with
  its "MIME-Version", "Content-Type", and "Content-Transfer-Encoding"
  headers values.
- -----cat there-----

-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5

iQCVAwUBNImG1XGCEHWOiJDhAQGlPAP/b7sSbSgVS27cQzpZ7D4OJ+voYWil64Hi
iSdrMqYrLdDj1si8i0VGsCOR0YX09KA4tbmV4lDzDYuqeoJB6kRrlL47cCwT2Oyv
pVOAy3xX1yNtk95Gbp8FUkYEIfSMFZhgq2LZhkThjgKO/UuHffyVD8ujQTRZCZWy
wATyQDWu4WE=
=oO86
-----END PGP SIGNATURE-----
--
-- Maksim Otstavnov <maksim(_at_)volga(_dot_)net> 
http://www.geocities.com/SoHo/Studios/1059/
--   -maintainer of The Russian PGP HomePage
--     (http://www.geocities.com/SoHo/Studios/1059/pgp-ru.html)
--   -moderator of "Security&Privacy" (Russian language) Web-forum
--     (http://www.rocit.ru/forum)