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.