Kazu wrote:
If the discussion should be repeated, it would like to know how
situation is changed comparing one year ago.
The difference this time is that armour is unlikely to be a MUST in OP.
So it shouldn't be a MUST in a standard that OP references.
S/MIME is now coming and it does not use multipart/encrypted but
application/pkcs7-mime. So, the alignment of PGP/MIME becomes
meaningless from the implementation view of point.
This is an interesting point. RFC 1847 is elegant, but it seems that
no-one else is following it. If S/MIME isn't, I don't think there is an
absolute need for us to do so.
I may be at risk of starting a religious war even worse than the one
over armour here ;-) but I can see many ways in which it would be useful
NOT to follow that model. Particularly from the point of view of mailers
which do not explicitly understand PGP/MIME, but do understand MIME -
such as that 25 million base we keep hearing about.
We need two things from MIME: the ability to send raw PGP binary data,
and the ability to send clearsigned messages. It is also nice if, in the
manner of PGP/MIME, we have a separate content-type for keys so that, as
Peter Gutmann suggested, we can have separate key management programs if
desired.
We could keep the application/pgp-keys content-type, and use the
multipart/signed mechanism largely as-is. However, for simply wrapping
PGP data, we could have an application/pgp-data type. This would simply
be data which, once the transfer encoding had been removed by the
mailer, could be presented to an OP application which would then be able
to process it.
Then, *any* MIME-compliant mailer could be configured by its users so
that when it receives an application/pgp-data bodypart, it removes the
transfer encoding then executes a user-specified OP program with the
data as input. A message could contain any number of such bodyparts.
This obviously needs work, but I hope it's a gem of an idea. Comments?
Ian.