-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ned Freed, <Ned(_dot_)Freed(_at_)innosoft(_dot_)com>, writes:
Existing facilities can be used to do detached MIME signaturues. Specifically,
one constructs a message/external-body MIME object that contains a
content-md5 field describing the external data. One then signs this
part. The result is a detached signature that also contains a pointer
to the actual data which has been signed.
Yes, this is similar to a PGP detached signature. For some applications,
it is superior since it includes a direct reference to the data being
signed. However although it is functionally similar it is not a MIME
encoding of a PGP detached signature. As I wrote earlier, PGP/MIME can
be thought of as an alternative protocol to PGP, with similar functionality
but different ways of achieving it.
If you don't want the pointer then the right answer is to define a
MIME type for a existing PGP detached signature object.
Yes, and likewise we could define MIME types for other PGP objects,
like binary signed objects.
I wonder if it wouldn't make more sense though to define a general
MIME type for a base64 encoded PGP object. This would ***NOT*** be
an alternative or replacement for PGP/MIME. That protocol is used to
protect MIME body parts, and would still be the protocol of choice for
email and similar appliations.
This proposal would simply be a transport layer for a binary PGP message.
It would be an alternative/replacement for PGP's existing ascii armor.
We'd add a couple of parameters to encode the small amount of data we
currently have in the ascii armor headers and header line.
Something like:
Content-Type: application/pgp; pgp-data-type="SIGNATURE";
pgp-version="PGP for Personal Privacy 5.0"
Content-Transfer-Encoding: base64
iQA/AwUBNIHX9cDh8jnv1nHwEQKPigCfe+AIn3e7ij8BG6UYFhCHXaIJZZ4An3Ad
bZC17Lo0/Yt/GH02/lVgDTYD
The pgp-data-type represents the data from the normal "-----BEGIN
PGP" line. It could be "SIGNATURE", "MESSAGE", "PUBLIC KEY BLOCK",
or whatever others get defined. The pgp-version has the version
info from the PGP ascii armor. We could have a pgp-comment as well.
(Including "PUBLIC KEY BLOCK" would mean that this would subsume the
application/pgp-keys content type from RFC2015.)
Then we have the base64 encoded PGP data, just like in a regular ascii
armor block, except that we don't have a checksum.
Application/pgp had been considered and rejected for PGP/MIME, because
they wanted to exploit the MIME security multiparts from RFC1847. I think
that is a good decision for that purpose. Having solved that (modulo
improvements) there still may be a role for a simple transfer encoding
to allow transport of general PGP objects. It would even be possible
to translate between the ascii armor format and this encoding, except
for the checksum. (We could think about making the checksum be an
additional optional parameter.)
This would allow MIME compliant mail readers to automatically launch
PGP on messages containing PGP objects.
Hal Finney
hal(_at_)pgp(_dot_)com
hal(_at_)rain(_dot_)org
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBNIHbUsDh8jnv1nHwEQLHlQCgkHXdb/XNy5k/Pl02LtQXn+cx2MYAoJ4z
o+aIj47UCChStXyYatvO6SvC
=AjNX
-----END PGP SIGNATURE-----