Re: browser vendors and CAs agreeing on high-assurance certificat es

2006-01-06 Thread Ben Laurie
Bill Frantz wrote:
 On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote:
 
 I don't see why not - the technical details actually matter. Since the
 servers will all share a socket, on any normal architecture, they'll all
 have access to everyone's private keys. So, what is gained by having
 separate certs?
 
 I responded in private email:
 
 With a POLA architecture, perhaps on a capability OS (dream, dream),
 they might not share access to the private keys.  However, given current
 software, I grant your point.
 
 Ben responded that I should post my comments to the list.
 
 There are two scenarios I see as being viable for separating the private
 keys with a security barrier.  One is the single machine case alluded to
 above.  Here the private keys would be in separate security domains, and
 the common part of the web server, which listens on the socket, would
 read the initial data on the TCP connection, select the correct security
 domain, and pass the connection to that domain. While the common part
 could continue to examine all the data, those data would be encrypted,
 so the it would have the same access as any other untrusted node in the
 path.
 
 The other scenario involves a network switch which performs the function
 of the common code of the web server.  It uses network address
 translation to forward the connection's packets to the back-end computer
 with the correct private key.  Here the keys are protected by being kept
 on separate computers.

This would defeat the reason people share IP addresses, which is so they
can share a single machine to reduce costs. Of course, a capability OS
would permit this whilst separating keys, as you said.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-27 Thread Ian G

Ben Laurie wrote:

Ian G wrote:

...

http://wiki.cacert.org/wiki/VhostTaskForce



(The big problem of course is that you can use
one cert to describe many domains only if they
are the same administrative entity.)



If they share an IP address (which they must, otherwise there's no
problem), then they must share a webserver, which means they can share a
cert, surely?


Certainly they *can* share a cert.  But a cert
speaks to identity - at the human level the cert
is supposed to (by some readings) indicate who
the site is purporting to be and in some scenarios,
there are people who think the cert actually
proves that the site is who it claims to be.

So regardless of the technical details of the
underlying software (complex, I grant), websites
SHOULD NOT share a cert.

(by capitals I mean the RFC sense, not the shouting
sense.)



What we really need is for the webservers to
implement the TLS extension which I think is
called server name indication.

And we need SSL v2 to die so it doesn't interfere
with the above.



Actually, you just disable it in the server. I don't see why we need
anything more than that.


If browsers don't know what is available on the
server, they send a Hello message that asks for
what protocol versions and ciphersuites to use.
This is the SSL v2 message, just in case so
to rectify this situation we need to get all
the browsers distro'd with SSL v2 turned off by
default.  The shorthand for this is SSL v2 must
die...  Thankfully, they did decide to do just
that at last month's browser pow-wow.

iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-27 Thread Ben Laurie
Eric Rescorla wrote:
 Ben Laurie [EMAIL PROTECTED] writes:
 And we need SSL v2 to die so it doesn't interfere
 with the above.
 Actually, you just disable it in the server. I don't see why we need
 anything more than that.
 
 The problem is that the ServerHostName extension that signals
 which host the client is trying to contact is only available
 in the TLS ClientHello.

Sure, but if the server won't negotiate SSL 2, why is this a problem?
-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-27 Thread Ben Laurie
Ian G wrote:
 Ben Laurie wrote:
 Ian G wrote:
 ...
 http://wiki.cacert.org/wiki/VhostTaskForce
 
 (The big problem of course is that you can use
 one cert to describe many domains only if they
 are the same administrative entity.)


 If they share an IP address (which they must, otherwise there's no
 problem), then they must share a webserver, which means they can share a
 cert, surely?
 
 Certainly they *can* share a cert.  But a cert
 speaks to identity - at the human level the cert
 is supposed to (by some readings) indicate who
 the site is purporting to be and in some scenarios,
 there are people who think the cert actually
 proves that the site is who it claims to be.
 
 So regardless of the technical details of the
 underlying software (complex, I grant), websites
 SHOULD NOT share a cert.

I don't see why not - the technical details actually matter. Since the
servers will all share a socket, on any normal architecture, they'll all
have access to everyone's private keys. So, what is gained by having
separate certs?

I do agree that the process by which the additional names get added to
the main cert needs to reflect ownership of the name, but that's a
different matter.

And I'm not claiming, btw, that this mechanism is better than the server
name extension. However, I don't believe its as broken as some are claiming.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-27 Thread Ian G

Ben Laurie wrote:

Ian G wrote:



