Edited Edupage, 24 March 1996

From:	IN%"educom@elanor.oit.unc.edu" 26-MAR-1996 19:24:26.78
To:	IN%"edupage@elanor.oit.unc.edu"  "EDUCOM Edupage Mailing List"
CC:	
Subj:	Edupage, 24 March 1996

*****************************************************************
Edupage, 24 March 1996.  Edupage, a summary of news items on information
technology, is provided three times each week as a service by Educom,
a Washington, D.C.-based consortium of leading colleges and universities
seeking to transform education through the use of information technology.
*****************************************************************

>ONLINE TRADING 
>Lombard International Brokerage in San Francisco and Pawws Financial Network
>in New Jersey are two brokerage houses that have opened Internet trading
>services, allowing customers to monitor their portfolios and retrieve
>corporate and financial information from brokerage databases or through
>links to other Web sites.  "You're seeing the culmination of the information
>brokerage -- with customer service, advanced analytical tools, and news
>available at one place and one time on the most incredibly productive medium
>that ever existed, the Internet," says Lombard's CEO.  By incorporating a
>Java applet into their Web design, Lombard's Web site refreshes its
>information every 30 seconds so that intra-day trading charts are
>automatically updated.  The Pawws trading system, a tailored version of the
>Security APL cash-management system, is used by several other investment
>houses to display their wares.  "Why should we spend time and money to tell
>people how to get a modem to work?  We provide brokerage -- not technical --
>services," says one user.  (Information Week 11 Mar 96 p64)  And discount
>broker Charles Schwab & Co. will begin this May to allow its customers to
>trade listed and over-the-counter stocks, get real-time quotes, and access
>account information using the Schwab site on the World Wide Web.  (Atlanta
>Journal-Constitution 22 Mar 96 F3)

	They're using _Java_ to do this? 

>PORN IS A GOLD MINE FOR IDT
>Tiny IDT Corp. has found a way to differentiate itself from the
>run-of-the-mill Internet access provider.  It pitches its service to porn
>aficionados, with ads like:  "With IDT, I access *all* Internet services.  I
>said *all* Internet services -- get that smirk off your face."  In fact, its
>service and pricing are similar to everyone else's, but its subscriber base
>has grown six-fold to 65,000 in the past six months using this approach.
>"IDT is looking for a marketing niche, and given how we think the primary
>Internet audience is -- lonely 20-something and 30-something males -- why
>not aim that niche at them?" says Gary Arlen, an Internet consultant. (Wall
>Street Journal 22 Mar 96 B4)

	An interesting way to differentiate oneself. I would suggest that
anonymnity (i.e., C2) would be a logical add-on.

>NETSCAPE TO GET IN ON THE PHONE-BY-INTERNET ACTION
>Netscape co-founder Mark Andreessen says that within six months the company
>will build into its Navigator program voice software (which it calls Insoft)
>for making low-cost long distance calls via the Internet into its Navigator
>program and that long-distance phone companies increasingly won't be able to
>justify their rates for telephone service.  (Sydney Morning Herald 13 Mar 96
>via Individual Inc.)

	Any possibility that Netscape might build in some form of cryptography?
I realize ITAR rules would make this problematic, but perhaps some sort of
out-of-country deal for putting in the hooks for PGPhone could be done.
	-Allen

>Edupage is written by John Gehl (gehl@educom.edu) & Suzanne Douglas
>(douglas@educom.edu).  Voice:  404-371-1853, Fax: 404-371-8057.  

>Technical support is provided by the Office of Information Technology,
>University of North Carolina at Chapel Hill.

