* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
On Sat, 31 Aug 2002, Brian May wrote:
(note that I really like this realiance on checking the hostname, for
instance it doesn't work properly with virtual name domains under https,
but it somehow seems to have become the defacto
Hi Stephen!
On Mon, 02 Sep 2002, Stephen Frost wrote:
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
On Sat, 31 Aug 2002, Brian May wrote:
(note that I really like this realiance on checking the hostname, for
instance it doesn't work properly with virtual name domains under
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
On Mon, 02 Sep 2002, Stephen Frost wrote:
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
On Sat, 31 Aug 2002, Brian May wrote:
(note that I really like this realiance on checking the hostname, for
instance it doesn't
Hi Stephen!
On Mon, 02 Sep 2002, Stephen Frost wrote:
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
On Mon, 02 Sep 2002, Stephen Frost wrote:
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
On Sat, 31 Aug 2002, Brian May wrote:
(note that I really like this
On Mon, Sep 02, 2002 at 02:22:52PM -0300, Henrique de Moraes Holschuh wrote:
I would think most places want their own cert and not to share with
other, probably totally unrelated, people.
For that, you need a specification that allows you to send a number of certs
(instead of only one) and
On Mon, Sep 02, 2002 at 10:10:07PM +0200, Richard Braakman wrote:
[on TLS]
If you're going to tinker with the specification anyway, I would
suggest one where the client states up front whose certificate it wants.
Such the Server Name Indication mechanism described in:
On Sat, Aug 31, 2002 at 12:18:04AM +0100, Andrew McDonald wrote:
Even the hostname check can be problematic - does the user really need
to accept the certificate every time because the name doesn't match?
I think the issue is this: if no hostname check is done, how to you know
you really are
On Sat, 31 Aug 2002, Brian May wrote:
On Sat, Aug 31, 2002 at 12:18:04AM +0100, Andrew McDonald wrote:
Even the hostname check can be problematic - does the user really need
to accept the certificate every time because the name doesn't match?
I think the issue is this: if no hostname check
On Fri, Aug 30, 2002 at 12:40:11AM +0200,
Henrique de Moraes Holschuh wrote:
Right now, every TLS-enabled package tries to screw it up in new and
never-before-tried ways.
One commonly missing feature is that the certificate should contain a
subjectAltName extension of type dNSName containing
On Fri, Aug 30, 2002 at 06:58:00PM +0100, Andrew McDonald wrote:
On a similar subject, there seem to be more than a few applications
that have had SSL/TLS support added, but don't do any hostname
checking against the certificate - leaving you open to
man-in-the-middle attacks.
(speaking as an
On Fri, Aug 30, 2002 at 02:57:12PM -0700, Neil Spring wrote:
On Fri, Aug 30, 2002 at 06:58:00PM +0100, Andrew McDonald wrote:
On a similar subject, there seem to be more than a few applications
that have had SSL/TLS support added, but don't do any hostname
checking against the certificate -
Hi *,
Now that the LDAP packages support TLS I would like to do the next
step: Get a sane debconf interface on first installation to setup
the directory and generate the TLS key and certificate.
But now I wonder if there is some established procedure for doing
so. I know many users will not
On Fri, 30 Aug 2002, Torsten Landschoff wrote:
But now I wonder if there is some established procedure for doing
so. I know many users will not have a key signed by verisign or
Nope. We should do so, and have it added to the ca-certificates package I
think.
Right now, every TLS-enabled
On Thu, Aug 29, 2002 at 07:39:37PM -0300, Henrique de Moraes Holschuh wrote:
Nope. We should do so, and have it added to the ca-certificates package I
think.
Right now, every TLS-enabled package tries to screw it up in new and
never-before-tried ways.
So it is okay if I do the same?
14 matches
Mail list logo
