Re: Draft of workshop notes

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Previous message: Brad Knowles: "Re: Security Problems"

At 3:00 PM 2/29/96, Dave Crocker wrote:

>     I apologize for rushing you but I'd like to release the document at
> the end of Friday, so that only gives you slightly more than a day for the
> review.  The initial, general release will also be a draft review but we
> should get the gross errors out now.

    Unfortunately, I'm not always able to check my home email for a
few days, so I missed the initial deadline on this one.
Nevertheless, I have some feedback I'd like to see get folded into
this document (or follow-on documents) in some fashion.


> 3.10.     Large home services information services supplier in
>      America (Brad Knowles <brad@his.com>)

    [ ... deletia ... ]

>      Evaluation
>           PGP/MIME (+)
>           MOSS (+)
>           S/MIME (if multipart, +)

    What I actually stated at the workshop was the that both PGP/MIME
and MOSS should get a plus (being much closer to usable as-is than
anything else), and observed that S/MIME, if it evolved to answer all
the concerns Terry Gray and I mentioned, would likewise rate a plus,
but that since that wasn't true yet, at best it could rate a dashed
minus.

    I later revised this to give PGP (as it exists today) a minus and
a full minus for S/MIME, since it does appear that it has strong
appearances of likely evolving to answer our concerns.



    Now, since I didn't contribute any of the rest of the source for
what I'm about to mention, I'm not sure how you're like to interpret
it.  However, I feel that it needs to be said:

    The chart in section 3.2 is labelled "PGP/MS" (section 4.3 is
likewise labelled) for one particular column, and as I understand it,
this is something that the PGP community (Mike Elkins, if no one
else) would like to stamp out of existance before it gets publicly
displayed anywhere.  PGP/MIME (or PGP-MIME?) should be used instead.

    Didn't Jim also have a "No Duplication" row, such that "Backward
compatible" signed (but not encrypted) documents could avoid having
both an unsigned and a signed version of the same text (the S/MIME
multipart/alternative problem)?


    As I vaguely recall, Raph Levien had three useful additional rows
to add to Jim's table from 3.2, and I'd like to see those publicly
included in some separate "working" version of that comparison table.
I'd also like to see tabular versions of my concerns included, if
they aren't already addressed by Raph's additions.  Specifically, I'd
like to see information on the following added:

        Secure - The minimum required implementation (including key length) is
                considered cryptographically secure by today's best practices
                (RC2 at 40 bits being a significant failure on this point)

        Exportable - There are no export restrictions such that there are "U.S.
                versions" and "exportable versions".  (note that, today, secure
                and exportable are mutually exclusive, so far as I know).

        Public Algorithms - All cryptographic algorithms specified in the
                standard have been and continue to be subject to public
                scrutiny (SkipJack being a notable failure).

        Freely Available - At least one reference implementation of the
                standard is freely available (a minus would mean that it
                is currently available under some restrictions, e.g.,
                export restrictions).


    I know that Raph covered some of these, but I can't find at the
moment his original note, so I don't know for sure how much I'm
duplicating here.  Also note that MIME-with-MSP (or is it
MSP-with-MIME?) needs to have a column, as well.  I'm also assuming
that the compatibility with installed base (PGP) problem will pretty
much solve itself as these standards evolve, and therefore we don't
need a separate row for that....

    In recognition of what is possible with MSP, I think we also need
to add rows for cryptographically signed receipts (very important for
closing transactions) as well as classification labelling.  And based
on re-reading the notes from Nat's presentation, I think we might
want to consider whether we want to explicitly call out whether a
standard explictly defines how it would interact with a digital
timestamping service.  We might also want to consider calling out
whether a standard defines how it interacts with anonymous remailers
(either directly in the standard itself or in a separate
"implementations" document).


    I'd also like to see some sort of tabular note made regarding how
public keys/certificates are exchanged and verified.  I'm thinking
perhaps of a line that reads "Keys/Certificates", with a key
something like "M=manual, 1=X.509v1, 3=X.509v3" with multiple entries
possible for standards that allow alternatives.



    IMO, one of the most important things (for me) was the chart that
Jim Galvin presented (section 3.2).  As I re-read the notes, I am
surprised by the amount of other useful stuff that came out of the
workshop, but this one chart still sticks out in my mind as one of
the defining moments of the entire time I spent in San Jose.



    Sorry it took so long for me to respond.

--
Brad Knowles,                                  MIME/PGP: brad@his.com
    comp.mail.sendmail FAQ Maintainer     <http://www.his.com/~brad/>
        finger brad@his.com for my PGP Public Keys and Geek Code
The comp.mail.sendmail FAQ is at <http://www.his.com/~brad/sendmail/>

• Previous message: Brad Knowles: "Re: Security Problems"