On 03/27/2009 06:31 AM, Kyle Hamilton:
The original idea was how to improve Thunderbird's existing abilities to
work with crypto and deliver security. If you read my proposal carefully
you will see I very carefully separated the crypto/secure email part from
the certificates part.
The
On 03/27/2009 06:48 AM, Kyle Hamilton:
My thought was designed to reduce the barrier to entry to the
CA-managed PKI. (Class 0: no verification performed, SSC. Class 1:
CA has verified that the holder of the private key that corresponds to
the public key in the certificate can read emails sent
2009/3/27 Eddy Nigg eddy_n...@startcom.org:
By the way, I'm *absolutely disgusted* by seeing the CN field be
Startcom Free Certificate Member.
Perhaps you haven't used S/MIME certs from other providers then :-)
Thawte Freemail Member. Startcom Free Certificate Member. Same
difference.
On 03/27/2009 02:16 PM, Kyle Hamilton:
I'm also going to state, once more: your Assumptions (in this case,
your Beliefs) are what are making this system NOT WORK. Your Beliefs
are what are preventing people from wanting to participate. Sure, you
set the rules, you set the UI... but nobody
On Fri, Mar 27, 2009 at 5:48 AM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/27/2009 02:16 PM, Kyle Hamilton:
I'm also going to state, once more: your Assumptions (in this case,
your Beliefs) are what are making this system NOT WORK. Your Beliefs
are what are preventing people from wanting
On 03/27/2009 04:40 PM, Kyle Hamilton:
And fortunately I'm glad to inform you that he wouldn't have received a
verified certificate from StartCom. I'm not saying it's imposable with faked
passports to receive certification, however the hooks and jumps the
subscriber has to go through makes it
Eddy... Remember. Most interactions on the Internet are not
contracts. Most interactions on the Internet have no need of Real
Names. Most interactions on the Internet have no need for this level
of knowledge.
Policy must support the user and the user's needs. There are reasons
why there's a
On 03/28/2009 12:41 AM, Kyle Hamilton:
Eddy... Remember. Most interactions on the Internet are not
contracts. Most interactions on the Internet have no need of Real
Names.
That's perhaps also the source of many problems on the Internet...and
don't pretend there aren't...
Your
On 24/3/09 21:21, Kyle Hamilton wrote:
(The US Patent and Trademark Office does it by sending a transaction
ID number via postal mail, and a verification code via email to the
address-of-record, only after a notarized jurat is physically mailed
in. I honestly think the current batch of CAs are
On 03/27/2009 01:46 AM, Ian G:
The original idea was how to improve Thunderbird's existing abilities
to work with crypto and deliver security.
Could you define security please?
...as such, Mozilla goes a step fuhrer and tells you correctly hey, we
can't know if you are connecting to the site
On 25/3/09 08:45, Kyle Hamilton wrote:
However, the fact that the NSS layer handles
authentication of data makes this the only logical place to bring up
these issues.
Agreed, either here or in the new policy list, iff it can be sustained
as a security policy. But I suspect not.
The
On 27/3/09 00:54, Eddy Nigg wrote:
On 03/27/2009 01:46 AM, Ian G:
The original idea was how to improve Thunderbird's existing abilities
to work with crypto and deliver security.
Could you define security please?
Of course, in many and various ways! For this particular thing, I would
On 03/27/2009 03:58 AM, Ian G:
Encryption would give more privacy of emails, where otherwise there
was less privacy.
S/MIME encryption without assuring the email address is security
theater. What you suggest would be even counter-productive since it
would give the wrong impression of
On Thu, Mar 26, 2009 at 4:46 PM, Ian G i...@iang.org wrote:
On 25/3/09 01:06, Eddy Nigg wrote:
On 03/25/2009 12:35 AM, Kyle Hamilton:
I don't understand how this is connected to the initial idea of finding
some better ways to use client certificates for mail (was actually
client certificate
On Thu, Mar 26, 2009 at 6:12 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/27/2009 03:58 AM, Ian G:
Encryption would give more privacy of emails, where otherwise there was
less privacy.
S/MIME encryption without assuring the email address is security theater.
What you suggest would be
On Thu, Mar 26, 2009 at 3:41 PM, Ian G i...@iang.org wrote:
On 24/3/09 21:21, Kyle Hamilton wrote:
(The US Patent and Trademark Office does it by sending a transaction
ID number via postal mail, and a verification code via email to the
address-of-record, only after a notarized jurat is
On Mar 24, 2009, at 5:06 PM, Eddy Nigg wrote:
On 03/25/2009 12:35 AM, Kyle Hamilton:
'reasonable security'
'this service' (the one you offer 'for free') -- my own assumption is
that you don't offer the service of verifying community membership
for
web-based communities that don't offer
Nelson,
Nelson B Bolyard wrote:
Eddy Nigg wrote, On 2009-03-23 08:30:
On 03/23/2009 06:29 AM, Nelson B Bolyard:
1) When the user downloaded his new email cert in his browser, he didn't
get the full chain, but only got his own cert. So, he didn't have the
complete cert chain in his browser
On Tue, Mar 24, 2009 at 3:30 AM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/24/2009 06:24 AM, Kyle Hamilton:
One thing I'm missingwhere comes the email control validation in?
This is where you get to upsell your service.
This is not something to up-sell, it's basic requirement for
Remember this: A public key is an identity. It is an identity which
is bound to the private key.
Sure...
That would be a bad idea IMO. I don't want a certificate from XYZ CA nor do
I want them to know anything about me. I'm happy to use ZXY and YXZ CA
however. I'd make simply another
On Tue, Mar 24, 2009 at 12:56 PM, Eddy Nigg eddy_n...@startcom.org wrote:
Remember this: A public key is an identity. It is an identity which
is bound to the private key.
Sure...
What would they know about you that couldn't be harvested from email
lists? That you have a public key, and
On 03/24/2009 10:21 PM, Kyle Hamilton:
Hate to say it, but anyone who scans for smime.p7s files on the net
can already do that. The cat's already out of the bag.
What's that? You mean scan for email addresses at large, right? That's
nothing new, but look, as a subscriber one has
On 03/25/2009 12:35 AM, Kyle Hamilton:
'reasonable security'
'this service' (the one you offer 'for free') -- my own assumption is
that you don't offer the service of verifying community membership for
web-based communities that don't offer email accounts.
Nope, and it's beyond the scope
On 03/23/2009 06:29 AM, Nelson B Bolyard:
1) When the user downloaded his new email cert in his browser, he didn't
get the full chain, but only got his own cert. So, he didn't have the
complete cert chain in his browser when he exported it to a PKCS#12 file.
If the cert chain had been complete
Eddy Nigg wrote:
The incomplete chain downloaded into Firefox is the problem that must be
fixed. It's the most crucial. I don't know if it's entirely an issue
in the CA (:-) or also partially in Firefox.
Unfortunately Firefox DOES NOT include the chain in the PKCS12 file even
if the
Eddy Nigg wrote, On 2009-03-23 08:30:
On 03/23/2009 06:29 AM, Nelson B Bolyard:
1) When the user downloaded his new email cert in his browser, he didn't
get the full chain, but only got his own cert. So, he didn't have the
complete cert chain in his browser when he exported it to a PKCS#12
On 03/23/2009 08:13 PM, Nelson B Bolyard:
Perhaps PSM should have a feature, used at cert import time, that discovers
that the chain is incomplete and offers, at that time, to go and fetch the
missing certs in the chain via AIA.
Cold this be a solution which could be applied to Firefox as
Eddy Nigg wrote, On 2009-03-23 11:20:
On 03/23/2009 08:13 PM, Nelson B Bolyard:
Perhaps PSM should have a feature, used at cert import time, that discovers
that the chain is incomplete and offers, at that time, to go and fetch the
missing certs in the chain via AIA.
Cold this be a solution
On 03/23/2009 10:27 PM, Nelson B Bolyard:
I'd change that last line to this;
Click here to bet your career that this cert is genuine and not a forgery.
I'd suggest that we also display the URL for the user to see before
deciding, but we know that users would click without even looking at it.
On 23/3/09 20:36, Nelson B Bolyard wrote:
Ian G wrote, On 2009-03-22 16:01 PDT:
Man in the Browser. It is a term that seems to have caught on to
describe what happens when the browser is taken over by malware, and it
owns the interface. To solve the security problems that arises in
online
On 22/3/09 00:32, Eddy Nigg wrote:
On 03/22/2009 12:55 AM, Ian G:
I don't know about these things, but I recognise that badly configured
servers are a pain. The servers I have experienced this with are
Apache. They may be misconfigured, but the sysadms aren't agreeing at
the moment, and talking
On 03/24/2009 02:25 AM, Ian G:
I haven't followed it in depth, but the primary way that the E.B.s
have responded is to move their existing TAN system to a cellphone SMS
(which the europeans call handys, brits call them mobiles). A TAN
is a transaction authentication number which is
On Mon, Mar 23, 2009 at 7:27 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/24/2009 04:09 AM, Ian G:
This would then mean that on adding an email account into Tbird, it
automatically creates the public key pair. On each email sent out, it
includes the public key in a header. On each email
On 03/22/2009 10:30 AM, Ian G:
Eddy,
can you speak plainly? As far as I can see, you are saying that
OpenID is the solution, and you sell it. If you are saying this, then
isn't this evidence that client certs are unusable without some
additional technology?
That's not what I said,
On 22/3/09 05:17, Nelson B Bolyard wrote:
I wrote:
Here's the TB RFE: https://bugzilla.mozilla.org/show_bug.cgi?id=437683
BTW, this client auth problem is MUCH MUCH worse for Thunderbird users than
for browser users, because evidently a higher percentage of free email
servers are crap.
I'll
On Sat, Mar 21, 2009 at 5:57 PM, Nelson B Bolyard nel...@bolyard.me wrote:
Kyle Hamilton wrote, On 2009-03-21 15:49:
On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard nel...@bolyard.me wrote:
I blame NSS for choosing not to adhere to certain aspects of the SSL
3.0 and TLS 1.0 standards
Eddy Nigg wrote, On 2009-03-22 02:57:
[...] client certificates AND OpenID are a great combination. We don't
sell it, it's free.
OpenID is a digital identity and eliminates the need for multiple
usernames across different websites. For authentication at the provider
side we use client
May I suggest that we who have spent considerable time and list
band-with on this topic try to summarize it in a public working
document for other people to study?
Since we don't agree on all issues and their possible solution(s), it is
reasonable
to include contributor(s) for each issue. Here
On 03/22/2009 05:42 PM, Nelson B Bolyard:
I think you're saying that OpenID provides a centralized single space
of Use IDs (user names, if you will), and your certs may be used as a
strong method of authenticating the user to a server as the true holder
of such an ID. Is that it?
MUST be
On 03/22/2009 07:36 PM, Eddy Nigg:
How does that work (for the user)? If I were to get an OpenID, how
would
I get a cert from your CA that certified me as the holder of that ID?
Or do I have it wrong?
One more thing on that one...there is is one OpenID provider which lets
you use certs
Kyle Hamilton wrote, On 2009-03-22 04:40:
On Sat, Mar 21, 2009 at 5:57 PM, Nelson B Bolyard nel...@bolyard.me
wrote:
Kyle Hamilton wrote, On 2009-03-21 15:49:
On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard nel...@bolyard.me
wrote: I blame NSS for choosing not to adhere to certain aspects
On 03/22/2009 07:58 PM, Nelson B Bolyard:
Each product has one way to install PKCS#11 modules. All modules are
installed in that product by that method, whatever it is. In Firefox,
you go to the Options dialog (exact method varies by platform, on Windows
you find Options in the Tools menu)
On 03/22/2009 07:25 PM, Anders Rundgren:
May I suggest that we who have spent considerable time and list
band-with on this topic try to summarize it in a public working
document for other people to study?
I suggest to use the Mozilla Wiki for that.
Since we don't agree on all issues and
Eddy Nigg wrote, On 2009-03-22 12:51:
On 03/22/2009 07:25 PM, Anders Rundgren:
Solution: One solution would be to define signature support as a
browser component.
Especially the component you've invented and have been trying to get
Mozilla to adopt for some time, right? Anders?
Sounds
Anders Rundgren wrote, On 2009-03-22 13:34:
I don't think PKCS #11 fills the role as universal crypto system for
the mass market since there is no registry like its competitors have.
Installing Security Devices (including finding out the path to them),
is way beyond what a consumer can do.
2009/3/22 Nelson B Bolyard nel...@bolyard.me:
Eddy Nigg wrote, On 2009-03-22 12:51:
On 03/22/2009 07:25 PM, Anders Rundgren:
FF issue: It seems that the AIA ca issuer extension is not supported.
This complicates
Kyle Hamilton wrote, On 2009-03-22 13:54:
2009/3/22 Nelson B Bolyard nel...@bolyard.me:
Eddy Nigg wrote, On 2009-03-22 12:51:
On 03/22/2009 07:25 PM, Anders Rundgren:
FF issue: It seems that the AIA ca issuer extension
Nelson B Bolyard wrote:
Solution: One solution would be to define signature support as a
browser component.
Especially the component you've invented and have been trying to get
Mozilla to adopt for some time, right? Anders?
At this stage it is enough considering (acknowledging) the 10M+ that
On 03/22/2009 10:38 PM, Nelson B Bolyard:
Oh, those poor server admins!
Wrong! It's those poor users exporting their client certs from Firefox
into Thunderbirdand then they have no clue why they can't sign their
mail (without explicitly importing the issuer intermediate CAs from a
Anders Rundgren wrote, On 2009-03-22 14:20:
Nelson B Bolyard wrote:
Solution: One solution would be to define signature support as a
browser component.
Especially the component you've invented and have been trying to get
Mozilla to adopt for some time, right? Anders?
At this stage it
On 22/3/09 22:20, Anders Rundgren wrote:
Nelson B Bolyard wrote:
Solution: One solution would be to define signature support as a
browser component.
Especially the component you've invented and have been trying to get
Mozilla to adopt for some time, right? Anders?
At this stage it is
Eddy Nigg wrote, On 2009-03-22 14:22:
On 03/22/2009 10:38 PM, Nelson B Bolyard:
Oh, those poor server admins!
Wrong! It's those poor users exporting their client certs from Firefox
into Thunderbirdand then they have no clue why they can't sign their
mail (without explicitly importing
@lists.mozilla.org
Sent: Friday, March 20, 2009 22:30
Subject: Re: client certificates unusable?
'since you obviously shouldn't have different PKI UIs for signatures
and authentication'? What crack are you smoking?
In the Real World, we have a different UI for authentication -- the
principal presenting an ID
On 20/3/09 08:32, Anders Rundgren wrote:
This is a stupid discussion.
Authentication schemes in general begin with authenticating the user.
How long the authentication should be considered as valid is
not something the client-end has anything to do with unless it
has gotten some kind of
On 20/3/09 22:30, Kyle Hamilton wrote:
'since you obviously shouldn't have different PKI UIs for signatures
and authentication'? What crack are you smoking?
Hey Kyle, I think you are thinking way to far ahead here...
In the Real World, we have a different UI for authentication -- the
On 21/3/09 16:54, Eddy Nigg wrote:
Huu? No outcry about rudeness in mailing lists here?
Eddy, I agree that rudeness was carrying us away from the problem and on
to the personalities. Indeed, it's up to all of us to be be minded of
this. For reasons that are too wordy to be worth the
On 20/3/09 19:29, Anders Rundgren wrote:
This is a stupid comment.
Pardon me. I just don't agree with the majority of this list since
many governments and banks in the EU are working in another
direction. This may be due to ignorance
Folks, Anders is right about this worldview difference.
Kyle Hamilton wrote, On 2009-03-20 02:15:
This is a stupid comment.
Then why post it?
There are many people who think differently; I, for one, think that
server-auth is the *worse* part of TLS (because there's no branding of
what CA is responsible for the certification, there's no way to
Ian G wrote, On 2009-03-21 12:32:
It seems that we have a consensus that client
certificates (in a client authentication role at least) are unusable
with the current system. Approximately, for many reasons.
Sorry, I disagree. There are many places (companies, governments) that
use client
On Sat, Mar 21, 2009 at 1:11 PM, Nelson B Bolyard nel...@bolyard.me wrote:
Kyle Hamilton wrote, On 2009-03-20 02:15:
This is a stupid comment.
Then why post it?
Because Anders was referring to the argument as stupid, and I was
referring to his comment as stupid. (Sometimes, just sometimes,
I should also add:
The problem is not simply on the server's end, Nelson. You've been
pointing at them for years. (The DoD also doesn't use Firefox, so
they don't end up filing bugs against it anyway.)
The client was built around the same paradigm as the server. The
client paradigm is what
On 03/21/2009 09:32 PM, Ian G:
On 21/3/09 16:54, Eddy Nigg wrote:
Huu? No outcry about rudeness in mailing lists here?
Eddy, I agree that rudeness was carrying us away from the problem and
on to the personalities. Indeed, it's up to all of us to be be minded
of this. For reasons that
Kyle Hamilton wrote, On 2009-03-21 14:07:
On Sat, Mar 21, 2009 at 1:11 PM, Nelson B Bolyard nel...@bolyard.me wrote:
Kyle Hamilton wrote, On 2009-03-20 02:15:
There are many people who think differently; I, for one, think that
server-auth is the *worse* part of TLS (because there's no
Eddy Nigg wrote, On 2009-03-21 15:08:
On 03/21/2009 10:43 PM, Nelson B Bolyard:
The consensus of which you speak is actually a consensus among users of
those crappy servers that, with those servers, client auth is unusable.
I am part of that consensus. But I do not agree that changing the
On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard nel...@bolyard.me wrote:
Kyle Hamilton wrote, On 2009-03-21 14:07:
No, I blame the browser UI for not exposing useful details of the TLS
protocol. The TLS protocol explicitly does not call out the handling
of server certificates: this is the
On 21/3/09 21:43, Nelson B Bolyard wrote:
Ian G wrote, On 2009-03-21 12:32:
It seems that we have a consensus that client
certificates (in a client authentication role at least) are unusable
with the current system. Approximately, for many reasons.
Sorry, I disagree. There are many places
On 03/22/2009 12:26 AM, Ian G:
Right, the problem perhaps is better expressed that some of these
comments *aren't written with emoticons at the end* so it is not easy
for those from diverse cultures to figure out the joke. Oh, and I
save my stuff for those that appreciate fine red wine ;-)
On 03/22/2009 12:55 AM, Ian G:
I don't know about these things, but I recognise that badly configured
servers are a pain. The servers I have experienced this with are
Apache. They may be misconfigured, but the sysadms aren't agreeing at
the moment, and talking about the sysadms being bad
Ian G wrote, On 2009-03-21 15:55:
I don't know about these things, but I recognise that badly configured
servers are a pain. The servers I have experienced this with are
Apache. They may be misconfigured, but the sysadms aren't agreeing at
the moment, and talking about the sysadms being
On Sat, Mar 21, 2009 at 4:32 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/22/2009 12:55 AM, Ian G:
Hmmm, well, many questions abound: why wasn't it done? where was this
discussed? Why didn't client certs just happen? Why are we still using
passwords?
Good questionit's because
Kyle Hamilton wrote, On 2009-03-21 15:49:
On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard nel...@bolyard.me wrote:
I blame NSS for choosing not to adhere to certain aspects of the SSL
3.0 and TLS 1.0 standards (accepting a ClientCertificateRequest with a
zero-length list of identifiers of
Ian G wrote, On 2009-03-21 07:00:
After MITB surfaced (and scared the European bankers into action)
What is that? Man In The Bank?
I suppose you meant MITM, but if not, please clarify.
people in finance circles started to realise that session authentication
was a mistake from the beginning
Kyle Hamilton wrote, On 2009-03-21 16:51:
On Sat, Mar 21, 2009 at 4:32 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/22/2009 12:55 AM, Ian G:
Hmmm, well, many questions abound: why wasn't it done? where was
this discussed? Why didn't client certs just happen? Why are we
still using
I wrote:
Here's the TB RFE: https://bugzilla.mozilla.org/show_bug.cgi?id=437683
BTW, this client auth problem is MUCH MUCH worse for Thunderbird users than
for browser users, because evidently a higher percentage of free email
servers are crap.
I'll have to dig a bit more for the FF one.
On Thu, Mar 19, 2009 at 8:29 PM, Nelson B Bolyard nel...@bolyard.me wrote:
Joe Orton wrote, On 2009-03-19 15:15:
Going from 3 minutes to 10 minutes doesn't seem like it will save the
world (if 3 minutes was indeed putting the world at risk).
Agreed. For most users 4 or 8 hours is more
Kyle Hamilton wrote, On 2009-03-19 23:07:
My reason for the conservative time suggestions is because that's what
banks tend to use (my bank times me out after 15 minutes of
inactivity, as does my phone company, and my electric company, and
PayPal, and...).
But those are *minutes of
On Thu, Mar 19, 2009 at 11:57 PM, Nelson B Bolyard nel...@bolyard.me wrote:
Kyle Hamilton wrote, On 2009-03-19 23:07:
My reason for the conservative time suggestions is because that's what
banks tend to use (my bank times me out after 15 minutes of
inactivity, as does my phone company, and my
nel...@bolyard.me
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Friday, March 20, 2009 07:57
Subject: Re: client certificates unusable?
Kyle Hamilton wrote, On 2009-03-19 23:07:
My reason for the conservative time suggestions is because that's what
banks tend
it.
Anders
- Original Message -
From: Nelson B Bolyard nel...@bolyard.me
To: mozilla's crypto code discussion list
dev-tech-crypto@lists.mozilla.org
Sent: Friday, March 20, 2009 07:57
Subject: Re: client certificates unusable?
Kyle Hamilton wrote, On 2009-03-19 23:07:
My reason
be able fix it.
Anders
- Original Message -
From: Nelson B Bolyard nel...@bolyard.me
To: mozilla's crypto code discussion list
dev-tech-crypto@lists.mozilla.org
Sent: Friday, March 20, 2009 07:57
Subject: Re: client certificates unusable?
Kyle Hamilton wrote, On 2009-03-19 23:07
part to a community that won't be able fix it.
Anders
- Original Message -
From: Nelson B Bolyard nel...@bolyard.me
To: mozilla's crypto code discussion list
dev-tech-crypto@lists.mozilla.org
Sent: Friday, March 20, 2009 07:57
Subject: Re: client certificates unusable?
Kyle
On Wed, Mar 18, 2009 at 07:42:12AM -0700, Kyle Hamilton wrote:
I think a reasonable default would be about 10 or 15 minutes, with a
refresh of the session (moving it back to 0 minutes) every successful
request?
With the default mod_ssl cache, I think that the session should already
get stored
Joe Orton wrote, On 2009-03-19 15:15:
On Wed, Mar 18, 2009 at 07:42:12AM -0700, Kyle Hamilton wrote:
I think a reasonable default would be about 10 or 15 minutes, with a
refresh of the session (moving it back to 0 minutes) every successful
request?
With the default mod_ssl cache, I think
Robert Relyea wrote:
[...] At the
cost of about 20 bytes per client you would rather chew up CPU and
network resources?
It's very far from being that small usually. It can't be that small if
client authentication is used.
There's an extension to TLS to offset the cost to the client (the
On Wed, Mar 18, 2009 at 3:28 AM, Nelson B Bolyard nel...@bolyard.me wrote:
b) they have NO CA CERTIFICATES marked as trusted to issue client certs,
so they violate the SSL and TLS 1.0 protocols by sending out empty lists
of issuer names for CA certs, which give clients no information with which
Joe Orton wrote, On 2009-03-17 08:55:
It seems like a poor trade-off to require a larger memory footprint of
all the SSL servers in the world,
I hear that disk space is pretty cheap these days. 1TB == USD 85
rather than improve Firefox to be a bit smarter about caching/
Jean-Marc Desperrier wrote, On 2009-03-18 02:50:
Robert Relyea wrote:
[...] At the
cost of about 20 bytes per client you would rather chew up CPU and
network resources?
It's very far from being that small usually. It can't be that small if
client authentication is used.
There's an
Kyle Hamilton wrote, On 2009-03-18 04:20:
On Wed, Mar 18, 2009 at 3:28 AM, Nelson B Bolyard nel...@bolyard.me wrote:
b) they have NO CA CERTIFICATES marked as trusted to issue client certs,
so they violate the SSL and TLS 1.0 protocols by sending out empty lists
of issuer names for CA certs,
On Tue, Mar 17, 2009 at 10:26:35AM -0700, Robert Relyea wrote:
Cert selection for Firefox does need to be improved. On the other hand,
I found the larger memory footprint argument someone confusing. At the
cost of about 20 bytes per client you would rather chew up CPU and
network
Alright, I have misremembered. But, this brings up a point:
What's the appropriate response to a 3,0 or 3,1 protocol server that
sends a 0-length ClientCertificateType Certificate request message?
Under a strict reading of the RFC (2246 is the one I'm looking at, for
TLS 1.0 (corresponding to
I think a reasonable default would be about 10 or 15 minutes, with a
refresh of the session (moving it back to 0 minutes) every successful
request?
-Kyle H
On Wed, Mar 18, 2009 at 6:56 AM, Joe Orton j...@manyfish.co.uk wrote:
On Tue, Mar 17, 2009 at 10:26:35AM -0700, Robert Relyea wrote:
Cert
Hi all,
I'd like to ask a couple of questions to those people closer to the
development effort. I spent some hours trying to get a couple of users
up and going on the weekend using client certs and ff/tb combinations.
On the Firefox side, there were problems because of the popup madness
On 03/17/2009 01:55 PM, Ian G:
Hi all,
I'd like to ask a couple of questions to those people closer to the
development effort. I spent some hours trying to get a couple of
users up and going on the weekend using client certs and ff/tb
combinations. On the Firefox side, there were problems
On 17-Mar-09, at 7:55 AM, Ian G wrote:
I'd like to ask a couple of questions to those people closer to the
development effort. I spent some hours trying to get a couple of
users up and going on the weekend using client certs and ff/tb
combinations. On the Firefox side, there were problems
On 17/3/09 13:45, Johnathan Nightingale wrote:
On 17-Mar-09, at 7:55 AM, Ian G wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=295922 Now, this is a
So we have seem to have a choice: client certificates are unusable
because they always ask, or they are unusable because they always leak
On 03/17/2009 05:55 PM, Joe Orton:
That's because Apache's default cache timeout is set to 30 seconds or
so. And might be buggy in addition to that.
The default mod_ssl configuration uses a 300 second timeout, not 30.
Oh yes, actually you are right.
There's a plea being made here
On 03/17/2009 02:45 PM, Johnathan Nightingale:
I think the implicit 4th step there is evangelism, because I think
they're a much more robust identification/authentication technology
than login+pw, or most of login+pw's would-be replacements. But I
also think there's no point evangelizing the
On Tue, Mar 17, 2009 at 12:35 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/17/2009 02:45 PM, Johnathan Nightingale:
I think the implicit 4th step there is evangelism, because I think they're
a much more robust identification/authentication technology than login+pw,
or most of login+pw's
Hamilton aerow...@gmail.com
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Tuesday, March 17, 2009 21:42
Subject: Re: client certificates unusable?
On Tue, Mar 17, 2009 at 12:35 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 03/17/2009 02:45 PM, Johnathan Nightingale
On Tue, Mar 17, 2009 at 2:51 PM, Anders Rundgren
anders.rundg...@telia.com wrote:
I'm personally unconvinced that client-cert-TLS auth is the way ahead.
HTTP-basic was killed by forms and quite a few schemes out there
including Entrust's use a similar paradigm for PKI which works better with
1 - 100 of 107 matches
Mail list logo