>***************************************************************
>EDUPAGE is what you've just finished reading.  To subscribe to Edupage: send
>a message to: listproc@educom.unc.edu and in the body of the message type:
>subscribe edupage Graham Greene (assuming that your name is Graham Greene;
>if it's not, substitute your own name).  ...  To cancel, send a message to:
>listproc@educom.unc.edu and in the body of the message type: unsubscribe
>edupage.   (Subscription problems?  Send mail to educom@educom.unc.edu.)

-----BEGIN PGP SIGNED MESSAGE-----

In list.cypherpunks, EALLENSMITH@mbcl.rutgers.edu writes:

> Subj:   Edupage, 24 March 1996

>>NETSCAPE TO GET IN ON THE PHONE-BY-INTERNET ACTION

>         Any possibility that Netscape might build in some form of
> cryptography? I realize ITAR rules would make this problematic, but
> perhaps some sort of out-of-country deal for putting in the hooks
> for PGPhone could be done.

Seems like SSL could work for this.
- -- 
           Roy M. Silvernail     [ ]      roy@cybrspc.mn.org
PGP Public Key fingerprint =  31 86 EC B9 DB 76 A7 54  13 0B 6A 6B CC 09 18 B6
                Key available from pubkey@cybrspc.mn.org

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMVnQGxvikii9febJAQFcxAP/TkEuQ9lPx/USyQjptvmL8FvM+nMvZrn/
m1tS7nYJ7SR7DQWl5uZM8Y+MRPZeDsmqvPNT13auS7QVJYDbM58Jp35khbJ/jdND
hWC/H4h/yyBt/GVoFgByLI/ORletMW5p9dEuVFXAY0BCFuB17yvdhr0UkOcaTPiZ
ciSWevXjh1I=
=L3PH
-----END PGP SIGNATURE-----

E. ALLEN SMITH wrote:
> >NETSCAPE TO GET IN ON THE PHONE-BY-INTERNET ACTION
> >Netscape co-founder Mark Andreessen says that within six months the company
> >will build into its Navigator program voice software (which it calls Insoft)
> >for making low-cost long distance calls via the Internet into its Navigator
> >program and that long-distance phone companies increasingly won't be able to
> >justify their rates for telephone service.  (Sydney Morning Herald 13 Mar 96
> >via Individual Inc.)
> 
>         Any possibility that Netscape might build in some form of cryptography?
> I realize ITAR rules would make this problematic, but perhaps some sort of
> out-of-country deal for putting in the hooks for PGPhone could be done.

  The internet phone software is coming from one of the companies that
we are acquiring.  This is one obvious application of SSL that I will be
looking into after the merger is complete.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Jeff Weinstein writes:
> >         Any possibility that Netscape might build in some form of
> >         cryptography?
> > I realize ITAR rules would make this problematic, but perhaps some sort of
> > out-of-country deal for putting in the hooks for PGPhone could be done.
> 
>   The internet phone software is coming from one of the companies that
> we are acquiring.  This is one obvious application of SSL that I will be
> looking into after the merger is complete.

1) I strongly suggest that SSL is *not* in its current form the right
   technology, because internet phone type tools probably use UDP, not
   TCP.
2) I strongly hope that Netscape tries to move the product towards
   standards based mechanisms like the IETF's RTP protocol, which are
   in widespread use, rather than pushing yet more proprietary
   systems. Proprietary is bad in this instance. I believe, by the
   way, that several existing RTP implementations have encryption in
   them.

Perry

Perry E. Metzger wrote:
> 
> Jeff Weinstein writes:
> > >         Any possibility that Netscape might build in some form of
> > >         cryptography?
> > > I realize ITAR rules would make this problematic, but perhaps some sort of
> > > out-of-country deal for putting in the hooks for PGPhone could be done.
> >
> >   The internet phone software is coming from one of the companies that
> > we are acquiring.  This is one obvious application of SSL that I will be
> > looking into after the merger is complete.
> 
> 1) I strongly suggest that SSL is *not* in its current form the right
>    technology, because internet phone type tools probably use UDP, not
>    TCP.

  I guess that is what I get for posting when too tired.  Certainly the
current SSL won't work for UDP based protocols.  Either we will have to
make a UDP version of SSL or use some existing protocol that gets the job
done.  Since our acquisition is not complete I haven't really had an
opportunity to talk to the streaming media guys yet...

> 2) I strongly hope that Netscape tries to move the product towards
>    standards based mechanisms like the IETF's RTP protocol, which are
>    in widespread use, rather than pushing yet more proprietary
>    systems. Proprietary is bad in this instance. I believe, by the
>    way, that several existing RTP implementations have encryption in
>    them.

  Here is a quote from a recent press release - "The Netscape LiveMedia
framework will be based on the Internet Realtime Transport Protocol (RTP),
RFC number 1889...".  The full release can be found at:

	http://home.netscape.com/newsref/pr/newsrelease81.html

