[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet-Draft                                             Kazu Yamamoto
Expires in six months                                          May, 1997

                Multi-signature Extensions for PGP/MIME

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

    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


    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.


    "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

    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

    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";

        Content-Type: text/plain; charset=us-ascii

        This is a text message to be signed.


Yamamoto                                                        [Page 2]

Internet-Draft           Multi-signature for PGP/MIME           May 1997

        Content-Type: Multipart/PGP-Signature; boundary="thismemo"

        Content-Type: Application/PGP-Signature; micalg="pgp-md5"


        Content-Type: Application/PGP-Signature; micalg="pgp-sha1"




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

    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:


    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

    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

    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
        - 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.


        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

Security Considerations

    This entire memo is about security.


    The author thank to Hidenori Ohta and Shigeya Suzuki for their
    feedback for early versions of this draft.


    [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

    [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]