pem-dev
[Top] [All Lists]

revised PEM/MIME integration documents

1994-11-22 16:02:00
Revisions for the two documents:

        Security Multiparts for MIME:
        Multipart/Signed and Multipart/Encrypted

        PEM Security Services and MIME

have been submitted to the internet drafts directory.  The expected
names of the files will be:

        draft-ietf-pem-sigenc-02.txt
        draft-ietf-pem-mime-07.txt

but you should wait for the announcement to be sure.

The document authors do hereby request that the PEM working group "vote"
to submit these documents to the IESG to be considered for publication
as Internet Proposed Standards.  Would the Chair (Steve Kent) please
acknowledge receipt of this request.

The changes to the first document are:

1. The definition of the application/signature and application/keys and
   has been relegated to companion documents.  In particular, for PEM
   we've changed the names to application/pem-signature and
   application/pem-keys and moved the definitions to the MIME/PEM
   document.

2. "hashalg" has been changed to "micalg", for terminology consistency
   between the "old" and "new" pem.

3. The "protocol" parameter value has been changed to be the content
   type of the body part holding the control information, for example
   "protocol=application/pem-signature" and
   "protocol=application/pem-keys".

4. We added a brief section suggesting that companion documents consider
   whether their protocol needs key management body parts.

The changes to the second document are:

1. Instead of "obsoleting RFC 1424", we've chosen to use the phrase
   "replace the mechanisms of RFC 1424".  This places less emphasis on
   the status of RFC 1424 and more on the content, where it belongs.

   Similarly, we've chosen to use the word "reduces" in place of
   "simplifies" when relating the Originator/Recipient fields of the
   "old" pem with the "new" pem.  This places less emphasis on
   subjective opinion and more on technical content, where it belongs.

2. "Key identifier" has been replaced with "key selector", thus allowing
   "identifier" to refer only to the combination of "name form" and "key
   selector".  This should improve the clarity of the specification.

3. The key management content types -- application/key-data and
   application/key-request -- were renamed to be application/pemkey-data and
   application/pemkey-request.

4. The application/signature and application/keys content types were moved
   from the security multiparts document to here and renamed
   application/pem-signature and application/pem-keys.

5. The value of the protocol parameter for multipart/signed and
   multipart/encrypted was specified to be "application/pem-signature" and
   "application/pem-keys" respectively.

6. The specification of the PGP key identifier has been dropped.
   Further discussion has revealed that the best course of action for
   PGP proponents is to produce a document that makes use of security
   multiparts framework.

7. A small amount of wordsmithing for better clarity.

That's it!  See you in San Jose.

Jim Galvin
Steve Crocker
Ned Freed
Sandy Murphy

Attachment: binkLQyoUwTYq.bin
Description: application/pem-signature

<Prev in Thread] Current Thread [Next in Thread>