On Tue, Nov 08, 2005 at 12:46:18PM +, Nick Kew wrote:
On Tuesday 08 November 2005 12:02, Brian Candler wrote:
[twice - please don't]
Not sure what you mean by that. I probably did a group reply, so you got one
copy directly and one via the list. I'm afraid it's impossible to please
-Original Message-
From: Nick Kew [mailto:[EMAIL PROTECTED]
... Personally, I feel this role belongs in the government.
Any particular government? A few years ago I'd probably have agreed.
With the most blatently corrupt government in living memory, that has
less appeal.
At
Exactly. It doesn't matter where you live and what government you live
under, they issue you some form(s) of identification. A digital
certificate is simply a digital form of identification. Why should the
government keep using ink and paper documents for identification when
digital ones
either for malicious or good use.
Peter
-Original Message-
From: Brian Candler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 09, 2005 2:22 AM
To: Nick Kew
Cc: dev@httpd.apache.org
Subject: Re: pgp trust for https?
On Tue, Nov 08, 2005 at 12:46:18PM +, Nick Kew wrote
Peter J. Cranstone wrote:
Currently Windows, Linux and Unix only use two levels of privilege - Ring 3
and Ring 0. Everybody and there uncle's code want to run at Ring 0. Another
really bad idea, as once I introduce a network/video/keyboard/whatever
driver at that level I can execute malicious
: Paul A Houle [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 09, 2005 1:07 PM
To: dev@httpd.apache.org
Subject: Re: pgp trust for https?
Peter J. Cranstone wrote:
Currently Windows, Linux and Unix only use two levels of privilege - Ring 3
and Ring 0. Everybody and there uncle's code want
.
Peter
[EMAIL PROTECTED]
-Original Message-
From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 09, 2005 1:12 PM
To: dev@httpd.apache.org
Subject: RE: pgp trust for https?
No problem - Itanium has the architecture you need. You can isolate all the
physical memory
Folks, somehow this thread diverged from HTTP/1.1 PGP based TLS mechanisms
into a fun-with-hardware-trust thread.
Please take this discussion to an appropriate security-wonk debating
club forum, such as vuln-dev or bugtraq, as it's all entirely off topic
on this forum.
Yours,
Bill
Aw shucks... dad... you never let us have any fun.
ROFL
Kevin
Hmmm... HTTP/1.1 PGP based TLS mechanisms under Itanium?
Interesting ( and OT ).
In a message dated 11/9/2005 2:45:13 PM Central Standard Time, [EMAIL PROTECTED] writes:
Folks, somehow this thread diverged from HTTP/1.1 PGP based
and the debate around compressing data from
a web server. LOL.
Peter
[EMAIL PROTECTED]
-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 09, 2005 1:43 PM
To: dev@httpd.apache.org
Subject: Re: pgp trust for https?
Folks, somehow this thread diverged
Peter J. Cranstone wrote:
But seriously though, Apache now has 70% of the Internet web servers running
it's software. The single most important thing on IT minds is web services
followed by security.
Yup. Apache takes a wee bit of pride that it comes up so infrequently on
bugtraq, and hides
discussing the ( Thread title ) "pgp trust for https".
I am not affiliated with any company that directly manufactures or
ships Itanium products... but I happen to have 2 or 3 of the beasties
here and Peter is right... the answers to most people's well-worn
arguments about how you ca
[EMAIL PROTECTED] wrote:
I am not affiliated with any company that directly manufactures or
ships Itanium products... but I happen to have 2 or 3 of the beasties
here and Peter is right... the answers to most people's well-worn
arguments about how you can't secure an OS are now laying right
on
On Tue, Nov 08, 2005 at 12:02:03PM +, Brian Candler wrote:
The attacker doesn't have your private key, so they would create their own
key pair. As a result, the connecting client would see a *different* key
than the one they would see if they connect to your server directly. The
problem
On Tuesday 08 November 2005 12:02, Brian Candler wrote:
[twice - please don't]
On Sun, Nov 06, 2005 at 10:19:25PM +, Nick Kew wrote:
I'll sign my server. Same as I'll sign an httpd tarball if I roll one
for public consumption. You sign your server. Where's the problem?
The problem
Nick Kew wrote:
Why would anyone have to do that? I'll trust a server as much as I trust
the PGP key of the person who signed it. That's the same as trusting
an httpd download because it's signed by someone whose key I trust.
The question then is who is going to sign? You seem to be
On Sunday 06 November 2005 21:41, Phillip Susi wrote:
Nick Kew wrote:
Why would anyone have to do that? I'll trust a server as much as I trust
the PGP key of the person who signed it. That's the same as trusting
an httpd download because it's signed by someone whose key I trust.
The
Personally, I feel this role belongs in the government.
Whose government? I don't even trust my own government, so why should I trust
a foreign government?
Joost
It is a little unclear to me about the combination of security and efficiency that we can achieve by using PGP keys and the web-of-trust on the web. Imagine connecting to you bank or online stock broker. If they would certify themselves using PGP certificates, they will need to have a large number
Nick Kew wrote:
Huh? The same person who installs the cert now. It's just a different
signature. And for those who want a certificate authority, have such
authorities (the more the better) sign *their* PGP keys.
>From whomsoever is responsible for it. Maybe even more than one
We have grown accustomed to two separate trust mechanisms
on the 'net; server certs signed by some authority, or the PGP
web of trust.
I would like to be able to use PGP trust over the web. That would
mean (something like) installing a certificate on the server, and
signing it with my PGP key.
Nick Kew wrote:
We have grown accustomed to two separate trust mechanisms
on the 'net; server certs signed by some authority, or the PGP
web of trust.
I would like to be able to use PGP trust over the web. That would
mean (something like) installing a certificate on the server, and
To add a bit more detail to Ben's mail, OpenPGP:SDK is a new open
source library, available under a Apache-style license. It's a
completely new implementation of the OpenPGP spec, and is available at
http://openpgp.nominet.org.uk.
At EuroOSCon, we discussed a number of applications which could be
The big reason that comes to my mind is that users don't want to have to
implicitly trust the server from the start, then register on the site by
uploading their own key before secure communications can begin.
The big advantage of a public certificate infrastructure is that the
rest of us can
On Saturday 05 November 2005 23:28, Phillip Susi wrote:
The big reason that comes to my mind is that users don't want to have to
implicitly trust the server from the start, then register on the site by
uploading their own key before secure communications can begin.
Why would anyone have to do
25 matches
Mail list logo