I have a couple of corrections to the minutes.
The first I-D, defines two multipart content types: one for use
when encrypting body parts, and one for use when signing body
parts. The intent is that these generic multipart content types
can then be customized for use with different security protocols
that would operate in the MIME environment, not just PEM. ...
However, the authors concluded that these body parts proved to
be insufficiently general to be included in this I-D, and thus
they will part of the protocol- specific documents.
Actually, the authors concluded that the movement of
application/signature and application/keys body parts from the multipart
document to the PEM-MIME document was purely administrative/editorial.
The issue was the use of the protocol parameter on the multipart header
required yet another table of values that implementations needed
knowledge of and had to be maintained by IANA. Discussions with other
MIME experts caused us to realize that the information being conveyed by
the value of the protocol parameter could just as easily be conveyed by
having protocol specific content types for the control information.
Thus, instead of using "protocol=pem" on the multipart header and a
generic control information content type of "application/signature", we
would use "application/pem-signature" on the control information content
type and use "control=application/pem-signature" on the multipart
header. The latter parameter is still required in support of one-pass
processing. Note that it differs substantially from the "protocol=XXX"
by not requiring a new table to be maintained. This is because the
"MIME specification" would state that the value is a content type, which
already has a well-defined grammar specification and existing tables.
This was believed to be a "win-win" change that in no way changes the
technical aspects of the specification.
- It was suggested that the syntactic requirements for
originator and recipient asymmetric key management IDs need not
be identical, as is reflected in the current PEM RFC (1421). The
originator ID is used to convey information needed to select the
public-key used by an originator to sign a message and to
identity the originator. This selection may involve directory
access, or may be satisfied directly by conveying the
originator's certificate in the message header (an identification
option not accommodated by the proposed syntax).
Actually, it is accommodated by the proposed syntax, since all that is
required is for an originator to include an "application/key-data"
content in the message with the "multipart/signed" content. We believe
that the most common usage will be for originators to indicate pointers
to the correct public/private keys that were used. Thus, we optimized
the PEM services syntax for this. However, there is the problem of
conveying the certificates the first time. This accommodated by the
definition of the application/key-data content type and MIME
accommodates its inclusion with a signed content type in a
straightforward way.
Jim
binHhVIntukDL.bin
Description: application/signature