Re: "Yes, I can handle PGP/MIME"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the absence of a definitive non-advisory flag, we solved this 
problem over a year ago, and the solution is now deployed in many 
versions of shipping products. Since PGP products never (before PGP 
Universal) generated the preferred keyserver attribute on keys, we 
consider PGP/MIME to be a preferred encoding format if the recipient 
key has this flag. If the flag does not appear, we use Legacy encoding 
(to be distinguished from the simplistic "inline" encoding concept as 
real scenarios such as sending HTML, RTF, encoded multiparts, and 
attachments properly in a method compatible with legacy products 
requires far more work when not using PGP/MIME than simply encrypting a 
block of "inline" plaintext).
Given that most PGP products before PGP Universal did not support 
PGP/MIME, and the only extant keys with said flag were some GPG keys, 
and most GPG front ends both require and only support PGP/MIME, it was 
a logical choice which has worked out well.
Thus, we would have no use for such a flag (if you had posted your 
message two years ago, that would be a different answer). I don't 
anticipate any major email scenarios in the future which will not 
support at least the decoding of PGP/MIME. PGP products either do now 
or will use this flag in the way indicated above. Since most GPG front 
ends already require PGP/MIME and often set this flag on keys, the 
waters are already moving in the proper direction.
Email formats are becoming ever more complex. PGP/MIME is the only 
standard solution on the table. Legacy encoding methods can be created 
to encapsulate MIME in a non-PGP/MIME way for maximum backwards 
compatibility as we have done with PGP Universal, but the complexity of 
creating an actual standard around such methods far exceeds the 
complexity of filling in the last few pieces in the transition to 
PGP/MIME.
The illusion here is that there is an alternative to PGP/MIME. That 
illusion is rapidly dispelled after careful analysis of all the kinds 
of email from every mailer and every mail system are thrown into the 
pot and we try to figure out how to encode them all without PGP/MIME. 
It is relatively hopeless to have 100% accuracy like PGP/MIME. Should 
legacy formats still be used in some cases and possibly even for 
decades to come?  Quite likely. There are some simple text/plain 
scenarios where using PGP/MIME just isn't worth the possibility of a 
compatibility issue. The reality is that the vast majority of email no 
longer falls into that category.
While this was a bit of a hack, the facts on keys in the field match 
the usage of the attribute and all signs point to that continuing. I 
believe over the next two years we will find that the remaining 
deployed population unable to decode PGP/MIME will have dwindled to 
insignificant levels. Meanwhile, anything we discussed here right now 
would not have any measurable deployment until likely 2005. Thus, I 
would suggest that if you find yourself needing such a flag, adopting 
the same method would be the most advisable and simplest solution which 
has the advantage of already being deployed.

On Apr 15, 2004, at 8:46 AM, David Shaw wrote:
> Given all that, would there be some benefit in a standard way for a
> user to advertise that he can handle PGP/MIME?  Specifically, a
> "features" subpacket bit to say "I can handle PGP/MIME".

- --
Will Price, VP Engineering
PGP Corporation


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal Satellite 1.2.0 (Build 182)

iQA/AwUBQH+mcqy7FkvPc+xMEQLnVgCg2UA1tg9NpTg4BJYsBWaDGr4N3QYAn3FG
f7PCObydphKV/ieWNSzAoq2O
=XNK6
-----END PGP SIGNATURE-----