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.
<string> ::= ; a non-null sequence of characters
For example, the string
the SAAG mailing list maintainer
I believe you must either specifically mention here that trailing white space
up to the terminating CRLF either IS or IS NOT respected. Otherwise there
is bound to be variations. (not that I'm certain it clearly matter either way)
I guess the same goes for Key-Info: etc. when QP encoding is used?
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 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.
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".
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.
Brent Stilley, Oklahoma State University, 113 Math Sciences, Stillwater, 74078