Internet-Draft Kazu Yamamoto
NAIST
Expires in six months May, 1997
Multi-signature Extensions for PGP/MIME
<draft-kazu-pgpmime-multisig-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
PGP/MIME provides single signature service of PGP in the context of
MIME, however, multiple signature service is desired for usability
and flexibility. For this purpose, this memo defines
"Multipart/PGP-Signature" used as the "protocol" parameter and the
content type of the second part of "Multipart/Signed".
Canonical MIME format used in PGP/MIME is reasonable but it is not
enough for some kinds of MIME objects, particularly for ISO 2022
text. Thus, this memo extends the "micalg" parameter syntax as
"pgp-<hash-symbol>+<canform-symbol>" so that <canform-symbol> can
specify more specific canonicalization for signature calculation.
Introduction
"Multipart/Signed" defined in [SecMulti] provides a good framework
to implement signature service in the context of MIME[MIME]. The
first part of "Multipart/Signed" contains a MIME object to be
protected by signature(s) and the second embeds the
signature(s). Some protocols such as MOSS[MOSS] and S/MIME[S/MIME]
define their signature service on "Multipart/Signed".
PGP/MIME[PGP/MIME] also makes use of "Multipart/Signed" for PGP[PGP]
signature service with detached signature.
"Multipart/Signed" itself does not define the format of the second
part but allows each protocol to do so. PGP/MIME specifies that the
Yamamoto [Page 1]
Internet-Draft Multi-signature for PGP/MIME May 1997
second part contains exactly one signature indicated by the "micalg"
parameter where "pgp-md5" and "pgp-sha1" are reserved so far. The
PGP program has used MD5[MD5] as the default hash function. So, it
is reasonable for PGP/MIME to define that the second part contains
one PGP signature identified by "pgp-md5".
Resent cryptanalysis shows, however, that the strength of MD5 is
suspicious. So, some users want to use another hash function such as
SHA1[SHA1] which is believed strong enough. To maintain backward
compatibilities, it is desired to deliver both the de-fact standard
signature and new strong ones at the same time. This memo thus
discusses how to embed multiple PGP signatures in the context of
"Multipart/Signed".
PGP/MIME defines canonical format for signature as 7bit-encoded MIME
format. However, for some kinds of MIME objects more specific
canonicalization is necessary. This memo also discusses how to
support such specific canonicalization.
The Multipart/PGP-Signature Content Type.
"Multipart/Signed" objects which conforms this memo MUST have the
"protocol" parameter whose value is "Multipart/PGP-Signature". The
content type of their second part MUST be "Multipart/PGP-Signature".
The content type of each part in "Multipart/PGP-Signature" MUST be
"Application/PGP-Signature".
The value of the "micalg" parameter of "Multipart/Signed" MUST be a
comma separated list of tokens. Each token specifies signature type
of regarding part of "Multipart/PGP-Signature". The number of the
tokens MUST be greater than or equal to 2. The number of parts in
"Multipart/PGP-Signature" MUST be equal to that of the tokens. Each
"Application/PGP-Signature" part MUST have the "micalg" parameter
whose value is the same as the regarding token.
For instance, if the "micalg" parameter is '"pgp-md5","pgp-sha1"',
the first part of "Multipart/PGP-Signature" contains a PGP signature
with MD5. Its "micalg" parameter is "pgp-md5". And the second embeds
a PGP signature with SHA1 whose "micalg" parameter is "pgp-sha1".
The following shows the entire format of the example.
Content-Type: Multipart/Signed; boundary="rfc1847";
protocol="Multipart/PGP-Signature";
micalg="pgp-md5","pgp-sha1"
--rfc1847
Content-Type: text/plain; charset=us-ascii
This is a text message to be signed.
--rfc1847
Yamamoto [Page 2]
Internet-Draft Multi-signature for PGP/MIME May 1997
Content-Type: Multipart/PGP-Signature; boundary="thismemo"
--thismemo
Content-Type: Application/PGP-Signature; micalg="pgp-md5"
SIGNATURE WITH PGP/MD5
--thismemo
Content-Type: Application/PGP-Signature; micalg="pgp-sha1"
SIGNATURE WITH PGP/SHA1
--thismemo--
--rfc1847--
The Canonicalization Format Extension
Section 2.1 of RFC1487 defines three steps to create a
"Multipart/Signed" part.
(1) An object to be signed is transformed into a MIME canonical
form. It has an appropriate set of MIME headers. It is
constrained to be in 7 bits if it is ever to be transferred
via SMTP. All line delimiters must be <CR><LF>.
(2) The MIME canonical form is converted according to the value
of the "protocol" parameter.
(3) A "Multipart/Signed" part is created over the prepared
object.
Section 5 of RFC2015 does not specify any PGP/MIME specific
transform for step (2) above.
For some objects to be signed, typically ISO 2022 family text, more
specific canonicalization than defined in step (1) is necessary. To
support this kind of specific canonicalization, the
"pgp-<hash-symbol>" syntax of the "micalg" parameter token is
extended as follows:
"pgp-<hash-symbol>+<canform-symbol>"
Here "<canform-symbol>" indicates type of the specific
canonicalization which may be defined in other RFCs. An example is
found in [JMSG]. For this extension, plus ("+") symbol MUST NOT be
used in "<hash-symbol>" nor "<canform-symbol>". This extension is
allowed only if the "micalg" parameter is a comma separated list of
tokens(i.e only if the value of the "protocol" parameter is
"Multipart/PGP-Signature.).
The canonicalization indicated by "<canform-symbol>" MUST be carried
out as step (3.5) in Section 5 of RFC2015.
Yamamoto [Page 3]
Internet-Draft Multi-signature for PGP/MIME May 1997
Verification and Error Handling
Each verification typically results in the followings:
- Succeeded
Hash value calculated over the first part of
"Multipart/Signed" matched one in the signature.
- Failure
Hash value calculated over the first part of
"Multipart/Signed" did not match one in the signature.
- Unknown
Did not verify since the value of the "micalg" is
unknown.
User agents which conforms this memo MUST tell users results of
every signature verifications upon request.
User agents MUST stop verification process if one or more of the
following errors occur:
- The number of parts in "Multipart/PGP-Signature" is not the
same as that of tokens specified for the "micalg" parameter
of "Multipart/Signed".
- The content type of parts in "Multipart/PGP-Signature" is not
"Application/PGP-Signature".
- The content type "Application/PGP-Signature" does not have
the "micalg" parameter.
- The "micalg" parameter of "Application/PGP-Signature" is
different from the regarding token.
- The value of the "micalg" parameter of "Multipart/Signed"
ends with comma.
User agents MUST tells users failure of the verification process and
MUST tell users, upon request, why the verification process stopped.
IMPLEMENTATION NOTE
The PGP signature format specified in [PGP] is categorized into
"binary image" and "canonical text". If the "-t" option is
specified and the PGP program guesses the object to be signed is
text, the PGP program itself converts line delimiters of the
object into <CR><LF>. Then it calculates a signature over the
converted object and specifies "canonical text" mark on the
signature. Otherwise, the PGP program calculates a signature
over the original object then specifies "binary image" mark on
the signature.
On verification, if the signature tells "canonical text", the
PGP program first converts line delimiters of the target object
into <CR><LF> then verifies. Otherwise verification is carried
out over the original object.
RFC2015 does not limit type of PGP signatures, so both "binary
Yamamoto [Page 4]
Internet-Draft Multi-signature for PGP/MIME May 1997
image" and "canonical text" are valid.
If a user agent itself converts line delimiters of an object to
be signed into <CR><LF> then calls the PGP program without the
"-t" option, the signature is produced as "binary image" even if
the object is a line-based text object. Please not that this
signature is valid in the context of PGP/MIME and signature
verification should success. If another user agent,
particularly on UNIX whose line delimiter is <LF>, calls the PGP
program without line delimiter conversion, the verification
fails because the PGP program never converts line delimiters.
So, to verify PGP signature, user agents MUST convert line
delimiters of the first part to <CR><LF> by itself.
Discussion Items
- The "micalg" parameter of "Application/PGP-Signature" is
necessary?
Security Considerations
This entire memo is about security.
Acknowledgements
The author thank to Hidenori Ohta and Shigeya Suzuki for their
feedback for early versions of this draft.
References
[SecMulti] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
August 1995.
[MIME] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC2045, December 1996.
[MOSS] S. Crocker, N. Freed, J. Galvin and S. Murphy, "MIME Object
Security Services", RFC1848 October 1995. 10/03/1995.
[S/MIME] Steve Dusse, Paul Hoffman, Blake Ramsdell, Laurence
Lundblade and Lisa Repka, "S/MIME Message Specification",
Internet Draft, <draft-dusse-smime-msg-01.txt>, May 1997
[PGP/MIME] M. Elkins, "MIME Security with Pretty Good Privacy
(PGP)", RFC2015, October 1996.
[PGP] D. Atkins, W. Stallings and P. Zimmermann, "PGP Message
Yamamoto [Page 5]
Internet-Draft Multi-signature for PGP/MIME May 1997
Exchange Formats", RFC1991, August 1996.
[MD5] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[SHA1] "Secure Hash Standard", National Institute of Standards and
Technology, U.S. Department Of Commerce, April 1995.
[JMSG] Kazu Yamamoto, "Japanese Message Signing Procedure with
Security Multipart", Internet Draft,
<draft-kazu-jmsg-sign-secmime-00.txt>, May 1997.
Author's Address
Kazuhiko YAMAMOTO
Graduate School of Information Science
Nara Institute of Science and Technology(NAIST)
8916-5 Takayama, Ikoma City 630-01 JAPAN
Phone: +81-7437-2-5111
FAX: +81-7437-2-5329
EMail: Kazu@Mew.org
Yamamoto [Page 6]