Re: Unrestricted crypto software web posting
On Thu, 20 Jan 2000, Matt Blaze wrote: > Consider it done; the alias: > > [EMAIL PROTECTED] > > now appends to http://www.crypto.com/exports/mail.txt, and also mails to > [EMAIL PROTECTED] (currently empty, but that will change as people use it). Do you agree to surrender any rights explicit or implied with respect to use of submissions to this site? Do you agree to not alter or remove any submissions (without the authors consent would be acceptable)? The future is downloading. Can you hear the impact? O[rphan] D[rift>] Cyber Positive The Armadillo Group ,::;::-. James Choate Austin, Tx /:'/ ``::>/|/ [EMAIL PROTECTED] www.ssz.com.', `/( e\ 512-451-7087 -~~mm-'`-```-mm --'-
Re: Unrestricted crypto software web posting
> > On Thu, 20 Jan 2000, Matt Blaze wrote: > > > Consider it done; the alias: > > > > [EMAIL PROTECTED] > > > > now appends to http://www.crypto.com/exports/mail.txt, and also mails to > > [EMAIL PROTECTED] (currently empty, but that will change as people use it). > > Do you agree to surrender any rights explicit or implied with respect to > use of submissions to this site? Do you agree to not alter or remove any > submissions (without the authors consent would be acceptable)? > No. I don't claim any "rights" to messages send to this address, although anyone who sends a message to it should be on notice that their message will be available in a public archive and be forwarded to the [EMAIL PROTECTED] address. Authors retain the rights to their own words, as is customary under the laws of most places. Because I'm a nice guy, I'll try to keep the alias running properly. But I make no promises, and, like just about everything else in the entire computer and communications industry, there are no guarantees of anything. I won't alter anyone's words, but I reserve the right to discontinue this service at any time and to remove any inappropriate material (this would include anything that isn't a notice of export, and where I am the sole judge of what that means). Still, I think you'll find you're getting more than you're paying for here.
More BXA mail about regs
I decided to ask the BXA all the anal questions about export of crypto source code that I could think of, since we'll probably run into every one of them in the next week around here. So, I sent mail to Jim Lewis at BXA with a pile of questions, and the answers are at http://www.columbia.edu/~ariel/jlewis-answers.html Now someone else can ask the ones I missed. Maybe we should collect this sort of mail and put it someplace, too. ariel
Re: Unrestricted crypto software web posting
Amazing. If you could get this address publicized far wider than the original BXA address, it would save the folks at EPIC countless hours of FOIA filings to find out what's been sent to [EMAIL PROTECTED] :-) -Shabbir At 3:37 PM -0500 1/20/00, Matt Blaze wrote: >Consider it done; the alias: > > [EMAIL PROTECTED] > >now appends to http://www.crypto.com/exports/mail.txt, and also mails to >[EMAIL PROTECTED] (currently empty, but that will change as people use it). > >-matt > > > > Wouldn't it be great if "we" could get put on the "[EMAIL PROTECTED]" > > mailing list? Failing that, perhaps eff.org, crypto.com, or similar > > could set up a "export-notice" mail alias that forward to the BXA, > > but also archives them for folks (e.g., JYA :) to keep. > > > >/R$ > > > > PS: Just for the heck of it, I tried something and got back: > >The message that you sent was undeliverable to the following: > >[EMAIL PROTECTED] (user not found) > >[EMAIL PROTECTED] (user not found) > > > >Possibly truncated original message follows: > >...elided > >
Re: Unrestricted crypto software web posting
Consider it done; the alias: [EMAIL PROTECTED] now appends to http://www.crypto.com/exports/mail.txt, and also mails to [EMAIL PROTECTED] (currently empty, but that will change as people use it). -matt > Wouldn't it be great if "we" could get put on the "[EMAIL PROTECTED]" > mailing list? Failing that, perhaps eff.org, crypto.com, or similar > could set up a "export-notice" mail alias that forward to the BXA, > but also archives them for folks (e.g., JYA :) to keep. > > /R$ > > PS: Just for the heck of it, I tried something and got back: > The message that you sent was undeliverable to the following: > [EMAIL PROTECTED] (user not found) > [EMAIL PROTECTED] (user not found) > > Possibly truncated original message follows: > ...elided >
President Clinton is a back door man
http://www.wired.com/news/business/0,1367,33779,00.html Clinton Favors Computer Snooping by Declan McCullagh ([EMAIL PROTECTED]) 6:00 p.m. 19.Jan.2000 PST WASHINGTON -- Visions of stealthy black helicopters landing on your lawn and disgorging Nomex-clad troops to steal your PGP keys aren't just for conspiracy theorists. The Clinton administration wants to be able to send federal agents armed with search warrants into homes to copy encryption keys and implant secret back doors onto computers. "When criminals like drug dealers and terrorists use encryption to conceal their communications, law enforcement must be able to respond in a manner that will not thwart an investigation or tip off a suspect," Attorney General Janet Reno and Deputy Defense Secretary John Hamre wrote in a seven-page letter to Congress. The idea first surfaced in mid-1999, when the Justice Department proposed legislation that allowed them to obtain surreptitious warrants and "postpone" notifying the person whose property they entered for 30 days. The Justice Department's thinking was that if a suspect was using data-scrambling encryption products, the FBI's G-men might need to enter the suspect's home and install software to tap into and decipher scrambled communications. After vocal objections from civil liberties groups, the administration backed away from the controversial plan. The final draft of the Cyberspace Electronic Security Act (CESA) submitted to Congress had removed the secret-search portions. But the White House now appears to think it doesn't need new legislation to enter a suspect's computer. [...] -- POLITECH -- the moderated mailing list of politics and technology To subscribe: send a message to [EMAIL PROTECTED] with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ --
RE: Unrestricted crypto software web posting
Wouldn't it be great if "we" could get put on the "[EMAIL PROTECTED]" mailing list? Failing that, perhaps eff.org, crypto.com, or similar could set up a "export-notice" mail alias that forward to the BXA, but also archives them for folks (e.g., JYA :) to keep. /R$ PS: Just for the heck of it, I tried something and got back: The message that you sent was undeliverable to the following: [EMAIL PROTECTED] (user not found) [EMAIL PROTECTED] (user not found) Possibly truncated original message follows: ...elided
[FYI] EU Directive 1999/93/EC on electronic signatures finally published
DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999 on a Community framework for electronic signatures Official Journal of the European Communities L13 (2000) of 2000-01-19, pp. 12ff. http://europa.eu.int/eur-lex/en/dat/2000/l_013/l_0132119en00120020.pdf
MS pr on new encryption regs
http://biz.yahoo.com/prnews/000118/wa_microso_1.html Company Press Release SOURCE: Microsoft Corp. Windows 2000 to Deliver 128-Bit Encryption Abroad Microsoft to Ship First Operating System Meeting New Federal Export Regulations REDMOND, Wash., Jan. 18 /PRNewswire/ -- Microsoft Corp. (Nasdaq: MSFT - news) today announced that the Windows® 2000 operating system will be the first platform with 128-bit encryption to be shipped internationally under the federal regulations on encryption exports announced Jan. 14, 2000. Microsoft worked closely with U.S. government regulators to obtain the necessary approvals to ship Windows 2000 with strong encryption to worldwide customers, irrespective of industry or application. ... http://biz.yahoo.com/prnews/000118/wa_microso_1.html Of course any of the US Linux companies could release a new version of their distributions in the US with strong crypto such as CFS, GnuPG, FreeSWAN, and OpenSSH included before Feb 17.
Unrestricted crypto software web posting
Pursuant to 15 CFR Part 734, as revised on January 14, 2000, notice is hereby given that files including freely-available (open source) source code for cryptographic functions is being published on the World Wide Web at URL http://people.qualcomm.com/karn/code/des/index.html Phil Karn
Re: small authenticator
You don't have enough room for RSA keys. I'd be surprised if you could fit elliptic-curve math into something that small, though there's enough room to store keys. Maybe the Certicom folks know more about it. For some kinds of authentication, a MAC is fine - you've got a server somewhere that knows your key, and the chip and the server both calculate Hash(Key,Challenge). Or you use a symmetric-key algorithm and calculate E(K,C). Both are relatively hard to crack, if your keys are long enough, but you need to have an environment where that's a useful mode of operations. At 12:10 PM 01/19/2000 -0700, [EMAIL PROTECTED] wrote: >Several people have suggested using a MAC; my problem is that the >opponent can reverse-engineer the chip and find the key. I was hoping >to give the chips a public key and have it encrypt a challenge that I'll >respond to. On my side, I'd need to prevent chosen-cipehrtext attacks. >-- >Mike Stay >Programmer / Crypto guy >AccessData Corp. >mailto:[EMAIL PROTECTED] > > > Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Trust Establishment on AlphaWorks
Hi, TrustEstablishment (available now on AlphaWorks at http://www.alphaworks.ibm.com) is a set of Java packages that can be used to solve the Trust Management problem. Below is a short description of the Trust problem and how TE can be used to solve it. More info can be found at http://www.hrl.il.ibm.com/TrustEstablishment. Any feedback is most appreciated. Regards, Yosi Mass Trust Establishment Project Manager, IBM Haifa Research Lab, Tel Aviv Site E-mail: [EMAIL PROTECTED] Tel +972-3-6978624, Fax +972-3-6914736 A new approach to the deployment of public key infrastructure is presented, based on a separation between the issuing of certificates and the usage of certificates. Certificates are signed assertions by the issuer about the subject of the certificate (holder of corresponding private key), not necessarily identifying the subject. Typical use of certificate is for access control decisions, to determine whether the subject is allowed to perform a certain action (on some resource); this decision is based on the policy of the owner of the resource. Issuers do not need to be known to resource owners in advance; it is sufficient that they, in turn, will provide sufficient certificates to be considered a trusted authority according to the owner's policy. This allows bottom-up, `grassroots` build-up of trusted issuers. Our approach extends, rather than replaces, existing role-based access control mechanisms, by providing automated role assignment. Existing access control mechanisms use the identities to map the subject to a given role, based on a static table. Our system maps the subject of the certificates to a role, based on the subject's certificates, on a given role-assignment policy set by the owner of the resource, and on the roles of the issuers of the certificates. The role is then fed as input to the existing role-based access control mechanism. This provides a simple, modular architecture and role-assignment policies. We describe an implementation called "Trust Establishment (TE)" , which can be used to provide a complete PKI-enabled web server (or other e-commerce server), or to extend access control systems. A central element in our implementation is a simple yet powerful Certificate-based Role-Assignment Policy Language specified using XML. We believe that the policy language is expressive enough to allow complex policies, including e.g. non monotone (negative) certificates while being simple enough to allow automated policy checking and processing. Processing of the policy is essential, to ensure reasonable efficiency (e.g. in handling a new certificate or revocation), to check policy e.g. for conflicts, to collect missing certificates, to compose policies, and to allow subjects to select which certificates to present. Our system includes an intelligent certificate collector that automatically collects missing certificates from peer servers, allowing the use of standard browsers (that pass only one certificate to the server). Trust Establishment Software The TE module is written in Java and therefore includes the cross platform advantages available to Java applications. The module also includes an API toolkit that programmers can use to extend the access control abilities of existing applications or web servers. All certificates and signatures are implemented through the Zurich Crypto Framework package from ZRL. The TE software uses a reduced version that does not include encryption and therefore has no problems with export regulations. Certificate Format === The Trust Establishment module uses the X509 V3 certificate format . TE is designed to support other certificate types; this type was chosen since it is currently the most commonly used. The certificate subject and issuer are identified by X500 names, where X500 defines a global directory for all names and DN is the distinguished name. The TE does not use these X500 names, but keeps a unique identifier for a subject/issuer which is derived from their public key and is kept in the standard extensions : issuer/subject altName. The TE module decides on the role for the key so it is not interested in the identity of the user; hence, the X500 names are not really important. TE uses them because they are obligatory for the X509 format. Related Documents = For further information on Trust Establishment, see the following: Trust Establishment home page at http://www.hrl.il.ibm.com/TrustEstablishment White paper accepted to the 2000 IEEE Symposium on Security and Privacy available at http://www.hrl.il.ibm.com/TrustEstablishment/paper.asp
PGP Export Ceremony
Hello, Some of you were probably at the PGP Party last night -- at the RSA Conference -- but for those who weren't you should check out this story that covers the PGP Export Ceremony that was held there: http://www.zdnet.com/zdnn/stories/news/0,4586,2423792,00.html The bottom line is that NAI now lets the world (less seven naughty nations) download all of the PGP products from www.pgp.com. Granted these are "eval" copies, but in the case of the current line-up of PGP products the only difference between "eval" and "licensed" is the text in the license file... all of the binaries are identical. Happy downloading, --Noah--
RE: PGP Export Ceremony
By the way... I suppose I should have warned everyone that the article contains myriad errors... but, oh well, it captures the spirit of the evening at least. --Noah-- -Original Message- From: Salzman, Noah Sent: Wednesday, January 19, 2000 5:25 PM To: [EMAIL PROTECTED] Subject: PGP Export Ceremony Hello, Some of you were probably at the PGP Party last night -- at the RSA Conference -- but for those who weren't you should check out this story that covers the PGP Export Ceremony that was held there: http://www.zdnet.com/zdnn/stories/news/0,4586,2423792,00.html The bottom line is that NAI now lets the world (less seven naughty nations) download all of the PGP products from www.pgp.com. Granted these are "eval" copies, but in the case of the current line-up of PGP products the only difference between "eval" and "licensed" is the text in the license file... all of the binaries are identical. Happy downloading, --Noah--