http://wiki.cacert.org/wiki/VhostTaskForce



(The big problem of course is that you can use
one cert to describe many domains only if they
are the same administrative entity.)



If they share an IP address (which they must, otherwise there's no
problem), then they must share a webserver, which means they can share a
cert, surely?


Certainly they *can* share a cert.  But a cert
speaks to identity - at the human level the cert
is supposed to (by some readings) indicate who
the site is purporting to be and in some scenarios,
there are people who think the cert actually
proves that the site is who it claims to be.

So regardless of the technical details of the
underlying software (complex, I grant), websites
SHOULD NOT share a cert.



I don't see why not - the technical details actually matter. Since the
servers will all share a socket, on any normal architecture, they'll all
have access to everyone's private keys. So, what is gained by having
separate certs?


1. Because the activity is being done in the name
of the site.  When a business signs or otherwise
represents a site as purporting to be in the name of
some business, we still want to do it in a way that
separates out that business from every other.

2. The system operator has access to the private
keys, yes, but he's just the agent, and this does
not mean that anyone else has access.  We have
systems in place to separate out the protection
of the keys from the rest of the business.

Most small businesses have some level of cooperation
where they share techies, systems, and other services,
so it is probably more seen and more useful in the
SOHO (small office home office) world.  Of course,
this is less interesting to the security world,
because there isn't the money to pay for consultants
there...

All the more reason why the software should provide
the best it can for free!


I do agree that the process by which the additional names get added to
the main cert needs to reflect ownership of the name, but that's a
different matter.

And I'm not claiming, btw, that this mechanism is better than the server
name extension. However, I don't believe its as broken as some are claiming.


Well, sure.  For many uses it will be a useful
stopgap measure, until SNI is deployed.  It's
only broken if you like a binary world, and you
happen to fall on the zero side of the question.

iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-24 Thread Ben Laurie
Ian G wrote:
 
 BTW, illustrating points made here, the cert is for
 financialcryptography.com
 but your link was to www.financialcryptography.com.  So of course Firefox
 generated a warning
 
 Indeed and even if that gets fixed we still have
 to contend with:
 
   * the blog software can't handle the nature of a
 TLS site (internal problems like non-working
 trackbacks, internal links, posts, ...)
   * the cert has to be shared with 3 other sites
   * Firefox will still warn about it being a CAcert
 signed certificate
   * ...  I'm sure there's more.
 
 Hopefully over the next year, the webserver (Apache)
 will be capable of doing the TLS extension for sharing
 certs so then it will be reasonable to upgrade.

In fact, I'm told (I'll dig up the reference) that there's an X509v3
extension that allows you to specify alternate names in the certificate.
I'm also told that pretty much every browser supports it.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-24 Thread Ian G

Ben Laurie wrote:
...

Hopefully over the next year, the webserver (Apache)
will be capable of doing the TLS extension for sharing
certs so then it will be reasonable to upgrade.



In fact, I'm told (I'll dig up the reference) that there's an X509v3
extension that allows you to specify alternate names in the certificate.
I'm also told that pretty much every browser supports it.


The best info I know of on the subject is here:

http://wiki.cacert.org/wiki/VhostTaskForce

Philipp has a script which he claims automates
the best method(s) described within to create
the alt-names cert.

(The big problem of course is that you can use
one cert to describe many domains only if they
are the same administrative entity.)

What we really need is for the webservers to
implement the TLS extension which I think is
called server name indication.

And we need SSL v2 to die so it doesn't interfere
with the above.

iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-24 Thread Ben Laurie
Ian G wrote:
 Ben Laurie wrote:
 ...
 Hopefully over the next year, the webserver (Apache)
 will be capable of doing the TLS extension for sharing
 certs so then it will be reasonable to upgrade.


 In fact, I'm told (I'll dig up the reference) that there's an X509v3
 extension that allows you to specify alternate names in the certificate.
 I'm also told that pretty much every browser supports it.
 
 The best info I know of on the subject is here:
 
 http://wiki.cacert.org/wiki/VhostTaskForce
 
 Philipp has a script which he claims automates
 the best method(s) described within to create
 the alt-names cert.
 
 (The big problem of course is that you can use
 one cert to describe many domains only if they
 are the same administrative entity.)

If they share an IP address (which they must, otherwise there's no
problem), then they must share a webserver, which means they can share a
cert, surely?

 What we really need is for the webservers to
 implement the TLS extension which I think is
 called server name indication.
 
 And we need SSL v2 to die so it doesn't interfere
 with the above.

