[Top] [All Lists]

Re: MOSS draft

1995-03-13 14:19:46
        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

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?



<Prev in Thread] Current Thread [Next in Thread>
  • MOSS draft, Brent Stilley
    • Re: MOSS draft, James M Galvin <=