From: Jason Zions <jazz@hal.com>
Date: Wed, 1 Sep 93 08:49:22 PDT
To: cypherpunks@toad.com
Subject: Re: (fwd'd) more Clipper inside?
In-Reply-To: <260kjq$irr@hal.com>
Message-ID: <9309011545.AA19233@jazz.hal.com>
MIME-Version: 1.0
Content-Type: text/plain


Warning: rampant paranoia inside.

>Check this out.
>Clipper inside the Apple get you bothered?
>How about Clipper inside all UNICES ?  (all POSICES)

Not bloody likely, for several dozen reasons.

Most importantly, POSIX does not, indeed cannot, specify implementation. All
it does is specify interfaces. That is, POSIX could define a standard API
which accepts a clear-text message and some form of secure identification
for a user and produces an authentication string which can be used by a
recipient of that message to verify that it was sent by that user. The
standard cannot state "You must use MD5" or "You must use Clipper".

POSIX also produces "Profiles", which are standards that point at other
standards. A profile might say "When the message-auth function is provided,
it shall use MD5 as its mechanism." Another profile might say "When the
message-auth function is provided, it shall use PGP."

A customer would tell a vendor "I want to buy a system that conforms to the
profile that says use Clipper for authentication." Other customers would
tell that same vendor "I want to buy a system that conforms to the profile
that says use PGP for authentication."

The base POSIX standard is neutral on the issue. Competing profiles take
stands on the issue. Customers buy systems that conform to profiles that
match their own stand on the issue.

The only way Clipper will appear in all POSIX-conforming systems is if one
of the following events occur:

  1) Only one profile is ever written, one that specified Clipper for
  message authentication and encryption.

  2) Customers tell their vendors they want the Clipper profile and don't
  tell their vendors they want any other profile.

Event (1) is pretty bloody unlikely. POSIX standards groups have substantial
international involvement; there are enough people from enough countries
where Clipper is recognized as stupid that other profiles will appear.
Besides, given a profile that requires Clipper, I can generate a profile
that requires PGP in about a day's work that will fly through ballot.

Event (2) is the one you have to watch out for. Here, though, it's a case of
the sheep going meekly to slaughter, which is what cypherpunks aim to stop
anyway.

Upshot: POSIX is a weak tool in the hands of the Clipper camp; don't sweat
it.

]                    Cryptographic Services
]
]One proposal has been received, form NIST, which outlines interfaces for
]several areas of cryptographic services: user cryptographic database
]management, secret key cryptography services,  and public key cryptography
]services.  The secret key services include encryption and data integrity,
]as well as key management. The public key services include encryption
]and digital signatures, as well as key management. The proposal will
]be included in the POSIX mailing and will be discussed at the October meeting.
]Another proposal may be submitted by the October meeting and will also
]be discussed.  Any additional proposals for crytpographic services will
]also be entertained.

Looks like APIs to me. I suspect there will be substantial opposition to
*all* cryptographic API standards from vendors, simply because they know
that the f-ing US Government, in the person of the Commerce Department, will
then tell them they cannot export those APIs and the mechanisms under them.
There's no point in standardizing something when you can't sell it to more
than half of your customers.

All you have to do is figure out how to use a more positive cryptographic
engine (like PGP) with each of the APIs that get defined; we push a profile,
and we're done.

Jason Zions
Chair, IEEE P1003.8 POSIX Transparent File Access
Note: I am speaking solely for myself. This is not an official statement of
IEEE or any entity thereof.