I see your point. But I suspect it illustrates a significant
limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
that an IP address and port number are used by only one named service.
It's been awhile since I looked at the TLS protocol but I don't recall
any way for the
I see your point. But I suspect it illustrates a significant
limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
that an IP address and port number are used by only one named service.
It's been awhile since I looked at the TLS protocol but I don't recall
any way for the
On Wed, Mar 05, 2003 04:39:51PM -0600, Spencer Dawkins allegedly wrote:
So I'm wondering why, if we're all individuals at the IETF,
Company is a required field on the registration form?
I like to use that space to acknowledge the organization who paid for my
trip. I've also used it for my
Oh, I'm not being clear enough - I understand why Company
APPEARS
(distinguish between common names, acknowledge sponsors, etc.).
I'm wondering why it's REQUIRED, especially since it seems to
gather single-spaces, home town names, and Lumberjack.
Spencer
--- Scott W Brim [EMAIL PROTECTED]
On Tue, 11 Mar 2003 15:42:00 -0500
John Stracke [EMAIL PROTECTED] wrote:
Perhaps the notion of a well known port is a concept whose time has
passed. At least for connection oriented protocols, doing away with
well known ports might have some good properties for some basic
On Sat, 8 Mar 2003 [EMAIL PROTECTED] wrote:
On Sat, 08 Mar 2003 01:16:48 EST, shogunx said:
Cant you just type ftp at a unix shell?
Or use one of the 3D or X11 ftp clients available for the 3D user
interface for linux?
3D? Where? ;)
www.3dwm.org
AND
www.fresco.org
Scott
/Valdis
Hi .. I am setting up an exchange server with webshield installed... While
setting up the virus scanner, I was recommended (by microsoft) to block .p7s
attachments.
Since those are certificate files, I am wondering what is the danger, and
I'd like to know if anyone here could bring me some
They never respond to my emails !
( No I'm not going to place a service call for that )
Michael
- Original Message -
From: Lars Eggert [EMAIL PROTECTED]
To: Michael [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 4:20 PM
Subject: Re: .p7s attachment
Michael
Michael wrote:
Hi .. I am setting up an exchange server with webshield installed... While
setting up the virus scanner, I was recommended (by microsoft) to block .p7s
attachments.
Since those are certificate files, I am wondering what is the danger, and
I'd like to know if anyone here could bring
Yes, this is true in theory, but I want to know how you're going
to get VeriSign to issue you a certificate with subjectAltNames
corresponding to a bunch of unrelated domains. And remember
that ever time the ISP gets a new customer they have to get a new
cert from VeriSign with yet another
On Wed, 12 Mar 2003 15:37:23 MST, Doug Royer [EMAIL PROTECTED] said:
If you are talking about TLS certs (not S/MIME certs) then the ISP can
issue them to the customer directly (be a CA for connections from their
customers over TLS connections). I have read that the customer can be
given
[EMAIL PROTECTED] wrote:
On Wed, 12 Mar 2003 15:37:23 MST, Doug Royer [EMAIL PROTECTED] said:
If you are talking about TLS certs (not S/MIME certs) then the ISP can
issue them to the customer directly (be a CA for connections from their
customers over TLS connections). I have read that the
Not quite inherent -- if you verify against a SubjectAltName dNSName
you can decide the certificate is valid for many domains.
Yes, this is true in theory, but I want to know how you're going
to get VeriSign to issue you a certificate with subjectAltNames
corresponding to a bunch of
This thread is trying to redefine or redesign SMTP's use of TLS. It
should probably be happening on the [EMAIL PROTECTED] list
instead of the main IETF mailing list. That's where the implementers
are, and that's where the implementers of most of the foo-over-TLS
protocols are. They too should
Sounds like an argument for having WG/mailing-list info in or near the
Authors Address section.
Thanks, Donald
On Tue, 11 Mar 2003, John Stracke wrote:
Date: Tue, 11 Mar 2003 11:24:28 -0500
From: John Stracke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Network Working Group
I think the trouble with this attachment is that the whole e-mail is
encrypted in clear (anybody can decrypt) to save space when you send the
e-mail (SSL/TLS includes compression).
The trouble is that the whole e-mail is encapsulated inside this signed
attachment. Therefore your antivirus may not
At 9:27 AM +1200 3/13/03, Franck Martin wrote:
I think the trouble with this attachment is that the whole e-mail is
encrypted in clear (anybody can decrypt) to save space when you send the
e-mail (SSL/TLS includes compression).
It's not encrypted, it's encoded in a form (base 64) that is unlikely
There's no reason a protocol can't be spec'd to let the client convey
the name of the resource before the TLS handshake begins.
no, there isn't. but it still wouldn't give the client a way to verify
that the server is authoritative for that domain.
ironyIf it isn't, your trust in the CA
Not clear. SMTP can relay a single copy of a message to multiple
recipients at multiple domains. Your suggestion would force a
separate TLS session, or a separate SMTP session, for every distinct
recipient domain.
Yes, that's true, but that's inherent in the one certificate
model.
Matt Crawford [EMAIL PROTECTED] writes:
Not clear. SMTP can relay a single copy of a message to multiple
recipients at multiple domains. Your suggestion would force a
separate TLS session, or a separate SMTP session, for every distinct
recipient domain.
Yes, that's true, but
The whole problem is that nobody sells certificates that can sign other
certificates.
If verisign gives a signing certificate to the ISP then the system works.
If we know who is the sender, then we can actively take action against him
outside the net in the real world. Like Caller ID phoning,
Keith Moore [EMAIL PROTECTED] writes:
I see your point. But I suspect it illustrates a significant
limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
that an IP address and port number are used by only one named service.
It's been awhile since I looked at the TLS
Keith Moore [EMAIL PROTECTED] writes:
It's true that this is a backward compatibility problem
in that STARTTLS as currently defined doesn't actually contain
the domain name. As I indicated before, I consider this to
be a design error. There wouldn't have been a compatibility
problem if
23 matches
Mail list logo
