Ian G wrote, On 2008-10-20 22:41:
> Nelson B Bolyard wrote:
>> It is widely agreed that, since KCM has no central revocation facility,
>
> KCM is not central, period. Talking about revocation is a strawman.
I should have said "central revocation SERVICE". Sadly, it DOES have a
central revocati
Nelson B Bolyard wrote:
> Ian G wrote, On 2008-10-20 19:24:
>
>> There are possibilities. One is the server-side self-signed certs,
>> which would generally prefer KCM to be useful, so add Petnames.
>> This is ok for small sites, small communities, but valuable there as
>> compromised boxes are a
Ian G wrote, On 2008-10-20 19:24:
> There are possibilities. One is the server-side self-signed certs,
> which would generally prefer KCM to be useful, so add Petnames.
> This is ok for small sites, small communities, but valuable there as
> compromised boxes are a pain.
The Debian OpenSSL fiasc
https is a perfectly valid protocol, and I don't think that it should
be changed (or any aspect of it should be changed or supplanted). The
ONLY problem that exists is the chrome.
On Mon, Oct 20, 2008 at 6:23 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
>
>> b) some unmistakeable blatantly obv
I disagree with Julien on two items in this thread.
At 5:31 PM -0700 10/20/08, Julien R Pierre - Sun Microsystems wrote:
>If the root could "revoke itself", in the case of root cert key compromise,
>ie. the root cert's private key becoming public, anybody could then sign
>revocation information
Nelson B Bolyard wrote:
> OK, I was too flippant, but I'm serious about wanting an alternative
> to https, something that means security not good enough for financial
> transactions, but OK for your private home router/server.
>
> Nelson B Bolyard wrote, On 2008-10-20 15:07:
>> Ian G wrote, On 200
Nelson B Bolyard:
OK, I was too flippant, but I'm serious about wanting an alternative
to https, something that means security not good enough for financial
transactions, but OK for your private home router/server.
One way doing it is going to http://www.ietf.org/ and proposing it.
Another wa
OK, extracting the meat from all these replies from Pierre, I wrote
this:
===
https://wiki.mozilla.org/CA:Recommendations_for_Roots#SubRoots
Revocation of the Root [edit]
* For a root listed in Mozilla's root list, file a bug to
request the root be marked "untrusted". Once di
OK, I was too flippant, but I'm serious about wanting an alternative
to https, something that means security not good enough for financial
transactions, but OK for your private home router/server.
Nelson B Bolyard wrote, On 2008-10-20 15:07:
> Ian G wrote, On 2008-10-20 13:28:
>> (e.g., we do agr
Julien R Pierre - Sun Microsystems:
Or until next update. It's still valid but not updated anymore.
It still remains valid for the application to use an old CRL if it is
unable to obtain newer one, whatever the reason.
I think that's what I said :-)
--
Regards
Signer: Eddy Nigg, StartCom L
Julien R Pierre - Sun Microsystems:
Eddy Nigg wrote:
Ian G:
b. Once so revoked, are all following CRLs also "revoked"?
The CRL would have to be valid until the expiration time of the root.
Remember that CRLs don't expire. The application can consider them
either valid or invalid based on
Nelson B Bolyard wrote:
b) some unmistakeable blatantly obvious way to show the user that this
site is not using security that's good enough for banking but, well,
is pretty good security theater. Flashing pink chrome?
Empty wallet icon? The whistling sounds associated with falling things?
http
Eddy,
Eddy Nigg wrote:
Julien R Pierre - Sun Microsystems:
Eddy Nigg wrote:
Ian G:
b. Once so revoked, are all following CRLs also "revoked"?
The CRL would have to be valid until the expiration time of the root.
Remember that CRLs don't expire. The application can consider them
either
Julien R Pierre - Sun Microsystems:
Eddy,
Eddy Nigg wrote:
That's entirely and implementation issue and design approach.
No. It is also an issue of PKIX standards as well. CAs should not
implement revocation mechanisms that are not standard, and expect them
to be supported by general-purpo
Eddy,
Eddy Nigg wrote:
Ian G:
b. Once so revoked, are all following CRLs also "revoked"?
The CRL would have to be valid until the expiration time of the root.
Remember that CRLs don't expire. The application can consider them
either valid or invalid based on the certification path of the
Ian,
Ian G wrote:
Having read and mused on this "chicken and egg" problem, I see a
bunch of questions here. I doubt they will all be answered, but
food for thought:
1. If a root is compromised, how is it revoked and/or replaced?
By means of marking that cert as untrusted , or deleting that
Eddy,
Eddy Nigg wrote:
That's entirely and implementation issue and design approach.
No. It is also an issue of PKIX standards as well. CAs should not
implement revocation mechanisms that are not standard, and expect them
to be supported by general-purpose software like NSS/Mozilla.
__
Ian,
Ian G wrote:
Nelson Bolyard wrote:
Frank Hecker wrote:
However there still appears to be an open question as to whether having an
AIA extension with OCSP URL in the Microsec root certificate will cause a
problem with NSS. (Nelson wrote that he was going to investigate this, but I
don't re
Eddy,
Eddy Nigg wrote:
Ian G:
Ah, ok, excellent, that helps with the big question: Can we
conclude from this that roots cannot be revoked by means of the
OCSP/CRL channel?
No, because it depends on the application and library implementing it I
think. Apparently it's correct for NSS.
Now
Nelson B Bolyard:
httpst:// (security theater) maybe? or
httpwf:// (warm fuzzy) or
mitm://
LOLI can't hold myself on the chair anymore...I'm laughing myself
kaput! Because of you I had to change my shirt and clean the keyboard
from coffee stainsCan you warn me next time upfront not
Ian G wrote, On 2008-10-20 13:28:
> Yes. E.g., did you know that the point of a good lock on a door is
> *not* to stop a burglar getting in, but to stop him getting out?
> That's why it is called a deadbolt. The burglar can always get in,
> the game is to stop him getting out the front door, car
At 11:49 AM -0700 10/20/08, Nelson B Bolyard wrote:
>Jean-Marc Desperrier wrote, On 2008-10-20 01:50:
>
>> As has *already* been reported on this group, *many*, *many*, *many*
>> users did not fill a bug report until now and switched browser instead.
>
>OK. So, many users who have been MITM attack
Kyle Hamilton wrote:
> On Mon, Oct 20, 2008 at 4:49 AM, Eddy Nigg <[EMAIL PROTECTED]> wrote:
>> Jean-Marc Desperrier:
>>> Graham Leggett wrote:
This is the classic balance between convenience and security.
>>> inconvenience != security.
>>>
>>> inconvenience == unsecurity.
>>>
>> Every time I
Nelson B Bolyard wrote:
> Jean-Marc Desperrier wrote, On 2008-10-20 05:33:
>> Jean-Marc Desperrier wrote:
>
>> I realized that there's a specific reason why I don't lock my door after
>> entering. [...] The door of my appartement doesnt' have an ouside handle.
>> You can't enter without using the
My good and knowledgeable friend Eddy Nigg will have a fit about my
putting into this list a link to something that is just an illustration.
Eddy, forgive me, but the folks on this list should be allowed to see a
new approach to a solution that is worth noting here.
See the bottom paragraph o
Ni Nuno,
nponte wrote:
Hi,
We are running a CA that has thousands of revoked certificates
which leads to CRLs of several MBytes.
On the next nenewal of the CA, we are thinking of partitioning the
CRLs at each X number of issued certificates. The issued certificates
will have diffe
On Mon, Oct 20, 2008 at 4:49 AM, Eddy Nigg <[EMAIL PROTECTED]> wrote:
> Jean-Marc Desperrier:
>>
>> Graham Leggett wrote:
>>>
>>> This is the classic balance between convenience and security.
>>
>> inconvenience != security.
>>
>> inconvenience == unsecurity.
>>
>
> Every time I come from shopping
Jean-Marc Desperrier wrote, On 2008-10-20 01:50:
> As has *already* been reported on this group, *many*, *many*, *many*
> users did not fill a bug report until now and switched browser instead.
OK. So, many users who have been MITM attacked chose to defeat their
protections, and switch to a pro
Jean-Marc Desperrier wrote, On 2008-10-20 05:33:
> Jean-Marc Desperrier wrote:
> I realized that there's a specific reason why I don't lock my door after
> entering. [...] The door of my appartement doesnt' have an ouside handle.
> You can't enter without using the key.
In other words, you don't
Everybody take a deep breath. If we start treating this as black-and-white
extremes, it is unlikely that most users will get the best security and
usability.
Few if any of us active in this thread are HCI experts. Few of us have anything
more than small amounts of anecdotal evidence. Many of us
Jean-Marc Desperrier wrote, On 2008-10-20 01:50:
> Eddy Nigg wrote:
>> Ian G:
>>> Nelson B Bolyard wrote:
Despite all the additional obstacles that FF3 put in her way, and all
the warnings about "legitimate sites will never ask you to do this",
she persisted in overriding every error
Eddy Nigg wrote:
[...]. But if we believe that we should get to the point to prevent users
from clicking through errors (because of the risk involved) than we are
very close already. Implementation proposals may vary, but I think that
with providing better security for the AVERAGE user, overall u
Nelson B Bolyard wrote:
> Ian G wrote, On 2008-10-19 15:17:
>> Nelson B Bolyard wrote:
>
>>> KCM would have accepted those certs without any complaint.
>> Ahhh, not exactly! With KCM, it is not up to it to accept any certs
>> any time: unfamiliar certs are passed up to the user for validation.
Eddy Nigg wrote:
[...]
Despite that, http://www.xitimonitor.com/ has testimony to a growing
market share of Firefox in Europe, including Germany. Go figure...
I *never* claimed that this problem would lower the *general* use of
Firefox. The SSL use case is small enough that it has *no* weight
Jean-Marc Desperrier:
The pratical result of inconvenience is a threshold level that depends
of two factor : the inconvenience and the perceived threat.
I agree with every word you said in this mail! Risk assessment is
important! I believe that we just don't agree (yet) where to draw the
line
Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
[...]
Every time I come from shopping it's very inconvenient to put down the
shopping bags, grab for my keys and open the front door of my house.
Then pick up my bags again. After entering I have to lock the door again
(by convenience, if I want). But
Jean-Marc Desperrier:
The second number hardly actually proves anything. In what I describe,
users will continue to use Firefox most of the time, and switch to IE
only for broken SSL sites.
Believe me, I have counts of web site owners "fixing" their web sites
because of the mounting complain
Eddy Nigg wrote:
[...]
Every time I come from shopping it's very inconvenient to put down the
shopping bags, grab for my keys and open the front door of my house.
Then pick up my bags again. After entering I have to lock the door again
(by convenience, if I want). But overall, what an inconvenien
Ian G:
Curious! Eddy, how did you learn how to go to all that inconvenience?
LOL
Because I'm a security expert I guess :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: https://blog.startcom.org
___
dev-tech-cryp
Jean-Marc Desperrier:
Broken ? Yes, instead of accessing to the web site, he got some error
screen, and had to run IE instead.
Oh yes, and IE let him just through, no errors and no red address bar
and no "We recommend not to visit this site", right?
This was a developer with already around t
Eddy Nigg wrote:
[...]
MY sources show clearly that both web sites using legitimate
certificates and "market share" of Firefox has gone up. This is correct
in real number and relative percentage wise.
The second number hardly actually proves anything. In what I describe,
users will continue to
Eddy Nigg wrote:
> Jean-Marc Desperrier:
>> Graham Leggett wrote:
>>>
>>> This is the classic balance between convenience and security.
>>
>> inconvenience != security.
>>
>> inconvenience == unsecurity.
>>
>
> Every time I come from shopping it's very inconvenient to put down the
> shopping bags,
Jean-Marc Desperrier:
Graham Leggett wrote:
This is the classic balance between convenience and security.
inconvenience != security.
inconvenience == unsecurity.
Every time I come from shopping it's very inconvenient to put down the
shopping bags, grab for my keys and open the front door
On Oct 17, 6:17 pm, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
> Nuno Ponte wrote, On 2008-10-15 04:20 PDT:
>
>
>
> > We are running a CA that has thousands of revoked certificates
> > which leads to CRLs of several MBytes.
>
> > On the next nenewal of the CA, we are thinking of partitioni
Jean-Marc Desperrier:
Eddy Nigg wrote:
[...]
When the visitor statistics suddenly goes down, web site owners will
take action.[...]
It will not go down. It's only the percentage of user using Firefox that
will go down.
Can you please backup your assumptions?
MY sources show clearly that
Nelson B Bolyard wrote:
[...]
This incident has shown that FF3, with its all-too-easy-to-defeat MITM
reporting, is NOT suitable for high-value web transactions such as
online banking.
You know Nelson the reason why you are taking this the wrong way is that
you have *no* direct experience of ho
Graham Leggett wrote:
David E. Ross wrote:
[...]
I have also visited sites with incorrectly configured site certificates.
[...]. I definitely do not want to be locked out of these sites either.
This is the classic balance between convenience and security.
inconvenience != security.
inconven
Eddy Nigg wrote:
[...]
When the visitor statistics suddenly goes down, web site owners will
take action.[...]
It will not go down. It's only the percentage of user using Firefox that
will go down.
Please note that we've seen *one* knowledgeable enough webmaster report
here that the number o
Eddy Nigg wrote:
Ian G:
Nelson B Bolyard wrote:
Despite all the additional obstacles that FF3 put in her way, and all
the warnings about "legitimate sites will never ask you to do this",
she persisted in overriding every error, and thus giving away most of
her valuable passwords to her attacke
49 matches
Mail list logo