I believe that the current product (which was developed by a company that we are
acquiring) will be migrated to RTP as soon as we can do it.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Jeff Weinstein writes:
> > 1) I strongly suggest that SSL is *not* in its current form the right
> >    technology, because internet phone type tools probably use UDP, not
> >    TCP.
> 
>   I guess that is what I get for posting when too tired.  Certainly the
> current SSL won't work for UDP based protocols.  Either we will have to
> make a UDP version of SSL or use some existing protocol that gets the job
> done.  Since our acquisition is not complete I haven't really had an
> opportunity to talk to the streaming media guys yet...

You probably want to look into the hooks that RTP audio programs like
VAT use right now to do their cryptography (yes, they do crypto) -- I
belive there is lots of precedent.

Perry

Perry E. Metzger wrote:

> 2) I strongly hope that Netscape tries to move the product towards
>    standards based mechanisms like the IETF's RTP protocol, which are
>    in widespread use, rather than pushing yet more proprietary
>    systems. Proprietary is bad in this instance.

Personally, I have some trouble with the work proprietary above.

    SSL 2 and SSL 3 protocols have been IETF drafts from the beginning.
    Discussion has been going on in a public forum since
	SSL 2 was first proposed. (Send a message to
	ssl-talk-request@netscape.com with "subscribe" in
	the Subject: to join the discussions.
    There is no trademark or copyright on the name.
    Netscape makes an SSL 2 implementation available with a no-cost
	license for non-commercial applications
    Other implementations done directly from the SSL 2 spec
	are also available.

SSL 3 has been made available to the newly convened IETF Transport Level
Security working group. If you want to be involved in the process send a
message to ietf-tls-request@w3.com with "subscribe" in the Subject
field.

SSL does depend upon an underlying reliable bytestream. This means it is
not the best choice for all applications. There are many for which it is
more than adequate.

PK
--
Philip L. Karlton		karlton@netscape.com
Principal Curmudgeon		http://home.netscape.com/people/karlton
Netscape Communications

     They that can give up essential liberty to obtain a little
     temporary safety deserve neither liberty nor safety.
		- Benjamin Franklin

Phil Karlton writes:
> Perry E. Metzger wrote:
> 
> > 2) I strongly hope that Netscape tries to move the product towards
> >    standards based mechanisms like the IETF's RTP protocol, which are
> >    in widespread use, rather than pushing yet more proprietary
> >    systems. Proprietary is bad in this instance.
> 
> Personally, I have some trouble with the work proprietary above.
> 
>     SSL 2 and SSL 3 protocols have been IETF drafts from the beginning.

We aren't talking about SSL, Mr. Karlton. We are talking about RTP
vs. a proprietary audio encapsulation. If you don't know what RTP is,
you to learn before talking about it.

> SSL does depend upon an underlying reliable bytestream. This means it is
> not the best choice for all applications.

Such as internet phone, for example.

Perry

Perry E. Metzger wrote:

> We aren't talking about SSL, Mr. Karlton.

My apologies for misunderstanding what you wrote. It could be that I am
oversensitive on the issue since SSL has been "accused" of being
proprietary in many forums.

> If you don't know what RTP is,
> you to learn before talking about it.

I am not an expert, but I do have some familiarity, and I wasn't talking
about it.

PK
--
Philip L. Karlton		karlton@netscape.com
Principal Curmudgeon		http://home.netscape.com/people/karlton
Netscape Communications

     They that can give up essential liberty to obtain a little
     temporary safety deserve neither liberty nor safety.
		- Benjamin Franklin

On Wed, 27 Mar 1996, Phil Karlton wrote:

> Perry E. Metzger wrote:
> --
> Philip L. Karlton		karlton@netscape.com
> Principal Curmudgeon		http://home.netscape.com/people/karlton

It's clear we have a good match here.

Charles Bell

On Wed, 27 Mar 1996, Phil Karlton wrote:
> Perry E. Metzger wrote:
> > We aren't talking about SSL, Mr. Karlton.
> My apologies for misunderstanding what you wrote. It could be that I am
> oversensitive on the issue since SSL has been "accused" of being
> proprietary in many forums.

