I've been holding off raising new technical issues until the WG status
and charter got worked out. Paul mentions an effort to finish up, and I
don't know what it is that is trying to be accomplished. Repeating my
question of Jul 2, where are we?
As far as open issues goes, I don't think the issue about the
DN-to-email mapping requirements of section 3.1 of the cert document has
been resolved.
The msg document makes use of the application/mime media type, which the
IESG has not approved. I have serious concerns with application/mime.
It has a far-reaching impact on MIME implementations which is both
non-obvious and subtle, and this impact is not mentioned at all in
draft-crocker-wrap-01.txt.
An application/mime can transport a binary MIME object. It is the first
method by which this can be done in the context of internet mail. A
large number of deployed MIME readers in the email domain are incapable
of handling binary MIME objects. It needs to be understood that
implementing application/mime will require rewriting these MIME
implementations, and the document needs to make this requirement more
explicit.
The application/mime document is also entirely missing an explanation of
the canonical encoding implications of the type. The contents of an
application/mime are in canonical (CRLF-separated) form, and this must
be made clear. Many MIME parsers deal with MIME entities which have
had CRLF sequences encoded into a local form of line break. Such MIME
parsers cannot be directly handed an application/mime object, especially
if that object is binary.
This "binary MIME object" problem is also an issue for the
application/pkcs7-mime type. I've already heard reports of
noninteroperability between different S/MIME implementations, because
some senders imbed binary MIME objects inside an application/pkcs7-mime
objects and some readers cannot handle binary MIME objects contained
inside application/pkcs7-mime objects.