But if the use of mutlipart/alternative is only a recommendation, not an absolute requirement, how can user software know what to send to the validation server? So it has to send the whole thing. So how does the validation server know if the first part of the /alternative is supposed to be the signed text? I suppose if it isn't, the validations service could generate a further nested multipart/alternative... Sure seems like a mess to me.
Actually, that's not the end of the "mess" (lack of consistency and definition, if you prefer)... The S/MIME Message Specification (8/29/95) does not speak to content transfer encodings when using multipart/alternative. So, either it is encoded, which may result in an unreadable message if an opaque encoding (base64) is chosen, or it may result in a clear-text message that does not correspond exactly to the signed message if no encoding is used. If quoted printable is used for email that might not otherwise make it through the network unscathed, the message will be readable and will emerge at the other end of the pipe intact. Of course, MOSS will provide the same result with a message that is less than half the size. So, which is it? Spock's: The multipart/alternative construct was deemed more useful for backward compatability to non-MIME readers. This is because the "alternative" part is in readable ASCII. The use of multipart/signed infers a requirement that the "signed" text be transported from sender to recipient intact. In practice, this would cause a tendency to encode the text for transport rendering it unreadable by non-MIME readers. Or Jeff Thompson's: Since the remote validation server is S/MIME-aware (it is checking the signature), then it can also check if the message it is verifying is multipart/alternative. If it is, then it can simply confirm that the data in the "clear" part is the same as the data inside the PKCS part. If it's the latter, then what does the validation server return when the clear version has mutated in transport or is otherwise different from the signed version, assuming that it is known that the clear-text in the multipart/alternative is supposed to be a representation of the signed text and not something totally disjoint? Mark p.s. Anyone else here wonder when the authors if the S/MIME fact will substantiate their claim that two MOSS implementations might not interoperate or remove that claim from the FAQ? Somehow the implied deficiancy has not been raised and this is the list for just such discussions.
bin7jPFUvGr7J.bin
Description: application/moss-signature