Just a quick comment on the openness of SSL.  I have been able to 
implement SSL and support routines from internet available documentation.
There is only one part that I have had trouble getting documentation 
for.  This one part is a 'standard' but the only way I can get it is by 
either spending lots of money or by getting other people to send me their 
own online information.
I'm talking about X509/ASN.1.  I still am not sure of the format of the 
ASN.1 BOOLEAN type, and I have only just been able to get hold of the 
actual full specification of X509v3.  The UNIVERSALSTRING type?  Only 
found out about it's existance 3 days ago.

Netscape has not been in anyway an impediment to implementing SSL.
RSA inc and it's software patents are more of an issue.  Mind you, I 
would not have gotten off the ground if it was not for RSA's PKCS 
documents.  As some-one who started implementing SSL as a learning 
exercise with no money to spend, I have learnt to dislike the way some 
the 'standards' are not available (by which I mean available for 
the masses via the internet, ala rfc's).

eric (venting some frustration that build up during the just completed
      'quest for the X509v3 spec')
--
Eric Young                  | Signature removed since it was generating
AARNet: eay@mincom.oz.au    | more followups than the message contents :-)

On Thu, 28 Mar 1996, Eric Young vented:

> exercise with no money to spend, I have learnt to dislike the way some 
> the 'standards' are not available (by which I mean available for 
> the masses via the internet, ala rfc's).
> 
> eric (venting some frustration that build up during the just completed
>       'quest for the X509v3 spec')

Speaking of which, could someone tell me who Canada's standards body and 
rep to the ISO is (and if that's where I've gotta go to get my hands on X.509
and all those other X.docs.). Any addresses would be helpful too.

(Excusa mi si eso no esta relevant to bilingualpunks ;-> )

On Thu, 28 Mar 1996 s1113645@tesla.cc.uottawa.ca wrote:

> Speaking of which, could someone tell me who Canada's standards body and 
> rep to the ISO is (and if that's where I've gotta go to get my hands on X.509
> and all those other X.docs.). Any addresses would be helpful too.

Try www.itu.org (X. series docs come from the ITU, not ISO. Same text 
though).

I don't think v3 has been balloted yet - that gives you a chance to 
explore one of the more amusing twists of OSI standardisation- you can 
get copies for free of most drafts from the editor right up until it gets 
standardised. Silly, isn't it. 

Simon

----
They say in  online country             So which side are you on boys
There is no middle way                  Which side are you on
You'll either be a Usenet man           Which side are you on boys
Or a thug for the CDA                   Which side are you on?
  National Union of Computer Operatives; Hackers, local 37   APL-CPIO

On Thu, 28 Mar 1996, Eric Young wrote:

> On Wed, 27 Mar 1996, Phil Karlton wrote:
> > My apologies for misunderstanding what you wrote. It could be that I am
> > oversensitive on the issue since SSL has been "accused" of being
> > proprietary in many forums.

A lot of the aura of "proprietariness" of SSL comes from the early 
history, which I don't think we need to go into again.

> ASN.1 BOOLEAN type, and I have only just been able to get hold of the 
> actual full specification of X509v3.  The UNIVERSALSTRING type?  Only 
> found out about it's existance 3 days ago.

DER BOOLEAN :  [UNIVERSAL 1]
	
	true - 0x01 0x01 0xff
	false- 0x01 0x01 0x00

I never had any problem getting hold of ASN.1 information for free (I 
even managed to get a change into the PER spec without being a government).
Marshall Rose's "The Open Book" really helped.  protectzia rules, even if 
Tim doesn't know what it means :)

Mind you, when I was working on z39.50 I had tremendous fun working on 
debugging when just about everybody had hand-rolled their own compilers 
or codecs, and nobody actually had a real copy of the ASN.1 specs 

The real problem with asn.1 is that it is so easily abused; unless you 
stop and think about what the spec you're writing is going to look like 
in terms of structs and bits on the wire it's way too easy to come up 
with something completely unimplementable. 

When used correctly it can be a life saver, and when used with PER, the
encodings generated are often way better than you'ld end up with if you
designed the encodings manually, especially for modern cache
architectures; however if the spec is fucked up there's not a lot you can 
do. 


Hmm - hi abuse potential - now there's something that really needs federal
regulation. 

Simon