On 10/15/2009 02:39 AM, Neil wrote:
> Robert Relyea wrote:
>
>> If you have no master password set, you have a token that doesn't
>> have 'need login' set in it. NSS will treat such a token as "always
>> logged in". No matter how many times you log out, the token and it's
>> keys are still availabl
On 2009-10-15 02:39 PDT, Neil wrote:
> Robert Relyea wrote:
>
>> If you have no master password set, you have a token that doesn't have
>> 'need login' set in it. NSS will treat such a token as "always logged
>> in". No matter how many times you log out, the token and it's keys are
>> still availa
On 10/15/2009 04:38 PM, Anders Rundgren:
But I don't *insist* that OCSP validation is a bad thing I just think that
using plain-vanilla HTTP or rolling your own cer seem to be an easier
way than faking an identity for a CA.
Agreed, but this is obviously an entire different issue.
--
Regard
Eddy Nigg wrote:
>Which is obviously not correct. Most revocations happen due to loss and
>compromise of private keys, retirements, software bugs, misuse, but
>seldom due to validation failures.
I would be surprised if a single public-TTP-issued server-certificate has ever
been revoked due to lo
On 10/15/2009 03:57 PM, Ian G:
On 15/10/2009 15:21, Gervase Markham wrote:
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. Th
On 15/10/2009 15:21, Gervase Markham wrote:
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often en
On 13/10/09 22:37, Robert Relyea wrote:
It turns out that of all cases 2, 3, and 4, case 4 is the easiest
(simply overload the requested OCSP server). Also, if you can do 2, and
3, you can always do 4 (You just drop the packet on the ground). So
while an attacker may have lots of things he can do
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often enough to motivate the building of new infrast
Apropos Gerv's strawman question about trying to make OCSP soft fail
better, here is a fairly eloquent article from Bruce Schneier that might
help. I don't always agree with him, but on this article, I am in full
agreement. First and last paras only.
http://threatpost.com/blogs/difficulty-
Robert Relyea wrote:
If you have no master password set, you have a token that doesn't have 'need login' set
in it. NSS will treat such a token as "always logged in". No matter how many
times you log out, the token and it's keys are still available.
What exactly are you seeing?
What I'm se
Nelson B Bolyard wrote:
By the way, I REALLY REALLY wish that the password manager would use that when
you click the button to reveal the passwords, instead of doing what it does
now, which forces you to re-enter the master password, even if you've JUST
entered it.
I think this is a holdov
Honza Bambas wrote:
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsPK11TokenDB.cpp#429
Says if there is need for a password when logging in.
Actually the case I want to distinguish is "logged in with a password"
versus "no password" (I don't care what the API return
Honza Bambas wrote:
Neil wrote:
Nelson Bolyard wrote:
I'll add these thoughts. I don't know of any way to "log in" to a
token that has no password. IINM, such a token just "comes up" in a
state that is similar to being already logged in. It's not
surprising to me that forcefully logging
13 matches
Mail list logo
