Replacing SSL
Pete Chown
SSL for what is now called Mozilla. Since then, I have had lots of
offers of help, some from people who know a lot more about cryptography
than I do. I thought, though, that it might be worth reposting my
original message now that we have our own newsgroup/mailing list.
If you are interested in helping, please do post here (or send me
email). Otherwise we will find that lots of people are working on the
same thing. (As an aside, the FSF have been wanting a GPL "clone" of
PGP for ages. Now they have two, with another one under development.
Obviously this was not the outcome they had in mind. One of the clones
was mine, and it wasn't the outcome I had in mind either. :-( )
----------
-- I would like to volunteer to reimplement SSL in the version of
Communicator that is released by Netscape. Suggestions are welcome, but
the way I would envisage it is that:
- US users wanting a binary release would download the 128-bit
Communicator from Netscape, the same as now.
- US users could not be given the cryptographic source code, because
this would violate Netscape's BSAFE licence. They could not import the
international source code because this would violate the RSA patent.
There is no way round this problem that I can see.
- International users wanting a binary release could either download a
40-bit Communicator as now, or else download a 128-bit binary release
from a suitable mirror site. I could look after the Linux, Windows and
Win32 builds; I would need volunteers to maintain the others.
- International users wanting the source code would download the
non-crypto version from Netscape. There would then be a patch file to
add cryptography on.
Hopefully this could be in the form of a small patch together with a
few additional files. Then it would not be too hard to keep an
international build up to date as the master source code changes.
Another alternative, which would be much nicer is to split crypto off
into a separate library. However, we are then into the issue of
whether Netscape is being exported with cryptographic hooks. The key
would be to make the interfaces high enough level so that they are not
specifically for crypto. What do we need...?
- a way of handing arbitrary MIME types, to deal with the application/
x-x509-ca-cert and application/x-x509-user-cert types. We already have
this, so this is not a problem.
- a way of adding new HTML tags, to deal with the keygen component.
- a way of adding new protocols, to deal with https:... URLs.
- a way of adding new menu items, so that people can view the security
information for a page.
What do people think? If I wrote code to add these features to
Communicator, and they were incorporated into the build, would it then
become impossible to export it from the US?
(Of course, I cannot give a firm commitment to do any of this until I
have seen the source! Also, I am currently doing some legal
investigations of my own which may have a bearing on what I can and
cannot do.)
-----------------------------------------------------------------------
Pete Chown, email p...@skygate.co.uk, phone +44 (0) 70 5001 4574,
fax +44 (0) 70 5009 2846, mobile +44 (0) 468 765 645,
post 58 Foss Avenue, Croydon, CR0 4EU, England
Ben Laurie
Pete Chown wrote:
>
> A while ago I posted to the general newsgroup, offering to reimplement
> SSL for what is now called Mozilla. Since then, I have had lots of
> offers of help, some from people who know a lot more about cryptography
> than I do. I thought, though, that it might be worth reposting my
> original message now that we have our own newsgroup/mailing list.
>
> If you are interested in helping, please do post here (or send me
> email). Otherwise we will find that lots of people are working on the
> same thing. (As an aside, the FSF have been wanting a GPL "clone" of
> PGP for ages. Now they have two, with another one under development.
> Obviously this was not the outcome they had in mind. One of the clones
> was mine, and it wasn't the outcome I had in mind either. :-( )
I certainly intend to have a good look at implementing SSL using SSLeay,
in the same sort of way as I have done for Apache-SSL. Obviously,
there's more work in it than for a server, so I'd be only too pleased to
cooperate with other interested parties.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: b...@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Marc Branchaud
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Pete Chown <Pete....@skygate.co.uk> scrawled:
>
> A while ago I posted to the general newsgroup, offering to reimplement
> SSL for what is now called Mozilla. Since then, I have had lots of
> offers of help, some from people who know a lot more about cryptography
> than I do. I thought, though, that it might be worth reposting my
> original message now that we have our own newsgroup/mailing list.
>
> If you are interested in helping, please do post here (or send me
> email). Otherwise we will find that lots of people are working on the
> same thing. (As an aside, the FSF have been wanting a GPL "clone" of
> PGP for ages. Now they have two, with another one under development.
> Obviously this was not the outcome they had in mind. One of the clones
> was mine, and it wasn't the outcome I had in mind either. :-( )
>
What I'm really keen to work on is the certificate/PKI side of things. But
before work on that stuff can even start there has to be a crypto library in
the source. I'd prefer that library to be SSLeay, since that's what I'm most
familiar with. I'm willing to help Ben Laurie, and whoever else, incorporate
SSLeay into Mozilla.
After that I'd get to work on the stuff I'm really interested in -- improving
the key & certificate management interfaces, better support for v3-extended
X.509 certs (the PKIX extensions would be nice), signed web forms, better
support for revocation checking...
>
[ ... ]
>
> - International users wanting a binary release could either download a
> 40-bit Communicator as now, or else download a 128-bit binary release
> from a suitable mirror site. I could look after the Linux, Windows and
> Win32 builds; I would need volunteers to maintain the others.
>
I can work with some other unixes -- FreeBSD, Solaris, Irix. Hmmm, I'm
guessing I might need Motif on some of those...
> - International users wanting the source code would download the
> non-crypto version from Netscape. There would then be a patch file to
> add cryptography on.
>
> Hopefully this could be in the form of a small patch together with a
> few additional files. Then it would not be too hard to keep an
> international build up to date as the master source code changes.
>
I doubt it'll be just a few extra files. The SSLeay distribution alone is
pretty hefty. And unless use of the international crypto library is
well-coordinated with use of the U.S. one, there could be all sorts of
little niggly differences where higher-level routines try to use crypto.
> Another alternative, which would be much nicer is to split crypto off
> into a separate library. However, we are then into the issue of
> whether Netscape is being exported with cryptographic hooks. The key
> would be to make the interfaces high enough level so that they are not
> specifically for crypto. What do we need...?
>
> - a way of handing arbitrary MIME types, to deal with the application/
> x-x509-ca-cert and application/x-x509-user-cert types. We already have
> this, so this is not a problem.
Don't forget PGP and SPKI/SDSI certs, too..
> - a way of adding new HTML tags, to deal with the keygen component.
> - a way of adding new protocols, to deal with https:... URLs.
> - a way of adding new menu items, so that people can view the security
> information for a page.
>
> What do people think? If I wrote code to add these features to
> Communicator, and they were incorporated into the build, would it then
> become impossible to export it from the US?
>
Who can tell? I imagine, though, that Netscape would be reluctant to
incorporate anything into the NPL code that might upset the NSA. We could
very well end up with an international Mozilla that has many more crypto
features than the U.S. one...
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marc...@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNQgYqFrdFXNdDxPlAQE1DQMAgA3pUUAvZO9c5kkmBFSVKZQU+il8zWLM
2MwCbpIMOnXQ1tSRwx9incZvmq2kTPZURT9Mmx8frYrtkN5AFzm+RleFDAjIUYzB
Yj3vUJITx917CWl7C+KpKAxsaR5ezTKH
=Tr1+
-----END PGP SIGNATURE-----
Kjell Wooding
I, too, have some features I'd like to implement that tie into the area of
crypto. (Specifically, Zones of Trust for Java, Javascript, and Cookies)
>Hopefully this could be in the form of a small patch together with a
>few additional files. Then it would not be too hard to keep an
>international build up to date as the master source code changes.
I think I can offer a few resources in this area, too. I can make some of
our company resources available for coordinating and/or housing these types
of development efforts (CVS tree, mailing lists, FTP, etc). Since we are a
Canadian company, we don't fall under the same rules as our US bretheren.
Specifically, we *CAN* export crypto code in almost every case (except
where the code originated from the US).
I think as a general rule, to simplify some of the legal issues we may
encounter here, we may want to ensure that all code *MUST* be written by
non-US residents in order for it to remain redistributable.
-kj
Ben Laurie
Agreed.
Looks like we've got a nice spread of interest here - seems we can do
some good stuff. All we need now is some code to hack :-)
Of course, it goes without saying that our code will have to remain
separate from the main Mozilla source. This is going to lead to pain in
the version tracking, so I hope the releases aren't _too_ frequent.
Anyone from NS care to comment on that point?
BTW, my experience of Apache-SSL suggests that moving from one version
to the next will almost never "just happen". Another thing I've found
with Apache-SSL is that careful changes to the non-crypto version that
are not directly crypto-related can help a good deal with the ease of
maintenance.
Marc Branchaud
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Stephen Zander <gib...@pobox.com> scrawled:
>
> Given the utterly abitrary nature of ITAR & the NSA, I'd be very
> suprised if doing a US-based crypto mozilla was even worth trying.
> That would just leave the issue of patent infringement and upseting
> RSA.
>
Abandoning U.S.-crypto Mozilla may be the way to go, but I don't think it'd
be a popular choice... :)
Wouldn't SSLeay's ability to use RSAref solve the patent problem? I'm
really unfamiliar with how RSAref is integrated into SSLeay, so I may be off
base here. But the U.S. version coul link RSAref while the international
version could use regular SSLeay.
So any crypto-esque development would be done outside the U.S., and Netscape
would "import" that code into the States. I wonder if Netscape has made any
promises to use a particular U.S. crypto library, which would make this
scheme just as hard to manage as any other...
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marc...@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNQhFoVrdFXNdDxPlAQEYBgL9ERxMZ5pG62J0aS1Pnu1ubhGTf9XCSwRx
XhU752dx7jit2Tku7ToAgJOyipQib5dayMPPGHkQ5rMvoc1s4m3+OBMFWCEPMDQL
xvW0g6I8P+uzg3tPN3zyWiIyDGP2a0uW
=Iy8X
-----END PGP SIGNATURE-----
Dr Stephen Henson
I can probably help in this area too. Subject to time constraints.
I have PKCS#12 code and S/MIME signing/verification stuff. I also have
prototype S/MIME encrypted code which could be finished off and used.
If/when I get info I can support the cert/private key database stuff. I
can currently read them by ignoring "unknown" bits. However to modify
them I need full info about what the "unknown" bits mean.
Steve.
--
************************************************
* Dr Stephen N. Henson. *
* Freelance Cryptographic Consultant. *
* Email: she...@bigfoot.com *
************************************************
Ben Laurie
Stephen Zander wrote:
> RSA> The license at the end of this note gives legal terms and
> RSA> conditions. Here's the layman's interpretation, for
> RSA> information only and with no legal weight:
>
> RSA> 1. You can use RSAREF in personal, non-commercial
> RSA> applications, as long as you follow the interface described
> RSA> in the RSAREF documentation. You can't use RSAREF in any
> RSA> commercial (moneymaking) manner of any type, nor can you use
> RSA> it to provide services of any kind to any other party. For
> RSA> information on commercial licenses of RSAREF-compatible
> RSA> products, please contact RSA Data Security. (Special
> RSA> arrangements are available for educational institutions and
> RSA> non-profit organizations.)
>
> This condition alone is enough to prevent the use of rsaref in mozilla IMHO.
Why? If you want to use RSA in the US, then you must pay. That's all
this says, surely?
Anyway, this has all been thrashed out with Apache-SSL (and other
things, I'm sure). The way to go is to develop outside the US, and
import into the US, where people can then deal with RSA. If they want
to.
Martin Nilsson
Marc Branchaud wrote:
>
> I doubt it'll be just a few extra files. The SSLeay distribution alone is
> pretty hefty.
>
I heard from one of the programmers at Idonex (makers of the Roxen
server) that this was one of the main reasons why they didn't use SSLeay
in Roxen.
--
/Martin Nilsson
Lutz Behnke
of functions on other crypto issues outside of SSL
Merging SSL and a PGP library while where at it? anybody?
mfg lutz
--
-----------------------------------------------------------
Lutz Behnke I have taken Knowlegde
<L.Be...@herts.ac.uk> to be my province
<lutz....@on-line.de> - Sir Francis Bacon
Information Department Director
Stephen Zander wrote:
> >>>>> "Marc" == Marc Branchaud <marc...@xcert.com> writes:
> Marc> Abandoning U.S.-crypto Mozilla may be the way to go, but I
> Marc> don't think it'd be a popular choice... :)
>
> Popular? No :)
I think that depends on whether an international coalition of
programmers (excluding U.S.-based) ends up developing better encryption
than the US-based. ...if they can get past catch-up and into
innovation.
If non-U.S. has better encryption than U.S., what do you think the U.S.
govt. will do...keep export controls or abandom them as futile? That
might be the only way to make ITAR and the NSA shut up and sit down.
--
Andrew Newell Neutron, Inc.
Information Department Director Rear 319 E. Beaver Ave.
and...@neutronet.com State College, PA 16801
http://www.neutronet.com/
Ben Laurie
Information Department Director wrote:
>
> Stephen Zander wrote:
> > >>>>> "Marc" == Marc Branchaud <marc...@xcert.com> writes:
> > Marc> Abandoning U.S.-crypto Mozilla may be the way to go, but I
> > Marc> don't think it'd be a popular choice... :)
> >
> > Popular? No :)
>
> I think that depends on whether an international coalition of
> programmers (excluding U.S.-based) ends up developing better encryption
> than the US-based. ...if they can get past catch-up and into
> innovation.
At the risk of pointing out the bleedin' obvious - the rest of the world
did this long ago.
> If non-U.S. has better encryption than U.S., what do you think the U.S.
> govt. will do...keep export controls or abandom them as futile? That
> might be the only way to make ITAR and the NSA shut up and sit down.
Again, touching on the bleedin' obvious, it has long been clear that
ITAR (now EAR, of course) has very little to do with what can be done
outside the US. What interests the NSA (and friends) is the control of
its own citizenry, firstly, and the control of the citizenry of friendly
powers, secondly, and only thirdly what unfriendly powers do (which,
natch, they have bugger all hope of controlling).
Information Department Director
Ben Laurie wrote:
> Information Department Director wrote:
> > Stephen Zander wrote:
> > > >>>>> "Marc" == Marc Branchaud <marc...@xcert.com> writes:
> > I think that depends on whether an international coalition of
> > programmers (excluding U.S.-based) ends up developing better encryption
> > than the US-based. ...if they can get past catch-up and into
> > innovation.
>
> At the risk of pointing out the bleedin' obvious - the rest of the world
> did this long ago.
Sorry, it's not exactly obvious to those of us in the U.S. ...victims
of propaganda and all that. This newsgroup is the first I've really
looked at the issue, and everyone here seemed to only be talking about
ways to emulate U.S.-based encryption. This (combined w/ all the hype
over export controls) had me assuming that the rest of the world hadn't
already surpassed U.S. encryption.
If the rest of the world has gone past U.S.-based encryption, why isn't
the talk about how to import it into the U.S.?
> outside the US. What interests the NSA (and friends) is the control of
> its own citizenry, firstly, and the control of the citizenry of friendly
> powers, secondly, and only thirdly what unfriendly powers do (which,
That part I knew.
Marc Branchaud
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Information Department Director <and...@neutronet.com> scrawled:
>
> Ben Laurie wrote:
> > Information Department Director wrote:
> > >
> > > I think that depends on whether an international coalition of
> > > programmers (excluding U.S.-based) ends up developing better encryption
> > > than the US-based. ...if they can get past catch-up and into
> > > innovation.
> >
> > At the risk of pointing out the bleedin' obvious - the rest of the world
> > did this long ago.
>
> Sorry, it's not exactly obvious to those of us in the U.S. ...victims
> of propaganda and all that. This newsgroup is the first I've really
> looked at the issue, and everyone here seemed to only be talking about
> ways to emulate U.S.-based encryption. This (combined w/ all the hype
> over export controls) had me assuming that the rest of the world hadn't
> already surpassed U.S. encryption.
>
> If the rest of the world has gone past U.S.-based encryption, why isn't
> the talk about how to import it into the U.S.?
>
I think the issue has been (and is) how to ensure that crypto-based
enhancements made outside the U.S. are incorporated into the mozilla.org code
with minimal fuss. Netscape will be compiling the mozilla.org code (&
linking with a U.S.-approved crypto library) to create its own "branded"
binaries. Ideally, mozilla.org code built with an international crypto
library would work the same as Netscape's builds.
I don't know how willing Netscape would be to "import" the same international
crypto library that everyone else decides on. In my mind, that would be the
most sensible way to go. If the rest of the world wants to build mozilla
with, say, SSLeay (it's got my vote!), then Netscape should do the same. That
way, us developers could grab the source from mozilla.org, & SSLeay from some
other place. Sadly, sensible solutions don't hold much weight with ITAR...
Here's a thought: Would Netscape be willing to have the source tree hosted
outside the U.S. (i.e. exclusively on non-U.S. servers)? Netscape could
release the crypto-clean code on the 31st, and host it on a server is, say,
the U.K. They wouldn't be exporting crypto at all, but everyone could add
crypto capabilities directly to the mozilla sources, and when Netscape made a
build they would only be importing the crypto, so no ITAR hassles.
Just a thought...
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marc...@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNQ8m9VrdFXNdDxPlAQHXXAMAouODUFUFc/sEtfsau25oY/BxACKc9VQG
V22bZg7ZWoka18qDsQUNXSNhHudHvMjOwdUnwg++jRZWFth7XeWFTWYfZDCOpH50
hwjFNCcF0gx3wRBdoYtzGC0lv+4/0ESP
=Nq3Q
-----END PGP SIGNATURE-----
nicolas roumiantzeff
>> If the rest of the world has gone past U.S.-based
>> encryption, why isn't the talk about how to import it into
>> the U.S.?
> Mainly 'cause it's a given that such importing will occur. That's
> what non-US ftp sites are for! :) Importing has always been legal.
It is legal but potentially dangerous: you could import code containing backdoors.
You could then be spied by the people you got (directly or indirectly) the encryption algorithm from.
nicolas roumiantzeff <nico...@esker.fr>
nicolas roumiantzeff
More precisely: I am more immune (I suppose) if the code comes from a commercial company (Netscape, Microsoft, RSA...) than from an unknown or uncontroled source. So you are right, US or not US is not the point.
nicolas roumiantzeff <nico...@esker.fr>
Simon P Lucy
At 10:34 18/03/98 +0100, nicolas roumiantzeff wrote:
>>> If the rest of the world has gone past U.S.-based
>>> encryption, why isn't the talk about how to import it into
>>> the U.S.?
>
>> Mainly 'cause it's a given that such importing will occur. That's
>> what non-US ftp sites are for! :) Importing has always been legal.
>
>It is legal but potentially dangerous: you could import code containing
backdoors.
>You could then be spied by the people you got (directly or indirectly) the
encryption algorithm from.
And you are immune from this if the code is from the US?
Simon
-------------------------------------------------------------------------
Objective Software
Dr Stephen Henson
nicolas roumiantzeff wrote:
>
> > And you are immune from this if the code is from the US?
>
>
Well IMHO I'm more immune if I have the source code to the stuff I'm
using.
Too much stuff from certain commercial companies is riddled with dirty
great big security holes that allow just about anyone to "spy" on what
you are doing if they so wish. Not mentioning any names here...
Information Department Director
Anyone know if there are any organizations using both of these facts in
serious efforts to lobby against crypto regulation?
1) that it hurts the U.S. position in software trade
2) that it is utterly ridiculous to limit export of crypto when the
U.S. doesn't have superior crypto
Jamie Zawinski wrote:
> Marc Branchaud wrote:
> > > If the rest of the world has gone past U.S.-based encryption, why isn't
> > > the talk about how to import it into the U.S.?
>
> Because a sizeable portion of the worldwide computer industry is still
> in the US. Those folks sure would like to ship their products to world
> markets without having to eviscerate them first. "Export jobs, not
> crypto."
Information Department Director
Dr Stephen Henson wrote:
> nicolas roumiantzeff wrote:
> > > And you are immune from this if the code is from the US?
> >
> > More precisely: I am more immune (I suppose) if the code comes from a commercial company (Netscape, Microsoft, RSA...) than from an unknown or uncontroled source. So you are right, US or not US is not the point.
> >
>
> Well IMHO I'm more immune if I have the source code to the stuff I'm
> using.
>
> Too much stuff from certain commercial companies is riddled with dirty
> great big security holes that allow just about anyone to "spy" on what
> you are doing if they so wish. Not mentioning any names here...
So (it appears from what I'm seeing) contrary to the buzz and propaganda
that one hears in the regular U.S. media, the only possible point to
regulation of crypto code is to prevent the average U.S. citizen from
being able to tell whether the govt. has placed a backdoor into a
program to spy on them...or being able to edit the code and remove the
backdoor.
Ben Laurie
Jamie Zawinski wrote:
> The right thing is probably for someone outside the US to be the
> maintainer of just the public crypto portions of Mozilla. That way,
> I still get to work on mozilla.org, without having to leave the country
> first...
Which is, of course, exactly what we are going to do.
G. Sumner Hayes
nicolas roumiantzeff wrote:
>
> It is legal but potentially dangerous: you could import code containing backdoors.
> You could then be spied by the people you got (directly or indirectly) the encryption algorithm from.
People can do this in the US, too. Unless you examine the code, you
can't know what it does. Running binary-only crypto software is really
risky; even if you don't read the source code for a source release,
chances are that other people (more paranoid than you) will and will
scream bloody murder it there's something fishy going on. Of course, a
Thompson attack is still feasible unless you wrote your own compiler(s)
or are verifying the crypto at the machine-code level, but presumably
trustworthy compilers are available on most platforms...
-Sumner
--
rage, rage against the dying of the light
G. Sumner Hayes
Information Department Director wrote:
>
> So (it appears from what I'm seeing) contrary to the buzz and propaganda
> that one hears in the regular U.S. media, the only possible point to
> regulation of crypto code is to prevent the average U.S. citizen from
> being able to tell whether the govt. has placed a backdoor into a
> program to spy on them...or being able to edit the code and remove the
> backdoor.
No, it's perfectly legal to use crypto source code inside the US as long
as you don't export it. The average U.S. citizen isn't going to use
source code, anyway -- they'll go for the shrink-wrapped binary or the
version bundled with their OS. It's my belief that the US crypto
regulations were really intended to prevent crypto from escaping;
they're just an extension of existing munitions export controls. They
really fail, though, because the authors don't understand the difference
between information (which wants to be free in the sense that it's nigh
impossible to stop it from spreading and being copied once it gets out)
and physical objects (just because I smuggle one tank out of the US
doesn't mean it's no longer worthwile to prevent more of that tank from
being exported, and if I import some weaponry there might be good reason
not to re-export it). They also try to distinguish between code and
information (it's okay to export a book with crypto algorithms in it or
even a paper copy of the source code), neglecting what von Neumann had
to say on the issue.
So basically, most of the lawmakers don't understand technology very
well and are extremely conservative about liberalizing the rules because
they think that's a one-way function. The security people (FBI, NSA)
don't understand some of the social issues involve and believe that
outlawing strong crypto without escrow is (1) possible and (2)
desirable; they're against loosening the export restrictions because
they fear it will cause more people to use strong crypto and make adding
escrow more difficult. So it's not about obfuscating the presence of a
back door, it's about trying to make (or keep) a back door socially
acceptable. Recent news is that the FBI and the executive branch are
softening their stance on this issue, so if we can keep the pressure up
they may suddenly go sane.
Of course, none of them understand this pesky thing called the first
ammendment.
G. Sumner Hayes
nicolas roumiantzeff wrote:
>
> More precisely: I am more immune (I suppose) if the code
> comes from a commercial company (Netscape, Microsoft,
> RSA...) than from an unknown or uncontroled source.
That's not a terribly good assumption, either. A better assumption is
that you are more immune if the source code is available for peer
review. Juried code is better than non-juried code, and the more widely
it's reviewed the safer it can be considered. Of course, if you don't
build the binaries yourself then you'll want to make certain you're
getting binaries built and signed by a trusted third party, but that's
completely orthogonal* to the issue of where the source code comes
from.
Your best bet for good security is to build the (published and
community-reviewed) source yourself after reviewing it (with a security
expert if it's really important).
-Sumner
*sorry for the marketroid word
Dr Stephen Henson
G. Sumner Hayes wrote:
>
>
> That's not a terribly good assumption, either. A better assumption is
> that you are more immune if the source code is available for peer
> review. Juried code is better than non-juried code, and the more widely
> it's reviewed the safer it can be considered. Of course, if you don't
> build the binaries yourself then you'll want to make certain you're
> getting binaries built and signed by a trusted third party, but that's
> completely orthogonal* to the issue of where the source code comes
> from.
>
Another issue is the security of the underlying OS and software. This
can turn many judgements on their head.
If the underlying security is sufficiently low that (for example) a
potential attacker can run arbitrary code on it there is very little you
can do.
In this case having the source code to the security software can
actually count against you. A potential attacker then knows precisely
where and how to install backdoors to do all manner of horrible things
like steal private keys and the victims identity with it: pronounced
"unlimited liability".
The solution touted by many manufacturers is to use crypto hardware.
Whereas this can prevent a catastrophic private key compromise it
doesn't stop private key usage which is nearly as bad. Also some crypto
hardware has poor random number generation: or can even be subverted
into producing predictable random numbers.
Marc Branchaud
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Dr Stephen Henson <she...@bigfoot.com> scrawled:
>
> The solution touted by many manufacturers is to use crypto hardware.
> Whereas this can prevent a catastrophic private key compromise it
> doesn't stop private key usage which is nearly as bad. Also some crypto
> hardware has poor random number generation: or can even be subverted
> into producing predictable random numbers.
>
Token-based crypto, though more secure, is not the solution to our mozilla
crypto problems (not that you implied that it was -- I'm just saying so).
Many tokens only provide a restricted crypto toolkit (e.g. only RSA signing).
Also, most are so slow that using them for SSL would be a dog's breakfast.
Many of them use serial interfaces -- imagine sending all your SSL traffic
through a serial port for (de/en)cryption before/after it goes through your
modem (or T1)...
Regardless of all that, crypto hardware is still too esoteric to be counted
upon by a general browser.
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marc...@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNRBXXlrdFXNdDxPlAQFTOAMApB8PErJuoJ/iGGETX0/4mc8VOD4V/iQg
wHAeZO2/pdrwXXWoC4zhOzvXfD07Ui+Npu7ng5rYQUvyuAOP2V60HZOypIgiI0bW
CzKFb/cfH8VHdBtvzl08BaLdpYAkFmmS
=1Ysa
-----END PGP SIGNATURE-----
Frederick G.M. Roeber
> More precisely: I am more immune (I suppose) if the code comes
> from a commercial company (Netscape, Microsoft, RSA...)
Like Crypto AG?
Information Department Director
G. Sumner Hayes wrote:
> Information Department Director wrote:
> information (it's okay to export a book with crypto algorithms in it or
> even a paper copy of the source code), neglecting what von Neumann had
> to say on the issue.
So why not just get someone to print out paper copies of the crypto
source and carry it on a flight over to the most prolific non-U.S. NPL
coder (or a European affiliate of Mozilla.org)? Would that legally
avoid all crypto uniformity problems? If so, would Netscape be willing
to go along with it?
> they think that's a one-way function. The security people (FBI, NSA)
> don't understand some of the social issues involve and believe that
When has anyone ever accused the FBI or NSA of understanding any social
issues, let alone fast-pace techy social issues?
> acceptable. Recent news is that the FBI and the executive branch are
> softening their stance on this issue, so if we can keep the pressure up
> they may suddenly go sane.
Wouldn't that be nice?
By the way, thanks to those who posted URLs of crypto-freedom sites.
Already knew about the EFF from other censorship issues; somehow I
managed not to realize they'd have info on this also. I hadn't looked
at their site in....well, apparently far too long.
> Of course, none of them understand this pesky thing called the first
> ammendment.
...nor the fourth, nor....
G. Sumner Hayes
Information Department Director wrote:
>
> G. Sumner Hayes wrote:
> > Information Department Director wrote:
> > not to re-export it). They also try to distinguish between code and
> > information (it's okay to export a book with crypto algorithms in it or
> > even a paper copy of the source code), neglecting what von Neumann had
> > to say on the issue.
>
> So why not just get someone to print out paper copies of the crypto
> source and carry it on a flight over to the most prolific non-U.S. NPL
> coder (or a European affiliate of Mozilla.org)? Would that legally
> avoid all crypto uniformity problems? If so, would Netscape be willing
> to go along with it?
For more info on this strategy, take a look at http://www.pgpi.com
Netscape probably wouldn't go for it, since if they upset the feds the
feds could pull their export licenses on everything (servers, branded
browsers, etc). I could be wrong, though.
-Sumner
Information Department Director
Stephen Zander wrote:
<and...@neutronet.com> writes:
> andrew> So why not just get someone to print out paper copies of
> andrew> the crypto source and carry it on a flight over to the
> andrew> most prolific non-U.S. NPL coder (or a European affiliate
> andrew> of Mozilla.org)? Would that legally avoid all crypto
> andrew> uniformity problems? If so, would Netscape be willing to
> andrew> go along with it?
>
> That's been done before; you don't even need a fast typist, just a good
> choice of fonts & a decent scanner.
Yah, with OCR.
> The difficulty is the one-time nature of such an activity. It would get
> old very quick if we're trying to use a "release early, release often"
> approach.
Why? They could print out a copy any time there is a significant change
in the crypto code. Yikes..."More than 70 people...for over 1000 hours"
to port the PGP code. I wonder how long it would take for the crypto
sections of the Netscape code?
Daniel Veditz
Jamie Zawinski wrote:
>
> Information Department Director wrote:
> >
> > serious efforts to lobby against crypto regulation?
>
> http://www.crypto.org/.
In addition to these advocacy organizations, major software companies
like Microsoft, Netscape, and Sun (we agree on *some* things, at least)
are lobbying the government with tales of how these regs are hurting our
business, moving jobs overseas, and not actually preventing the spread
of crypto.
-Dan Veditz
Daniel Veditz
Marc Branchaud wrote:
>
> I don't know how willing Netscape would be to "import" the same international
> crypto library that everyone else decides on. In my mind, that would be the
> most sensible way to go.
If the Int'l crypto-replacement worked, was secure, and didn't violate
any US patents then Netscape might consider using it (just guessing, I
have little contact with the crypto folks). Mozilla.org still couldn't
host it, though, it'd be strictly internal to Netscape.
> If the rest of the world wants to build mozilla
> with, say, SSLeay (it's got my vote!), then Netscape should do the same. That
> way, us developers could grab the source from mozilla.org, & SSLeay from some
> other place.
As I mentioned above, "and didn't violate any US patents"...
> Here's a thought: Would Netscape be willing to have the source tree hosted
> outside the U.S. (i.e. exclusively on non-U.S. servers)? Netscape could
> release the crypto-clean code on the 31st, and host it on a server is, say,
> the U.K. They wouldn't be exporting crypto at all, but everyone could add
> crypto capabilities directly to the mozilla sources, and when Netscape made a
> build they would only be importing the crypto, so no ITAR hassles.
Nope. I'm pretty sure the gov't would consider that to be Netscape
doing/funding overseas development of crypto, and that's not allowed
either. You'll have to do it overseas without any help from Netscape.
-Dan Veditz
Daniel Veditz
Information Department Director wrote:
>
> So why not just get someone to print out paper copies of the crypto
> source and carry it on a flight over to the most prolific non-U.S. NPL
> coder (or a European affiliate of Mozilla.org)? Would that legally
> avoid all crypto uniformity problems? If so, would Netscape be willing
> to go along with it?
We currently license our cryto code from RSA, so even apart from
government regulations we would not be able to publish the juicy bits.
-Dan Veditz
Daniel Veditz
> More precisely: I am more immune (I suppose) if the code comes from
> not the point.
>
Isn't crypto illegal in France anyway? In order to sell Communicator in
France we were forced to build a special version that doesn't do S/MIME
encrypted mail (weak SSL was acceptable, though).
We've even been warned against carrying our personal S/MIME capable
version of Communicator with us on laptops during business trips.
-Dan Veditz
Dr Stephen Henson
Daniel Veditz wrote:
>
>
> If the Int'l crypto-replacement worked, was secure, and didn't violate
> any US patents then Netscape might consider using it (just guessing, I
> have little contact with the crypto folks). Mozilla.org still couldn't
> host it, though, it'd be strictly internal to Netscape.
>
Which in practice means no RSA and possibly no RC2 either (what is the
US situation with RC2?).
It could be done but since such a beast would not talk to most servers
and not work with most CAs and wouldn't support S/MIME (which requires
mandatory RC2-40 and RSA in one standard) it wouldn't be much use at
present.
Will Price
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The fact you quote is hopelessly out of date. It took *ONE* person 2 weeks
of spare time to scan the entire 7000 pages of PGP 5.5.3 source code.
Publishing source code is really the only way to do usable crypto here in
the US -- usable meaning everyone including international users can examine
the source and use it. There were previous attempts to publish the PGP
source code before the 5.5.3 attempt. The 5.0 attempt took longer because
we just didn't understand how to print source code in books. By 5.5.3, we
had developed extremely sophisticated tools which turned the process of
printing the entire source tree into a nearly 3 step process: checkout, run
tool, print. Combined with months of time spent testing various OCR
configurations and tuning our tools, the 5.5.3 source was able to be handed
over to a sheet feeding scanner and scanned back in less time than it
usually takes a company to print CDs of its software. Also recall that
once the book left our offices and was distributed at a cypherpunks
conference on US soil, we had no hand in any of the subsequent steps.
The size of mozilla may be perhaps 3 times the size of PGP 5.5.3, but at
the rate these things can be scanned the difference is really negligible.
Also, all that would need to be published for this group is the diff files
between Netscape's official mozilla sources and the international crypto
version.
You will note that we recently made even further announcements on this
topic from the news stories in most of the industry press today.
- -Will
At 7:47 AM -0800 3/20/98, Information Department Director wrote:
>Stephen Zander wrote:
><and...@neutronet.com> writes:
>> andrew> So why not just get someone to print out paper copies of
>> andrew> the crypto source and carry it on a flight over to the
>> andrew> most prolific non-U.S. NPL coder (or a European affiliate
>> andrew> of Mozilla.org)? Would that legally avoid all crypto
>> andrew> uniformity problems? If so, would Netscape be willing to
>> andrew> go along with it?
>>
>> That's been done before; you don't even need a fast typist, just a good
>> choice of fonts & a decent scanner.
>
>Yah, with OCR.
>
>> The difficulty is the one-time nature of such an activity. It would get
>> old very quick if we're trying to use a "release early, release often"
>> approach.
>
>Why? They could print out a copy any time there is a significant change
>in the crypto code. Yikes..."More than 70 people...for over 1000 hours"
>to port the PGP code. I wonder how long it would take for the crypto
>sections of the Netscape code?
>
>--
>Andrew Newell Neutron, Inc.
Will Price, Architect/Sr. Mgr.
Total Network Security Division
Network Associates, Inc.
Direct (650)473-2906
Cell/VM (650)533-0399
<pgpfone://atropos.pgp.com>
PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNRLka6y7FkvPc+xMEQL3dACgrYJ9D0lTmg+Lo11RGkOetswHlTkAoM6R
JWwe0MoJPFJ6SGlXPiLP1xZ4
=NohK
-----END PGP SIGNATURE-----
Marc Branchaud
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Dr Stephen Henson <she...@bigfoot.com> scrawled:
>
> Daniel Veditz wrote:
> >
> >
> > If the Int'l crypto-replacement worked, was secure, and didn't violate
> > any US patents then Netscape might consider using it (just guessing, I
> > have little contact with the crypto folks). Mozilla.org still couldn't
> > host it, though, it'd be strictly internal to Netscape.
> >
>
> Which in practice means no RSA and possibly no RC2 either (what is the
> US situation with RC2?).
>
> It could be done but since such a beast would not talk to most servers
> and not work with most CAs and wouldn't support S/MIME (which requires
> mandatory RC2-40 and RSA in one standard) it wouldn't be much use at
> present.
>
Not necessarily.
I think we're all agreed that SSLeay should be the crypto package integrated
into Mozilla. SSLeay 8 has defineable crypto callbacks that Netscape can
use to substitute the RSA code easily. The internationally developed code
wouldn't even have to be changed.
Add a #define'd wrapper, and the native SSLeay RSA code wouldn't even get
built into Netscape's executables. I'm just guessing here, but I don't
think Eric Young (SSLeay's author) would oppose such an addition to the
package.
So to build a release, Netscape would take the mozilla.org code, apply the
latest crypto patch imported from a non-U.S. server, and use a couple of -D's
on the make command. I don't think that's an unreasonable price for a
globally common source tree...
Note that SSLeay's RC2 code isn't callbackized, but I don't imagine it would
be very hard to make it so.
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marc...@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNRLrJ1rdFXNdDxPlAQEphAMAgHPBD8AAW39cMeZum/WkddcCnVCL/RcX
nLjjppA0Gerh6jfBBnI3rj0r0gkzTm9QwaTkjg5PpuT4hm2e4y+j1pv5fi72NMeD
zwwKKEg1an/z3Wbs0BBWFLd/X+XTtW0b
=Sjw8
-----END PGP SIGNATURE-----
Dr Stephen Henson
Marc Branchaud wrote:
>
> Not necessarily.
>
> I think we're all agreed that SSLeay should be the crypto package integrated
> into Mozilla. SSLeay 8 has defineable crypto callbacks that Netscape can
> use to substitute the RSA code easily. The internationally developed code
> wouldn't even have to be changed.
>
My point was that if you want the source to all the crypto stuff to be
the same everywhere you don't get something that's currently of much
use.
If you start adding wrappers to the $$$ licensed stuff then you aren't
always using the same source anymore. SSLeay already does something like
that with rsaref: replacing symmetric ciphers is trivial too.
Such a thing would almost certainly be "Netscape internal only" because
there would be problems redistributing the licensed stuff it linked to
if it had an exposed interface. I would guess that your average US user
couldn't legitimately recompile the crypto section unless they had a $$$
RSA crypto licence.
Marc Branchaud
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Dr Stephen Henson <she...@bigfoot.com> scrawled:
>
> If you start adding wrappers to the $$$ licensed stuff then you aren't
> always using the same source anymore. SSLeay already does something like
> that with rsaref: replacing symmetric ciphers is trivial too.
>
Yes, it wouldn't be the same source, but the differences would be so small as
to be easily managed. Either the crypto algorithms work, or they don't.
Exactly which code does the crypto is irrelevant from a functionality POV.
> Such a thing would almost certainly be "Netscape internal only" because
> there would be problems redistributing the licensed stuff it linked to
> if it had an exposed interface. I would guess that your average US user
> couldn't legitimately recompile the crypto section unless they had a $$$
> RSA crypto licence.
>
That would be true even if there were no export restrictions. We're not
trying to get around RSA licensing, just the NSA ("just"!).
A U.S. developer, with a license, could import the crypto patch and use it
the same way Netscape would.
Marc
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC.
marc...@xcert.com PKI References page: www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNRMb21rdFXNdDxPlAQGjzQMAm5uMSeTxTWjb11RHLgmBflkZZRzqnJfN
uXJvU8s0OGlOqqOVBd3k9mLcKDdieDmgcliJSVyQTOLoLfwrzPkWgTi6cw3QQgTY
COWd0Fjf0ZBMqngYil8SP+QA4rjtOBRN
=ugMV
-----END PGP SIGNATURE-----
Ben Laurie
Daniel Veditz wrote:
>
> Marc Branchaud wrote:
> > If the rest of the world wants to build mozilla
> > with, say, SSLeay (it's got my vote!), then Netscape should do the same. That
> > way, us developers could grab the source from mozilla.org, & SSLeay from some
> > other place.
>
SSLeay can be linked with RSAREF. Is there some other problem I'm not
aware of?
Ben Laurie
Daniel Veditz wrote:
>
> Information Department Director wrote:
> >
Missing RSA is no problem. Missing _all_ the crypto hooks is much harder
to deal with. Though deal with it we shall, if there is no alternative
:-)
Bob
Marc Branchaud wrote:
>
> [ BUNCH OF STUFF DELTED! ]
>
I apologize in advance if I'm off base on my questions/comments below as
I am joining this thread late. I just wanted to throw in a couple of
'cents' of my own. I welcome all flames! ;->
Anyway, as I understand the thread thus far, the discussion is focusing
on what will happen to replace the crypto in Mozilla (i.e. SSL, S/MIME,
etc.) since Netscape can't release the source for it -- due mostly to
licensing.
At first I thought, "We'll just have to re-build the crypto portions!"
My reasoning was: (A) Exportability should *not* be an issue as long as
what we build is only as strong as what Netscape was building, (B) RSA
licensing should not be an issue because the RSA royalty of (2% * $0) is
still $0 -- (I don't have my BSAFE license agreement on me, but I'll
check it on Monday. I believe it is just a royalty on the purchase
price of the software. Anyone?) Or perhaps, using RSAREF?
My next thought was, "That's ridiculous" Because: (A) Then multiple
code bases would have to be maintained as mentioned in previous threads
because different countries would have different crypto policies, (B)
Multiple compilation 'tricks' would have to be employed to try to
satisfy every government around the world, or (C) "customers" would have
to obtain their own crypto and compile their own version.
Then, the idea hit me ----- "Let's just get rid of crypto from Mozilla
all together!" -- Now I know you are yelling explicatives at the screen
right now, but just hear me out.
Netscape currently uses a PKCS #11 library (statically linked) to
service it's crypto requirements. *This* should be the piece that they
can not release. Meaning, that Mozilla should come PKCS #11 enabled --
just without the actual static libraries implementing PKCS #11 (Not
having seen the code, I'm making an assumption). So, what would happen
if we created Mozilla such that it *COULD* utilize crypto given the
existence of some (possibly more than one) dynamically linked PKCS #11
library? Meaning, it would look for them at runtime and determine
dynamically what it can and can't do cryptographically? [NOTE: PKCS #11
has no licensing restrictions -- it is an open standard that can be
utilized freely] This would have the following advantages:
1) Mozilla can be developed completely without relying on (or being
restricted by) crypto issues (licensing or export).
2) Only 1 code base would be necessary internationally.
3) Using an "open" standard interface allows Mozilla devlopers to
concentrate on using the crypto, not supplying it.
4) Given that PKCS #11 was originally designed to be a hardware
interface (although Netscape helps show that it doesn't have to be that
way! Software can always simulate any hardware), it provides the added
*FREE* benefit of potential hardware acceleration or even storing crypto
info on smart cards (i.e. certificates, etc.).
Now, that still leaves the big question of how we get crypto into
Mozilla (given that this group is dedicated to crypto).
Well, I think the answer then becomes, "However we can". Meaning that
every country will be different with regards to both export and
licensing (read, "RSA licensing"). For example, If I build a S/W PKCS
#11 DLL with RSA capabilities, I'm responsible for handling the
licensing issues. As noted above, if I give it away for free, I think
the royalty can be avoided -- or better yet, use RSAREF. Anyway, the
point is that the 'net will find a way to do it.
I envision various web sites dedicated to distributing each countries
DLL through a provable method. Or even, if I wish to PURCHASE a
commercially available DLL, I can.
Now, I see a number of potential problems with the logic I used above.
These are:
1) Mozilla will be PKCS #11 enabled -- just no crypto.
-- This isn't really a show-stopper because we can just re-write it such
that crypto services go through a PKCS #11 library. This question will
be answered at the end of the month (perhaps Mr. Veditz at Netscape
knows the answer already?)
2) I assume that a program that attempts to use strong cryptographic
processes (i.e. making a PKCS #11 request) is freely exportable.
Meaning, just because Mozilla will request that some library (possibly
nonexistent) perform strong crypto doesn't mean that *WE* are performing
the crypto.
-- I believe this to be true. If my memory serves me correctly, the
export on strong crypto is on the actual technology implementing the
crypto, not a program attempting to use it. If this assumption is
wrong, all bets are off. (I certainly don't pretend to be a
(...yuck...) Lawyer!)
3) I also think that Netscape does not currently (i.e. Communicator
4.01) use their PKCS #11 services to implement SSL.
-- I have a feeling that their SSL implementation is a legacy carry over
from previous version. For this solution to work, we would have to
re-write their SSL implementation to use PKCS #11 service. This should
not be that difficult because: (1) the crypto call-outs should be easy
to identify, (2) PKCS #11 supports all of the mechanisms necessary to
implement SSL, and (3) if they take out SSL all together, we can modify
SSLEAY (with the authors help/permission) to use PKCS #11 and plug that
in.
4) A number of potential security problems exist with using shared
object libraries (i.e. .so or .DLL) in security software.
-- Although there is a risk of hijacking, I believe the risks are
manageable. At a minimum, this should be discussed in a separate
thread. (I know that RSA is pursing this option on a couple of thier
crypto products...)
In Conclusion....
Therefore, by removing the crypto portions from Mozilla, we allow it to
proceed unimpeded.
The crypto can be developed in a standards based manor. Plus, our
friends overseas should be able to easily develop/hack/find a PKCS #11
implementation to plug into Mozilla. They have certainly shown that
capability in the past and I don't expect this case to be any different.
Thanks for hearing me out.
I'd be very interested in hearing your comments......
- Bob
--
------------------------------------------------------------
Bob Burns Email: rbu...@ibm.net
AOL Buddy ID: Hi2Bob
ICQ ID: 6430247
------------------------------------------------------------
Dr Stephen Henson
Bob wrote:
>
[STUFF DELETED]
>
> 2) I assume that a program that attempts to use strong cryptographic
> processes (i.e. making a PKCS #11 request) is freely exportable.
> Meaning, just because Mozilla will request that some library (possibly
> nonexistent) perform strong crypto doesn't mean that *WE* are performing
> the crypto.
>
> -- I believe this to be true. If my memory serves me correctly, the
> export on strong crypto is on the actual technology implementing the
> crypto, not a program attempting to use it. If this assumption is
> wrong, all bets are off. (I certainly don't pretend to be a
> (...yuck...) Lawyer!)
>
AFAIK the main problem is "crypto with a hole". You can't just leave out
the crypto you also have to leave out anything that is a "hook". What a
"hook" is is anyones guess: it's what the NSA says it is. This means
that "all bets are off".
If it were as simple as having a hook then export controls would be
useless. All the soure to strong crypto algorithms is freely available:
they would just be linked in overseas. Everyone would use strong crypto
and EAR and ITAR would fall overnight.
As a result you can't have all the crypto going through PKCS#11 and just
have a "strong crypto module" used in the US and a "export strength"
module elsewhere.
Anyone who has utilised the PKCS#11 interface (and read the specs) will
know that even if you support strong crypto algorithms Communicator will
not use them. Thus in the export version the PKCS#11 interface is
covered by export restrictions as well because it is a "hook".
Incidentally SSL (well everything) can be set to use the PKCS#11 module
algorithms instead of its own. Not the PKCS#11 SSL based stuff but
certainly RSA and symmetric stuff. Though it currently wont use digest
algorithms and has the odd bug or two...
Also there is the issue of licensing. Even if you could do things that
way you would be allowing the PKCS#11 module to be a general crypto
library with an exposed RSA interface. The PKCS#11 stuff in Netscape
currently needs an exposed RSA interface: you can't get it to use a
CryptoAPI like interface which doesn't expose RSA.
I don't know how much Microsoft paid to allow CryptoAPI to use RSA
royalty free but it has been said that they don't support an exposed RSA
interface because the licence fee would be much greater. If MS can't
afford that then who could?
You can understand why this would be Expensive (note capital E) if you
consider that if such a beast existed no one would need to license RSA
under Windows anymore: they could just use the CryptoAPI interface.
As a result of this the discussion is on "what hooks are allowed that
aren't crypto hooks as such but make crypto related extensions easier to
add". Hence the talk of a protocol module API.
Dr Stephen Henson
Ben Laurie wrote:
>
> Daniel Veditz wrote:
> >
> > As I mentioned above, "and didn't violate any US patents"...
>
> SSLeay can be linked with RSAREF. Is there some other problem I'm not
> aware of?
>
If the crypto stuff is to be used in a profit making capacity
(Professional editions, servers) I don't think the RSAREF license allows
it.
Having said that it is probably trivial to write an SSLeay wrapper so it
gets the RSA stuff from a legitimate US source (BSAFE maybe?). This
could probably be developed outside the US by using the SSLeay BSAFE
wrapper to enable RSA in an RSA wrapped version of SSLeay to an RSA
enabled version. There seems to be some heavy irony in there somewhere
:-)
Steve (who is very glad the RSA patent isn't valid here in the UK).
Bob
Steve,
Thanks for the quick reply. I appreciate the clarifications. I'm
mostly convinced that perhaps this has been hashed (no pun intended)
through before, but I just have a few more questions in the notes
below.
Dr Stephen Henson wrote:
>
> AFAIK the main problem is "crypto with a hole". You can't just leave out
> the crypto you also have to leave out anything that is a "hook". What a
> "hook" is is anyones guess: it's what the NSA says it is. This means
> that "all bets are off".
Are the restrictions regarding "hooks" layed out in documentation
somewhere? NSA? Dept. of Commerce? etc.? If you could point me in
their direction, I'd love to give them a read.
>
> [STUFF DELTED]
>
> Anyone who has utilised the PKCS#11 interface (and read the specs) will
> know that even if you support strong crypto algorithms Communicator will
> not use them. Thus in the export version the PKCS#11 interface is
> covered by export restrictions as well because it is a "hook".
1) I am assuming what you mean by 'specs' is some Netscape produced spec
regarding it's use of PKCS #11 and not the PKCS #11 spec itself.
2) Netscapes current use of PKCS #11 is though the use of a static
library, and as such, is no different than using BSAFE. Regardles of
how the program does it (i.e. using BSAFE or using PKCS #11), the reason
for export restriction is the type of crypto used and not how it is
used.
>
> algorithms instead of its own. Not the PKCS#11 SSL based stuff but
> certainly RSA and symmetric stuff. Though it currently wont use digest
> algorithms and has the odd bug or two...
I'm a little confused by this statement....Why couldn't Netscape use the
PKCS #11 SSL mechanisms? (I realize it doesn't use them today, but I'm
refering to the future).
> I don't know how much Microsoft paid to allow CryptoAPI to use RSA
> royalty free but it has been said that they don't support an exposed RSA
> interface because the licence fee would be much greater. If MS can't
> afford that then who could?
I think this paragraph is misleading. The choice by Microsoft to not
expose RSA for the reason of 'costing too much' could be better
classified as a decision not to increase the price of Windows by 2% (or
conversely, throw away 2% of the profit of each sale) to expose an API
which will be used minimally by most of the users of Microsoft operating
systems. From a management standpoint, I would have a hard time
convincing a customer that the reason for a cost increase was to add
exposed APIs that 99% of the users would not know how to use. Even
Microsoft agrees with this one.
>
> You can understand why this would be Expensive (note capital E) if you
> consider that if such a beast existed no one would need to license RSA
> under Windows anymore: they could just use the CryptoAPI interface.
This also doesn't make sense. Even if I used CryptoAPI, I'm still
relying on the underlying RSA technology. Since RSA still gets their 2%
from the sale of Windows -- RSA wins. Even if Windows goes away,
ultimately people would be building products that rely on RSA technology
-- not windows technology. (i.e. good for RSA). Now perhaps it would
be bad for the sale of BSAFE, but BSAFE is not a cash cow for RSA. In
fact, if I had to build a product around RSA technology, I would go with
BSAFE instead of CryptoAPI anyday -- mostly because BSAFE is available
for multiple platforms unlike CryptoAPI (WIN 95 & NT only) -- not to
mention Microsoft can make changes to CryptoAPI any time they want
too....At least BSAFE is market driven.
>
> As a result of this the discussion is on "what hooks are allowed that
> aren't crypto hooks as such but make crypto related extensions easier to
> add". Hence the talk of a protocol module API.
Thanks again, and I'll try to follow the threads on the protocol module
(although I'm still a little skeptical about this notion it seems to
just move the problem to a "MACRO" level and still doesn't address how
to minimize the number of source code trees and maximize exportablity --
but, I change my mind like a mother changes a baby -- "Many times
daily").
nicolas roumiantzeff
> Isn't crypto illegal in France anyway? In order to sell Communicator in
> France we were forced to build a special version that doesn't do S/MIME
> encrypted mail (weak SSL was acceptable, though).
>
> We've even been warned against carrying our personal S/MIME capable
> version of Communicator with us on laptops during business trips.
>
> -Dan Veditz
Correct...
Except that:
1) Crypto keys for authentication are not limited.
2) The French government (as well as other Europeean countries I suppose) has decided to allow escrowed keys of any length. (US government's dream is becoming a reallity here) :)
nicolas roumiantzeff <nico...@esker.fr>
Farrell McKay
> Bob Burns wrote:
>
> Are the restrictions regarding "hooks" layed out in documentation
> somewhere? NSA? Dept. of Commerce? etc.? If you could point me in
> their direction, I'd love to give them a read.
Hah hah! Ho ho! Stop it! You're making my sides split. Ow. :)
Seriously though, this is one of the many objections to the export
restrictions. There is no clear definition of a crypto "hook".
It is completely open to interpretation, and the U.S. Gov't can
make - and change - its interpretation to suit its tastes.
Farrell McKay
Tim Hudson
According to Farrell McKay:
> > Bob Burns wrote:
> > Are the restrictions regarding "hooks" layed out in documentation
> > somewhere? NSA? Dept. of Commerce? etc.? If you could point me in
> > their direction, I'd love to give them a read.
> Hah hah! Ho ho! Stop it! You're making my sides split. Ow. :)
My understanding is that a number of organisations and individuals have
been 'encouraged' to walk the safe side of an interpretation of "hooks" which
is an understandable approach to take.
In my opinion, software should be designed in a sufficiently modular
style so that "protocol" stacks can be dynamically plugged in and as new
application protocols arise they can be cleanly added into existing
code without custom work. This is simply good design.
I/O abstraction layers certainly make a lot of sense ... you want to have
a well setup system so that you can handle different communication mechanisms
(shock horror ... all the world might not be TCP/IP) and different event
handling models (yes ... X11 and Microsoft Windows and MacOS all do things
rather differently). If you design and implement a setup for taking code
cleanly across at least all these environments, nice things tend to happen
in that you end up with fairly clearly defined points at which you can
hook things. This is good design.
Exposing those points to external view however is something that is
actively discouraged ... however it is rather hard with a source code release
to prevent such things from happening.
The starting point for adding SSL into existing applications is to get
all the I/O through the one set of routines ... something which for some
strange reason I happen to know more than a little about doing :-)
Tim.
---
SSLeay and SSLapps FAQ - http://www.psy.uq.oz.au/~ftp/Crypto/
Ben Laurie
Tim Hudson wrote:
> The starting point for adding SSL into existing applications is to get
> all the I/O through the one set of routines ... something which for some
> strange reason I happen to know more than a little about doing :-)
Me, too! :-)
But adding crypto to Mozilla is about more than just SSL, of course, and
adding SSL is about more than I/O. For example, there's all that cert
management stuff, and the UI for it. All in all, its going to be a big
job, I fear.
That said, protocol abstraction is going to be an important component,
and probably is the thing we should address first.
I'm beginning to think we've beaten this subject to death though - until
we see the code, it is difficult to get much more specific than
"protocol abstraction would be a Good Thing".
What might be a more useful exercise while we wait for the big day is to
figure out who is going to do what. It seems I've foolishly volunteered
to host the mailing list, CVS tree and website. I was also planning to
do the initial I/O abstraction, and first cut SSL implantation, but it
sounds like Tim may want to do that (Tim?).
Since I seem to have the support of most of the interested parties, and
someone's gotta do it, I guess I'll be the "Benevolent Dictator" for
crypto. At least until someone deposes me :-)
Because I suspect that most people will be going for Unix as a dev
platform, but most users will be on Windoze, I'm also going to
masochistically opt for Windoze as my dev platform. I'd be interested to
hear what other people intend.
Other obvious stuff that needs looking at: cert management, PGP
integration, S/MIME, UI for everything. If there are people out there
looking for less technical things to do, my Webmaster would probably
appreciate help. There's also a need for people with access to every OS
under the sun to build binaries. Also, this stuff needs documenting, and
publicising (or at least, announcing!).
Hmmm ... that sounds like enough work for a small army, so I'll stop
there for now.
Dr Stephen Henson
Ben Laurie wrote:
>
>
> Other obvious stuff that needs looking at: cert management, PGP
> integration, S/MIME, UI for everything. If there are people out there
> looking for less technical things to do, my Webmaster would probably
> appreciate help. There's also a need for people with access to every OS
> under the sun to build binaries. Also, this stuff needs documenting, and
> publicising (or at least, announcing!).
>
OK while people are volunteering let me add my voice to a few things.
For me much depends on how I can get hold of the source. I don't have
the facilities to download the lot onto my hard disk in a reasonable
time so that may be delayed.
Naturally things I get paid for have to take priority.
However provisionally I could probably at least partially handle the
certificate stuff.
I have code that can read the current Netscape databases but to write to
them in a compatible way I'll need documentation on the bits I can't
guess. I would guess that the certificate database format needs at least
a bit of tweaking because it is currently vulnerable to dictionary
attacks on the password: yes I've reported this.
My now (in)famous PKCS#12 patch can be used in this area as well.
As for S/MIME I have code for SSLeay that will handle most of the stuff.
It can do sign and verify with both RSA and DSA keys and it can also
handle the enveloping modes (encrypt/decrypt). I haven't tried the RSA
S/MIME interop tests (yet) but it interops fine with both Netscape
Communicator and Outlook Express and yes it does handle the strong
crypto modes fine. So if/when the relevant "mail hook API" is present I
can probably have an S/MIME module ready to slot in.
Like most people I can also add semi-useless comments at strategic
points in the discussions.
Steve.
Farrell McKay
> > Other obvious stuff that needs looking at: cert management, PGP
> > integration, S/MIME, UI for everything. If there are people out there
> > looking for less technical things to do, my Webmaster would probably
> > appreciate help. There's also a need for people with access to every OS
> > under the sun to build binaries. Also, this stuff needs documenting, and
> > publicising (or at least, announcing!).
>
> OK while people are volunteering let me add my voice to a few things.
My turn!.....
I'm interested in just about every area of this effort. But if I had to
narrow things down, the guts of the engine (I/O, sockets, thread model,
event dispatching, modularization etc. etc.), and the GUI layer
would be the two most relevant areas to my background. I'm happy to work
in with the rest of the group. There is no point in duplicating work.
I agree that the GUI components ought to be done towards the end
of the pluggable-protocol work, once we have a better idea of what
shape it is going to take.
Bandwidth is no problem for me, and I have access to most of the mainstream
operating systems on which Communicator is shipped (which the exception of
PPC and 68k OSs at the moment).
In the non-technical area, I can assist with the web site in
the quiet moments.
> Like most people I can also add semi-useless comments at strategic
> points in the discussions.
Ditto. :)
Farrell McKay
Eric Young
On Tue, 24 Mar 1998, Farrell McKay wrote:
> I'm interested in just about every area of this effort. But if I had to
> narrow things down, the guts of the engine (I/O, sockets, thread model,
> event dispatching, modularization etc. etc.), and the GUI layer
> would be the two most relevant areas to my background. I'm happy to work
> in with the rest of the group. There is no point in duplicating work.
I will be interested to see what they have. I strongly suspect his part of
mozilla will need litle work. The model Tim and I have for various things is
an event driven engine with callbacks. I suspect Mozilla will be similar.
This model lets extra threads the thrown in with little programming effort. If
using a non-threading environment, this system also works very well with
non-blocking IO. It is easy to wrap the normal unix select(2) into an event
driven framework, so that the same programming model is present under unix and
Win16/Win32 (can we say WSAAsynchSelect() :-). Again, considering the
portability of Navigator, I suspect something like this will already be in
place. I will be interested to see :-).
I also would like to think that all IO is already going through 1 or 2 places.
How well they support a read that fails because of a non-blocking write
condition is an interesting question. I assume they do non-blocking connects
(which is reasonably evident) so it depends how this is implemented as to how
the SSL stuff can slip in for the non-blocking model. You will have noticed
that when accepting a certificate, the popup is non-blocking, the protocol has
stoped. More evidence (specifically for non-threaded environments) that the
non-blocking semantics are probably similar to what I'm used to. IE 3 used to
drop the connection, then do the popup, evidence that that SSL implementation
did not believe in being able to 'stop and resume' :-).
eric (doing more idle speculation about execution model of Mozilla :-).
Graham Leggett
Dr Stephen Henson wrote:
> It could be done but since such a beast would not talk to most servers
> and not work with most CAs and wouldn't support S/MIME (which requires
> mandatory RC2-40 and RSA in one standard) it wouldn't be much use at
> present.
I was under the impression that S/MIME was an open standard - this would
mean that a requirement inside an open standard was that you had to use
a patented/restricted component.
This is a bit self defeating, or am I missing something here?
Regards,
Graham
--
-----------------------------------------
gra...@vwv.com "There's a moon
VWV Interactive over Bourbon Street
tonight...
Jamie Zawinski
Graham Leggett wrote:
>
> I was under the impression that S/MIME was an open standard - this would
> mean that a requirement inside an open standard was that you had to use
> a patented/restricted component.
>
> This is a bit self defeating, or am I missing something here?
I believe that later versions of the S/MIME draft no longer require RSA.
--
Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
Dr Stephen Henson
Jamie Zawinski wrote:
>
> I believe that later versions of the S/MIME draft no longer require RSA.
>
Indeed they don't. v3 S/MIME draft only says RSA SHOULD be supported. It
says that DH and DSA MUST be supported which offers an alternative.
Similarly it also says the 3DES MUST be supported but RC2-40 SHOULD be
supported. Bit of a headache that for US exporters.
Unfortunately for backwards compatability it is not really practicable
not to support RSA for a while anyway. There are a hell of a lot of RSA
certificates out there and not many DSA ones (not to mention DH).
Graham Leggett
Pete Chown wrote:
> Another alternative, which would be much nicer is to split crypto off
> into a separate library. However, we are then into the issue of
> whether Netscape is being exported with cryptographic hooks. The key
> would be to make the interfaces high enough level so that they are not
> specifically for crypto. What do we need...?
Not having seen the source yet, what I'm suggesting may have already be
done. Still, FWIW:
The communication backend of NS5 should be a modular affair, implemented
perhaps with the same plugins system that exists now.
Basically we have an API that performs the function "get me a document,
from wherever" - the higher level stuff calls this API with a URL (plus
any other args), and the API returns the document.
What happens inside the API is that the URL is parsed to check where it
should come from, and handler "plugins" are scanned (the same way Apache
modules work) to see if one should pick it up.
In a typical senario:
- The higher level stuff asks the API for an URL
- First off, the "cache" plugin (which is tagged to look for http, ftp,
and https files) is run to see if the document is already in the cache.
- If not, then the http plugin checks if it's http. If so, it's
downloaded, if not...
- Check ftp, send it to the ftp plugin...
- Check mailto:, send it to the mailto plugin (which doesn't return any
data)
- etc etc.
- Check mail: (or whatever it's called) to pull a mail message from the
local mailboxes.
- Check news: to fetch a news message from the local news servers.
- Check PGP plugin (which looks out for mail: and news: types) to do any
verification/decryption on a message.
- Same for S/MIME, etc etc.
To implement functions such as viewing certificates, etc a function
could be exposed that implements a "properties" function. When Edit ->
Preferences is called, the plugins have the opportunity to add functions
to the toolbar on the left, and have the opportunity to generate and act
on html pages to the right. This way, plugins can be kept pretty much
platform independant as well.
What I'm getting at is that the browser type "https" can just be another
plugin - most probably written outside the US, the plugin in reality
being just a wrapper for SSLeay and the http plugin.
For those only interested in downloading a complete NS5 internationally,
they download NS5 from the states, and then download the security
plugins from elsewhere.
Any more ideas?
Graham Leggett
Ben Laurie wrote:
> But adding crypto to Mozilla is about more than just SSL, of course, and
> adding SSL is about more than I/O. For example, there's all that cert
> management stuff, and the UI for it. All in all, its going to be a big
> job, I fear.
The security properties dialog is already HTML (it seems to act like a
webpage to an extent).
The actual properties functions of any part of the system can be exposed
as a "browser/server" style interface - abstracting this completely.
Workable?
G. Sumner Hayes
Dr Stephen Henson wrote:
>
> Unfortunately for backwards compatability it is not really practicable
> not to support RSA for a while anyway.
What a bizarre situation this is. We have to support RSA in the short
term in order to interoperate with others. We could phase it out in a
few years, but the RSA patent expires 20 Sep. 2000, making it not really
worth the effort.
Hopefully people will refrain from using patented algorithms in open
standards in the future so we can avoid this sort of scenario.
Anyone know when the IDEA patent expires in the U.S.?
-Sumner
--
rage, rage against the dying of the light
Eric Young
On Fri, 3 Apr 1998, G. Sumner Hayes wrote:
> What a bizarre situation this is. We have to support RSA in the short
> term in order to interoperate with others. We could phase it out in a
> few years, but the RSA patent expires 20 Sep. 2000, making it not really
> worth the effort.
The other problem is that RSA does actually make more sense than some of the
other algorithms for certificates because while signing is expensive,
verification screams compaired to just about all other PK algorithms I know
of. What do we do more of in PKI?
> Hopefully people will refrain from using patented algorithms in open
> standards in the future so we can avoid this sort of scenario.
The IETF seems to be doing a very good job of this. To implement TLS, you
HAVE to implement Ephemeral DH with DSA and Triple-DES.
For the most recent S/MIME standard, I belive this has also been done.
> Anyone know when the IDEA patent expires in the U.S.?
Consider not using IDEA. Nortel are doing the right thing with CAST, it is
avaialble under DES type conditions. (Blowfish has some key setup time
hassles for thinks like SSL, but this does not affect it for S/MIME).
Obviously there are issues like academic scurutiny of new block ciphers (since
everyone and their dog has their favorite).
eric
Dr Stephen Henson
G. Sumner Hayes wrote:
>
> Dr Stephen Henson wrote:
> >
> > Unfortunately for backwards compatability it is not really practicable
> > not to support RSA for a while anyway.
>
> term in order to interoperate with others. We could phase it out in a
> few years, but the RSA patent expires 20 Sep. 2000, making it not really
> worth the effort.
>
Yes very silly. Of course it is pure coincidence that these standards
are on www.rsa.com...
> Hopefully people will refrain from using patented algorithms in open
> standards in the future so we can avoid this sort of scenario.
>
The trouble with many "open" standards is that they refer either
directly or indirectly to "closed" standards. That is hard to get
documents that are either in permanent state of revision and/or cost $$$
to obtain.
Almost all the standards refer to ASN1 in one form or another. What
people frequently go by is the "laymans guide" on www.rsa.com. Where it
is incomplete they either guess or follow what someone else has done
(who probably guessed too).
As a result all manner of incorrect stuff is out there. For example
there are very few X509 certificates that are correct in all respects,
and even if they were they would probably break existing
implementations.
Even when the specs are plain to see they can get ignored. To give an
example one big name CA is distributing S/MIME certificates without the
S/MIME bit set in netscape-certificate-type. If you follow the specs you
conclude that the certificates can't be used for S/MIME. The same CA is
issuing webpass certificates (SSL Client only) without the SSL client
bit set but with the SSL Client CA bit set...
So if the crypto effort followed the specs to the letter it would break
lots of certificates...