Actually, you just disable it in the server. I don't see why we need
anything more than that.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-24 Thread Anne Lynn Wheeler
Ben Laurie wrote:
 If they share an IP address (which they must, otherwise there's no
 problem), then they must share a webserver, which means they can share a
 cert, surely?

this is a semantic nit ... certs are typically distributed openly and
freely ... so potentially everybody in the world has free access to the
same cert.

what operations need is the same access to a high-assurance private key.
given that there is access to a high-assurance private key ... then it
is possible to scaffold various other operations. some of the issues
surrounding private key high-assurance may preclude having replicated
private keys, restricting use to a single physical entity.

over ten years ago ... i helped a small isp set up a single server to
host a larger number of different email domains ... which required doing
several hacks/enhancements to sendmail.

the early onset of some of the leading search engines started out with
multiple-A records for load balancing and availability (i.e. dns having
single host/domain name with a list of different ip-addresses) ... where
they rotated the ip-addresses in the list. as their traffic ramped up,
this wasn't sufficient ... in part because the ip-address lists got
cached in a large number of different places ... as static lists. this
resulted in the evolution of boundary routers that responded to the set
of published ip-addresses and internally kept track of activity to
backend servers ... and dynamically spread the load across an
increasing/growing number of backends.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-24 Thread Eric Rescorla
Ben Laurie [EMAIL PROTECTED] writes:

 Ian G wrote:
 Ben Laurie wrote:
 ...
 Hopefully over the next year, the webserver (Apache)
 will be capable of doing the TLS extension for sharing
 certs so then it will be reasonable to upgrade.


 In fact, I'm told (I'll dig up the reference) that there's an X509v3
 extension that allows you to specify alternate names in the certificate.
 I'm also told that pretty much every browser supports it.
 
 The best info I know of on the subject is here:
 
 http://wiki.cacert.org/wiki/VhostTaskForce
 
 Philipp has a script which he claims automates
 the best method(s) described within to create
 the alt-names cert.
 
 (The big problem of course is that you can use
 one cert to describe many domains only if they
 are the same administrative entity.)

 If they share an IP address (which they must, otherwise there's no
 problem), then they must share a webserver, which means they can share a
 cert, surely?

Actually, the big problem if you run a virtual hosting server
is that every time you add a new virtual domain you need a new
cert with that domain in it. And that applies even if you put
all the names in one cert.

Really, the ServerHostName extension is better.


 What we really need is for the webservers to
 implement the TLS extension which I think is
 called server name indication.
 
 And we need SSL v2 to die so it doesn't interfere
 with the above.

 Actually, you just disable it in the server. I don't see why we need
 anything more than that.

The problem is that the ServerHostName extension that signals
which host the client is trying to contact is only available
in the TLS ClientHello.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-23 Thread leichter_jerrold
| | But is what they are doing wrong?
| | 
| | The users?  No, not really, in that given the extensive conditioning
that
| | they've been subject to, they're doing the logical thing, which is not
paying
| | any attention to certificates.  That's why I've been taking the
(apparently
| | somewhat radical) view that PKI in browsers is a lost cause - apart from
a
| | minute segment of hardcore geeks, neither users nor web site admins
either
| | understand it or care about it, and no amount of frantic turd polishing
will
| | save us any more because it's about ten years too late for that - this
| | approach has been about as effective as Just say no has for STD's and
drugs.
| | That's why I've been advocating alternative measures like mutual
challenge-
| | response authentication, it's definitely still got its problems but it's
| | nothing like the mess we're in at the moment.  PKI in browsers has had
10
| | years to start working and has failed completely, how many more years
are we
| | going to keep diligently polishing away before we start looking at
alternative
| | approaches?
| I agreed with your analysis when I read it - and then went on to my next
mail 
| message, also from you, which refers to your retrospective on the year and
had 
| a pointer to an page at financialcryptography.  So ... I try to download
the 
| page - using my trusty Netscape 3.01, which with tons of things turned off

| (Java, Javascript, background images, autoloading of images) remains my 
| work-a-day browser, giving decent performance on an old Sun box.
| 
| Well, guess what:
| 
|   Netscape and this server cannot communicate securely
|   because they have no common cryptographic algorithm(s).
| 
| So ... we have the worst possible combination:  A system that doesn't
work,
| which is forced on you even when you don't care about it (I can live with
| the possibility that someone will do a MITM attack on my attempt to read
your 
| article).
| 
| Sigh.
BTW, illustrating points made here, the cert is for
financialcryptography.com
but your link was to www.financialcryptography.com.  So of course Firefox
generated a warning
-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-23 Thread Ian G



