Nelson Bolyard wrote:
Gerv agreed with this when he wrote:
Yes, and actually, SSL goes much further than DNSsec. The latter is
good to prevent DNS spoofs and is much-needed, but it does nothing to
protect the content.
(This was me, not Gerv, BTW.)
In fact, I have asserted many times that
Gerv, thank you for the useful objections in this mail! Seriously - I
mean it! You've touched a few points (some of it was already discussed,
but never mind), which require either a good answer or some improvement...
Gervase Markham wrote:
You misunderstand my concern - I apologise for not
Gervase Markham wrote:
Right. But if I promise you a pony, it doesn't mean you'll get one.
Sure, but if a false promise might have some consequences, you'll think
about it twice, if you it's worth promising me a pony, if in fact it is
a donkey ;-)
There's a fine line to walk between
Ben Bucksch wrote:
(You *may* be thinking of DV (Domain Validation) and Class 1 SSL
certs. These are indeed insecure and make SSL a joke. They were a
really bad idea and that is one of the reasons behind EV.)
Ben, the reason behind EV (or any higher verification in that respect)
is about the
Heikki Toivonen wrote:
Alaric Dailey wrote:
than doing things right. For example SSL for identification is
worthless without DNS being secured, and no-one on any list wants to
talk about that. Unfortunately, the number people who actually
I don't understand how you can claim this.
Ben Bucksch wrote:
I would much rather have more information about the existing certs ...
At very least this gives ME the chance to decide rather than giving me
a false sense of security.
You already have that info with Tools | Page Info (in Firefox; Seamonkey
in View menu IIRC), Security tab.
Ben Bucksch wrote:
(You *may* be thinking of DV (Domain Validation) and Class 1 SSL certs.
These are indeed insecure and make SSL a joke. They were a really bad
idea and that is one of the reasons behind EV.)
Well, even DV certs are supposed to be only issued to the person in
control of the
Gervase Markham wrote:
Oh, and I'm sure we're taking patches for DNSSec support in Firefox.
Aren't we?
This however would be a very good idea!
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
___
dev-security mailing
Oh, and I'm sure we're taking patches for DNSSec support in Firefox.
Aren't we?
No, but its a good idea.
Yes, and actually, SSL goes much further than DNSsec. The latter is
good to prevent DNS spoofs and is much-needed, but it does nothing to
protect the content.
Actually, you could
This is probably my last response in this thread, since I'm about to stop
reading it altogether (as so many others already have, I should note), but I do
have to respond to this, because there's hope that a reasoned response would
have effect, unlike in some of the other subthreads.
Alaric
Boris Zbarsky wrote:
Alaric Dailey wrote:
If DNS were secure, then attempts to use a stolen cert would be thwarted.
Not particularly. As someone pointed out, anyone who steals a cert and
can affect the routing of your packets can screw you.
Not if we were to strengthen the rules by saying
Alaric Dailey wrote:
As far as a fix for DNS, everyone hates hearing it, but the fix is
already out there no one wants to use it though
http://www.dnssec.com
I wouldn't say nobody wants to use it. I'd love to use it. See, e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=342242 . I think
Alaric Dailey wrote:
Sure even if we don't
steal the cert, most users don't read error boxes so you could redirect
them and use a fake cert.
This is again an orthogonal problem. Browser handling of things like
hostname/cert mismatches is abysmal. If they don't match, we should not show
Eddy Nigg (StartCom Ltd.) wrote:
Johnathan Nightingale [EMAIL PROTECTED] wrote:
Imagine that we found a way to clearly present to the user:
+ Your connection is encrypted
+ The site's identity has been verified
+ You've been here many times before
+ This site is trusted by (your friends |
Johnathan Nightingale wrote:
1. To a first approximation my sense is that, unsurprisingly, EV and
Eddy's proposal are trying to accomplish the same thing: strengthening
the internet's TLS/SSL certificate infrastructure to provide stronger
identity verification.
Actually, I'm afraid I
Gervase Markham wrote:
Eddy Nigg (StartCom Ltd.) wrote:
That's right! But the audit confirms exactly that (in your example,
no verification). The CA will have to mark its certificates compared
to its policy which was audited accordingly.
Why will they have to?
Because they would like to
Nelson Bolyard wrote:
Exactly. But there IS NO following information.
The page says:
Unique Identifier
CUI:1869067182
Domain Name:registerfly.com
Country:US
State: New Jersey
Locality: Boonton
Organization: RegisterFly.com, inc.
Disclaimer: The following
Alaric Dailey wrote:
than doing things right. For example SSL for identification is
worthless without DNS being secured, and no-one on any list wants to
talk about that. Unfortunately, the number people who actually
I don't understand how you can claim this. SSL *is* the solution to
Alaric Dailey wrote:
Heikki Toivonen wrote:
Alaric Dailey wrote:
SSL for identification is worthless without DNS being secured, and
no-one on any list wants to talk about that.
I don't understand how you can claim this. SSL *is* the solution to
insecure DNS. Could you explain?
I
Howdy all,
First of all I'd like to thank all the contributors to this thread, but
particularly Eddy for starting it, and Gerv, Ben and Nelson for
alternately acting as supporters and foils. As someone new to Mozilla
(the company that is, I'm quite familiar with the app, of course) it is
Hi Johnathan,
Welcome to this thread! Let me try to provide some answers and
thoughts...so don't expect my reply to be much shorter than your post ;-)
Johnathan Nightingale wrote:
my wand is not yet so magical and my power not yet so great that me
saying something makes it law.
Oooo :-( And
Johnathan Nightingale wrote:
The second part is critical, because one thing I haven't seen reflected
much in this thread (for obvious reasons) is that a cert is not the only
source of info we have here. We have a user's browsing history (Note:
I posted some comments on this exact topic a few
Nelson Bolyard wrote:
Gervase Markham wrote:
Ben Bucksch wrote:
Actually, not even that is necessary. Classes each have their own root
cert, so we can simply match root certs to level in our software,
using a list that is just as hardcoded as our root certs, and matches
the assigned
Gervase Markham wrote:
- Mozilla writes loads of code to detect each different type of CA
certificate and make sure that NSS knows what level it corresponds to
(or are we doing that bit by asking the CAs to include new OIDs?)
YES! Eddy explicitly said that. My do this all ourselves was just a
Ben Bucksch wrote:
Actually, not even that is necessary. Classes each have their own root
cert, so we can simply match root certs to level in our software, using
a list that is just as hardcoded as our root certs, and matches the
assigned levels.
That assumes CAs only issue one type of cert
Eddy Nigg (StartCom Ltd.) wrote:
Fist of all the proposal tries to structure and define SSL certificates
in the Mozilla CA policy first and foremost, about something which is
common practice. It nowhere says how, if and when the UI should
differentiate.
Oh come on, Eddy. Are you telling us
Eddy Nigg (StartCom Ltd.) wrote:
Gerv, I think you are concentrating too much on what Level 2 means,
instead of trying to see the whole picture first and which problem the
proposal tries to solve. But here a few thoughts about Level 2, since
you are insisting on it. First a few facts:
- This
Eddy Nigg (StartCom Ltd.) wrote:
Sorry? Gerv, please open a bug at bugzilla with the request to remove
all CA certificate from the NSS certificate store on the grounds, that
there is no auditing to make sure the CA was honest in terms of doing
the correct amount of verification.
I'd like to.
They are a Geotrust reseller, but also have issued hundreds of ssl
from their own FlySSL CA: http://www.registerfly.com/ssl/
They have no CPS or other documentation posted - just the statement
The following information has been self-reported by the entity to
which it relates for the purpose of
[EMAIL PROTECTED] wrote:
They are a Geotrust reseller, but also have issued hundreds of ssl
from their own FlySSL CA: http://www.registerfly.com/ssl/
It's irrelevant! There is no FlySSL in the Mozilla certificate store.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone:
Looks like there's a mix of FlySSL certs out there. Many of them are
issued from Geotrust's RapidSSL (with no reference to FlySSL in
them). But there are also many from the
ResellerFlyCertificateServices CA, which is under Comodo's AddTrust
root.
___
Boris Zbarsky wrote:
Given 4 levels of infrastructure, there could be either more or fewer
than 4 levels in the UI. As a dumb example, the UI could have two
levels: safe and not safe, where safe would be level 3 or 4
certificates that you've bookmarked before or level 2 certificates that
Boris Zbarsky wrote:
Given 4 levels of infrastructure, there could be either more or fewer
than 4 levels in the UI. As a dumb example, the UI could have two
levels: safe and not safe, where safe would be level 3 or 4
certificates that you've bookmarked before or level 2 certificates that
Gervase Markham wrote:
But the more levels we have, the more work it is for us and the CAs to
classify certificates and products. If this distinction is not reflected
in the UI, that work is wasted.
I didn't suggest that it's not reflected in the UI. Just that it's not the only
thing
Ben Bucksch wrote:
Gervase Markham wrote:
Right. But if you have four levels in the infrastructure, that sort of
implies four levels in the UI. And if it turns out that four levels in
the UI is impossibly confusing, then having four levels in the
infrastructure is unnecessary.
Not really,
Gervase Markham wrote:
On what basis would you mark a level 2 certificate as safe? How can a
user make such a decision safely?
Gerv, I think you are concentrating too much on what Level 2 means,
instead of trying to see the whole picture first and which problem the
proposal tries to solve.
Gervase Markham wrote:
Except that it would be an enormous amount of effort. There are 44 CAs
currently in Firefox, and 20 more in the queue.
So?
Each may have between one and ten different products.
That's why we propose the Mozilla CA policy defines this structure and
provide a framework
The project you propose is monumental in terms of 1) categorizing the
hundreds of certificate classes offered by the dozens of CAs, and 2)
auditing compliance with the new tiers. It could also take up to
three years to bring the new classification system online, assuming
CAs would only issue
Hi Mister Charter77,
It would be nice, if you would post as a person and not as an email
address...
[EMAIL PROTECTED] wrote:
The project you propose is monumental in terms of 1) categorizing the
hundreds of certificate classes offered by the dozens of CAs, and
Again no! It was explained
Ben Bucksch wrote:
Not really, you may want to treat some levels (including self-signed
and plain HTTP,
Considering plain http out of the scope of SSL so...Self-signed is
actually Level 0, which I omitted from the proposal, because it has no
meaning, except if you explicit agree to accept
Hi Mister Charter77,
[EMAIL PROTECTED] wrote:
Currently the UI is the same for all SSL, no matter the
quality. You are proposing to use the UI to differentiate between
grades of SSL ...
Fist of all the proposal tries to structure and define SSL certificates
in the Mozilla CA policy first and
Eddy Nigg (StartCom Ltd.) wrote:
to add the new OIDs.
Yes, this is the only requirement really.
Actually, not even that is necessary. Classes each have their own root
cert, so we can simply match root certs to level in our software, using
a list that is just as hardcoded as our root certs,
Hi Ben,
Ben Bucksch wrote:
Actually, not even that is necessary. Classes each have their own root
cert, so we can simply match root certs to level in our software,
using a list that is just as hardcoded as our root certs, and matches
the assigned levels.
So your idea might be a good one,
Eddy Nigg (StartCom Ltd.) wrote:
Following discussions both in private and at the dev-security mailing
list of Mozilla with various participants, we decided to put forward the
following initial proposal of a framework for the handling of SSL/TLS
and S/MIME digital certificates in Mozilla
Hi Gerv,
Gervase Markham wrote:
Just to be clear: this is, at heart, a UI proposal, isn't it? You want
the UI to differentiate between these four levels, rather than just
the one level (as now) or two levels (as IE 7 does with EV)?
Before you can do anything with the UI, there needs to be an
Eddy Nigg (StartCom Ltd.) wrote:
I'm sorry, but I can't work it out - what does the abbreviation
resp. stand for?
It stands for respective.
Ouuups, it stand for Respectively of course...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
Following discussions both in private and at the dev-security mailing
list of Mozilla with various participants, we decided to put forward the
following initial proposal of a framework for the handling of SSL/TLS
and S/MIME digital certificates in Mozilla products. The trigger for
this
47 matches
Mail list logo
