Nelson B Bolyard wrote:
it has exposed an unrelenting amount of accusation without
evidence. Show us a single falsified certificate. Anything less is
unworthy of this forum.
A large amount of that. But not necessarily exclusively.
There is in what has been reported one fact that has merit to
Hi Kurt,
I think it's more subtle than that, some of the problems in brief:
1) Mozilla/Firefox either trust a CA 100% or not at all.
Correct.
3) It's very difficult even for technical users to find out who
exactly signed a certificate. For example a certificate is signed by
"valicert",
Hello Kurt and others.
This is something I'd like to see a very long answer from someone in charge of
these thing in Mozilla.
TIA,
Martin.
On Feb 22, 2010, at 23:25 , Kurt Seifried wrote:
>
> This does not mean that the certificate verification mechanics are at fault;
> it only means that CA s
>
>
>
> This does not mean that the certificate verification mechanics are at
> fault;
> it only means that CA selection protocol has not been thought out properly:
> it limped along with a handful of CAs, it is showing the serious symptoms
> of the malaise with hundreds. In the meantime, does anyb
Nelson B Bolyard wrote:
On 2010/02/22 02:11 PST, makrober wrote:
CHHIC controversy has exposed the fallacy of current SSL implementation
premise,
Rather, it has exposed an unrelenting amount of accusation without
evidence. Show us a single falsified certificate. Anything less is
unworthy o
On 2010/02/22 02:11 PST, makrober wrote:
> Nguyễn Đình Nam wrote:
>>> What you're trying to do is a "who is watching the watchers" kind thing...
>
>> ...Every existing CA [...] made a promise to comply to the universal PKI
>> trust policy, we just need a scheme to enforce their promise.
>
> If
On Feb 22, 2010, at 13:03 , Nguyễn Đình Nam wrote:
>>
> I agree with you that you should revive the CA selection protocol, but
> we should also add 01 Auditing layer above of it anyway, it's an
> independent problem.
CA-s are audited, AFAIK that's one of the basic requirements. If your problem
is
On Feb 22, 5:11 pm, makrober wrote:
> > ...Every existing CA [...] made a promise to comply to the universal PKI
> > trust policy, we just need a scheme to enforce their promise.
>
> If we need a scheme to enforce some TTP's promise of uncorruptibility, he
> evidently does not qualify as a Trusted
Nguyễn Đình Nam wrote:
What you're trying to do is a "who is watching the watchers" kind thing...
...Every existing CA [...] made a promise to comply to the universal PKI
> trust policy, we just need a scheme to enforce their promise.
If we need a scheme to enforce some TTP's promise of unco
> What you're trying to do is a "who is watching the watchers" kind thing and
> as you described, you do this by adding another central piece of machinery to
> the picture where another central piece of machinery is easily manipulated
> into rogue actions. I don't see how this would make anythin
On Feb 22, 2010, at 05:20 , Nguyễn Đình Nam wrote:
> On Feb 22, 3:56 am, Eddy Nigg wrote:
>> On 02/21/2010 09:34 AM, Nguyễn Đình Nam:
>>
>>> The way to solve it is not to inform people of each potential attack,
>>> because there will be too many false positive, pushing people to just
>>> ignore i
On Feb 22, 3:56 am, Eddy Nigg wrote:
> On 02/21/2010 09:34 AM, Nguyễn Đình Nam:
>
> > The way to solve it is not to inform people of each potential attack,
> > because there will be too many false positive, pushing people to just
> > ignore it, rendering the scheme ineffective. The way to solve it
On 02/21/2010 10:56 PM, Eddy Nigg:
On 02/21/2010 09:34 AM, Nguyễn Đình Nam:
The way to solve it is not to inform people of each potential attack,
because there will be too many false positive, pushing people to just
ignore it, rendering the scheme ineffective. The way to solve it is to
let a sma
On 02/21/2010 09:34 AM, Nguyễn Đình Nam:
The way to solve it is not to inform people of each potential attack,
because there will be too many false positive, pushing people to just
ignore it, rendering the scheme ineffective. The way to solve it is to
let a small number of relevant and knowledgab
> If this solution would solve the problem in such an easy way, why isn't
> it already in use for more than a decade? Recent studies going at task
> with those accessing SSH servers have shown that most users simple edit
> their known_hosts file - those people are way more knowledgeable than
> the
On 02/21/2010 04:11 AM, Nguyễn Đình Nam:
I think you didn't look closely at my description.
The intrusion detection servers track the changes of certificates
belong to a host name over time, reported by user agent software
around the world, this is just like "Perspectives". If there is one
time t
> 1. How do you secure the connection to the perspectives server?
The software to be released with predefined intrusion detection
servers, each comes with it's own X.509 certificate, should be self
signed. It's a kind of "Auditive" mechanism, by using it, we should be
suspicious of any CA, so we wo
On 2010-02-20 08:46 PST, Nguyễn Đình Nam wrote:
[yet another promotion of "perspectives"]
Questions/issues:
1. How do you secure the connection to the perspectives server?
(This is a recursive problem)
2. How do you avoid false reports for the multiple servers that legitimately
claim to be th
I forget to mention, I aware there are two similar mechanisms:
"Perspectives": http://www.cs.cmu.edu/~perspectives/firefox.html
"Certificate Patrol": https://addons.mozilla.org/en-US/firefox/addon/6415
According to my analysis, my proposed mechanism has following
advantages:
* Easier to use: no in
Background
Recently I have read the problem of Mozilla and CNNIC. Many years ago,
I was a cryptography researcher, I worked on this problem when my
country – Vietnam – started working on a central PKI. Vietnam is
similar to China, the possibility of being cheated by rogue
certificates created under
20 matches
Mail list logo
