ietf-openpgp
[Top] [All Lists]

Re: The case against redundancy and isolation

1997-11-19 16:10:46

Dave Crocker / IMC <dcrocker(_at_)imc(_dot_)org> writes:
PGP is about security.  All of the wrapping and encoding mechanisms in PGP
were developed because none were available at the time it was first
developed.  Things have changed.  There are now standards to cover these
requirements.  This means that PGP can focus on doing what it needs to do,
namely security, and it need no longer be burdened with assorted baggage
for segmenting and labeling the data or for protecting it against the
vagaries of transport.

MIME does all that.

The only remaining problem is cut and paste situations... encrypt to
clipboard, etc.  I guess you could MIME those too.

Thinking about clear text signatures (pgp -sat) does MIME have a way
to do text without putting = on the end of each line, and similarly
breaking other symbols?  (I found that most irksome, and generally
skip MIME munged articles to majordomo lists.)

Why would you want to perpetuate unique, non-standard ways of doing
something that is both already covered in existing standards which are in
real use and getting more used?

I agree.

People are focussing on backwards compatibility with ascii armor.

Backwards compatibility is already broken in the MUST section.  So
armor can be another SHOULD or MAY, or simply an appendix as
suggested.

This does not mean that vendors won't implement armor; just that they
won't _have_ to implement it.  Doesn't sound that controversial to me.
William Geiger is free to implement it.  Systemics implements it
already.  PGP will probably keep it too.

ps. I have the same line of argument against S/MIME's use of ASN.1,
and am intrigued to see whether this group is similarly
uncooperative towards true integration with Internet mail and web
standards...

Ugh, please not!  ASN.1 truly does suck.  Let's keep things away from
ASN.1.  I would have thought one of the main advantages OpenPGP has
over S/MIME is that it doesn't currently go overboard on ASN.1.  Faced
with implementing one of the two -- I know I would plump for the one
which avoids ASN.1 other things being equal. 

Any ASN.1 crapola should be in an appendix.  Include the hex for magic
strings which go inside PKE packets.

Adam