Jim:
To summarize some relevant facts, MIME describes a framework for
organizing and transporting body parts. Except for
multipart/alternative and multipart/parallel, it does not specify any
relationship between the body parts in any given message, i.e., all body
parts are independent of all other body parts. What the MOSS
specification does is define a set of new body parts. For two of those
body parts (multipart/signed and multipart/encrypted), it explicitly
defines a relationship between the nested objects.
The issue is that even if an application/mosskey-data body part appears
in a message, there is neither a requirement nor a guarantee that the
certificates (key data) in it have anything to do with any other
digitally signed body part (or any other body part) in the message.
Hence, the following statement:
The information in the body part is entirely independent of any
other body part.
is (already) included in the definition of application/mosskey-data.
In conclusion, we (the authors) believe it would be misleading (from a
security perspective) to say any more than what is already stated in the
current draft of the specification.
I'd appreciate some clarification of the point you make here, refering to the
request to add the following text from Paul Lambert:
*Digital signature implementations can be simplified/optimized if the signer's
*certificate (and, possibly, other certificates in the chain) accompany the
*signature. This is not a mandatory capability because of the potentially
*excessive communications overhead. MIME messages may contain any number of
*parts, so certificates may be readily included with MOSS protected
information.
*The certificate chain should be created as a separate MIME object and then
*combined with the MOSS protected MIME information to make a single MIME
object.
*The object conveying the certificate(s) should precede the signed object in
the
*message.
I feel this text nicely reflects what I thought was an agreement built up, in
the review period of the previous I-D, as to a common method for conveying
certificates with a multipart/signed body part. You now seem to be saying one
or more of:
(a) The above approach would not be a suitable convention for carrying
certificates along with a multipart/signed, because it would be "misleading
from
a security perspective". (If you are saying this, you might expand on the
security concern.)
(b) There should not be any agreed common (optional) method for conveying
certificates with a multipart/signed. (This would imply a significant
functional shortcoming of MOSS vis-a-vis RFC1421.)
(c) The correct way to document an approach to conveying certificates with
multipart/signed would be state a relationship between a multipart/signed and
an
application/mosskey-data somewhere in the same message. (This would
necessitate
a technical change to the spec.)
Which of these statements would you support?
Warwick