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:
What I'm saying is it's a MIME issue as to how or if the two body parts
are combined, not a MOSS or a security issue. MOSS (like MIME) provides
a means by which you can accomplish what you want, i.e., the building
blocks for a lot of functionality. How you make use of them is a local
issue.
Note, the first paragraph of the application/mosskey-data definition is
as follows:
The principal objective of this content type is to convey
cryptographic keying material from a source to a destination.
This might be in response to the receipt of an
application/mosskey-request content type or it might be in
anticipation of receiving an application/mosskey-request if it
is not sent.
I thought about trying to convince you that the latter half of the last
sentence is intended to cover the scenario you're concerned about, but I
decided you'd probably suggest it was too vague and a specific example
would be much more convincing. So, how about the following first
paragraph instead:
The principal objective of this content type is to convey
cryptographic keying material from a source to a destination.
This might be in response to the receipt of an
application/mosskey-request content type or it might be in
anticipation of receiving an application/mosskey-request if it
is not sent, e.g., it may be combined with a multipart/signed
object by an originator to ensure that a recipient has the
cryptographic keying material necessary to verify the signature.
When combined with other content types, the processing by a
recipient is enhanced if the application/mosskey-data content
type is positioned in its enclosing content type prior to the
content types that will make use of its cryptographic keying
material.
In response to the rest of your message:
(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?
None. In response to each (which may be moot given my suggestion
above):
(a) It is a suitable mechanism for conveying cryptographic keying
material (by definition), it's just that it's misleading to say in a
security document to combine these two objects when there is no
requirement that such a combination means the combined objects are
related.
(b) This is obviously false, since by definition
application/mosskey-data is for conveying certificates. It's a MIME
issue as to how or if the two body parts are combined. By the way, the
1421 spec is ambiguous on this point, since the spec does not require
that the certificates in a message be related to the message in which
they are conveyed. The intent is that they be related but it is not
required.
(c) This is one option than I believe is unnecessary. I wouldn't object
to someone else doing it as an adjunct specification but I would
recommend against it.
Jim