BTW, illustrating points made here, the cert is for
financialcryptography.com
but your link was to www.financialcryptography.com.  So of course Firefox
generated a warning


Indeed and even if that gets fixed we still have
to contend with:

  * the blog software can't handle the nature of a
TLS site (internal problems like non-working
trackbacks, internal links, posts, ...)
  * the cert has to be shared with 3 other sites
  * Firefox will still warn about it being a CAcert
signed certificate
  * ...  I'm sure there's more.

Hopefully over the next year, the webserver (Apache)
will be capable of doing the TLS extension for sharing
certs so then it will be reasonable to upgrade.

iang

PS:  SSL v2 must die!  Wot, you mean you haven't
turned it off in your browser yet?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-21 Thread leichter_jerrold
|  Imagine a E-commerce front end:  Instead of little-guy.com buying a
cert
|  which you are supposed to trust, they go to e-commerce.com and pay for a
|  link.  Everyone trusts e-commerce.com and its cert.  e-commerce provides
a
|  guarantee of some sort to customers who go through it, and charges the
|  little guys for the right.
| 
| Do you mean like Amazon Marketplace and Amazon zShops? I think it's been
| done already:
| 
| http://www.amazon.com/exec/obidos/tg/browse/-/1161232/103-4791981-1614232
Well, yes, and eBay provides the same service.  But how much protection are
they providing for buyers?  I think Amazon will cover the first $100 a
customer paid.  eBay gives you a bit of protection if you go with PayPal,
but not a whole load - they rely on their reputation system.

e-commerce.com would bring up a page saying:  We guarantee that
transactions
up to $nnn with this site will be to your satisfaction or your money back.
The merchant would specify the maximum dollar value, and pay e-commerce.com
based on the limit and, presumably, his reputation with e-commerce.  (This 
is one way it might be set up - there are certainly other ways.  And, even
in this style, the entire wording of the guarantee would be something agreed
upon between the seller and e-commerce.

-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-18 Thread leichter_jerrold
| 2) the vast majority of e-commerce sites did very few number of
| transactions each. this was the market segment involving e-commerce
| sites that aren't widely known and/or represents first time business. it
| is this market segment that is in the most need of trust establishment;
| however, it is this market segment that has the lowest revenue flow to
| cover the cost of creating a trust value.
...which raises the interesting question of whether there is a role here for
banks in their traditional role:  As introducers and trusted third parties.
Imagine a E-commerce front end:  Instead of little-guy.com buying a cert
which you are supposed to trust, they go to e-commerce.com and pay for a
link.  Everyone trusts e-commerce.com and its cert.  e-commerce provides a
guarantee of some sort to customers who go through it, and charges the
little
guys for the right.

| there is actually a third issue for the vast numbers of low traffic
| e-commerce merchants ... the lack of trust can be offset by risk
| mitigation. it turns out that this market segment where there is
| poissble litte reason for the customer to trust the merchant has had a
| trust issues predating the internet ... at least going back to the
| introduction of credit financial transactions. as opposed to trust, risk
| mitigation was addressed in this period with things like reg-e and the
| customer having a high level of confidence that disputes tended to
| heavily favor the customer. this characteristics of risk mitigation, in
| lieu of trust, then carried over into the internet e-commerce relm.
Yup.  This is the role E-commerce.com would play.

Since e-commerce.com would actually be present in the transaction - as
opposed
to a distant cert authority - in principle it could charge in a way that
made
sense.  If it's mitigating risk, the cost should be proportional to the risk
-
i.e., the size of the transaction and what e-commerce knows about little-guy
and its history.
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-18 Thread Sidney Markowitz
On 12/19/05 9:54 AM, [EMAIL PROTECTED] wrote:
 Imagine a E-commerce front end:  Instead of little-guy.com buying a cert
 which you are supposed to trust, they go to e-commerce.com and pay for a
 link.  Everyone trusts e-commerce.com and its cert.  e-commerce provides a
 guarantee of some sort to customers who go through it, and charges the
 little guys for the right.

Do you mean like Amazon Marketplace and Amazon zShops? I think it's been
done already:

http://www.amazon.com/exec/obidos/tg/browse/-/1161232/103-4791981-1614232

 -- Sidney Markowitz
http://www.sidney.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]