In the MOSS draft:
4.1.2. Arbitrary Strings
The arbitrary string (grammar token <string>) must have a
length of at least 1. There are no other restrictions on the
value chosen.
I believe you must either specifically mention here that
trailing white space up to the terminating CRLF either IS or IS
NOT respected.
All characters immediately after the colon up to but not including the
line terminator are part of the string. I'll make this clear in the
final revision prior to publication.
In section 2.2:
The following sequence of steps comprises the application of the
encryption service.
(1) The body part to be encrypted must be in MIME canonical form.
It would be nice to reiterate the following definition from RFC1521:
The term "body part", in this document, means one of the parts
of the body of a multipart entity. A body part has a header
and a body, so it makes sense to speak about the body of a
body part.
because it wasn't clear until the examples much later in section
6 that the body part headers were also encrypted, not just the
body proper.
I don't think this is the right place for this comment but I'll find a
place to add it.
I think additional info needs to be provided with
application/mosskey-request and -data in order to support
gateway-to-gateway signing and encryption. For instance, in an
environment where most users cannot be expected to sign every
message they send out via cc:Mail or MSMail, management may
insist that their MIME gateway do it for them (as a whole
enterprise using one key assigned to the gateway, or using keys
assigned to groups somehow). This would seem to necessitate some
way of indicating that the mosskey-request is seeking a
gateway-level key, rather than a personal key, which should be
used for all recipients at a target FQDN. It is unclear to me
whether this could be done with some combination of Subject: and
Issuer:. Does it make sense in this case to simply direct the
mosskey-request to the postmaster address at the FQDN along with
explanatory text? I'd rather have the gateways automatically
respond to each other in some standard way.
The mosskey-request body part should be requesting the key of whatever
signed the message, in this case the gateway as opposed to the internal
user who passed the message through the gateway. In other words, if the
gateway signs all messages on the way out, it should sign those messages
with its own key (perhaps one of many chosen for this purpose).
As for where the query should be directed, the spec doesn't say much, by
design. However, in a semi-closed community you can setup whatever
standard address you want and just have everyone use it.
Also, where the heck am I supposed to find a copy of reference
eight in order to develop support for the "Name" production used
in distinguished names? Or is there enough info in RFC1422? And
the same goes for reference nine regarding
"SubjectPublicKeyInfo".
Ah yes, where to get ISO/ITU specifications. Do I really need to answer
this question?
Another small gripe about formatting: with all the lists
contained in this doc, I hope the final RFC will avoid having so
many of them broken into by page headings.
Can you give me an example of what you don't like and I'll see what I
can do?
Thanks!
Jim