On 23/05/17 14:08, ryan.sle...@gmail.com wrote:
> I think it should be a policy
OK. Are you able to propose wording and a location within the policy
(section 5.1) for both of these proposals? If you are willing to do
that, I'm happy to include it.
Gerv
--
dev-tech-crypto mailing list
On 19/05/17 17:02, Ryan Sleevi wrote:
> I support both of those requirements, so that we can avoid it on a
> 'problematic practices' side :)
But you think this should be a policy requirement, not a Problematic
Practice?
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
> There's a
Brian Smith filed two issues on our Root Store Policy relating to making
specific requirements of the technical content of certificates:
"Specify allowed PSS parameters"
https://github.com/mozilla/pkipolicy/issues/37
"Specify allowed encoding of RSA PKCS#1 1.5 parameters"
On 15/02/17 17:17, Martin Thomson wrote:
> Sure. Both NSS and Firefox support P-521. We still accept TLS
> handshakes that use it (for both key exchange and signing). I believe
> that it is also supported in webcrypto.
>
> I believe that Chrome doesn't support P-521 in TLS. We tried to
>
On 05/05/16 15:22, Zoogtfyz wrote:
> This is my recommendation for changes to the supported ciphersuits in
> Mozilla Firefox. I performed rigorous compatibility testing and
> everything works as advertized. I used Firefox telemetry data, SSL
> Pulse data, and my own tests to verify that *not a
On 07/04/15 17:32, Hanno Böck wrote:
Are you using DSA? Firefox removed DSA recently (which is good - almost
nobody uses it and it's a quite fragile algorithm when it comes to
random numbers).
Hanno's probably hit the nail on the head here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1073867
Hi Stefano,
On 02/04/15 22:06, stefano.forn...@gmail.com wrote:
Hi All, it seems the latest update to FF37 has broken some SSL
functionality.
Are you sure the problem has begun in 37, and not 36, or 35, or an
earlier version?
Are you able to see how many connection attempts Firefox makes?
Discovered today:
https://whatsmychaincert.com/
That seems like a great resource for when we get those emails that say
my cert isn't working in Firefox - why?
Thanks to Andrew of SSLMate for putting the site together.
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
I think you may have buried the lede a little bit here, Rick :-)
The questions are:
* Does NSS correctly handle the case where a SHA-1 root signs a SHA-2
CRL or OCSP response?
* Which version of Firefox first supported SHA-2?
I believe the answer to the first question is Yes; NSS doesn't
On 07/08/14 23:17, fhw...@gmail.com wrote:
Curious to know the process by which cert holders will get their
certs added to these lists. How much of that flow and the necessary
security measures have been worked out?
Cert holders get their certs added to CRLs maintained by their CA. Cert
I am generally in favour of this plan - I think it's the right way to
go. I am not sure we will ever get to hard-fail for plain OCSP, but I am
very happy for that to be a data-driven decision somewhere down the line.
On 01/08/14 03:07, Richard Barnes wrote:
There's one major open issue
On 30/01/14 13:09, Kai Engert wrote:
You probably refer to the functionality and user interface that was
present in past versions of Firefox, but which got removed:
https://bugzilla.mozilla.org/show_bug.cgi?id=802302
The most recent software that still contained is probably Firefox 17
ESR.
On 06/12/13 13:07, firef...@gmail.com wrote:
The reason I ask is the following: We are out to implement an
alternative trust model, consisting of an external (but local) Java
application, managing the trust validation etc., and a Firefox
extension acting as an interface between the user, the
Hi everyone,
Following Microsoft's announcement re: SHA-1, some CAs are asking
browser and OS vendors about the ubiquity of SHA-256 support. It would
be a help to them if we could say:
- Which version of NSS first supported SHA-256
- Which versions of Mozilla/Firefox/SeaMonkey/Thunderbird that
On 01/11/13 09:41, Dirkjan Ochtman wrote:
His Bugzilla status suggests Brian might have left Mozilla:
Brian Smith (:briansmith, was :bsm...@mozilla.com; NEEDINFO me if you
want a response)
No, Brian hasn't left Mozilla - he just decided to use a different
primary email address.
I too would
On 11/10/13 21:50, Wan-Teh Chang wrote:
I would use a timeout of 5 seconds. 3 seconds seem a little short.
I agree 10 seconds are too long.
Can you expand on what criteria you are using to make these judgements?
Fetching the OCSP response takes 2RTT, as Camilo said. So if your RTT is
1000ms
On 09/08/13 03:30, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
This proposal promotes ECC.
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
Schneier: Prefer conventional discrete-log-based systems over
elliptic-curve
On 22/08/13 19:21, Robert Relyea wrote:
The attack profile protection of PFS versus non-PFS is basically two points:
1) some government agency could force a server to give up it's private
keys and decrypt all the traffic sent to that server. But we already
know that government agencies with
On 19/08/13 04:07, Brian Smith wrote:
When risk is there to a user of having a network eavesdropper able to
tell that they are using a particular browser? If I had an exploit for a
particular browser, I'd just try it anyway and see if it worked. That
seems to be the normal pattern.
One
On 15/08/13 19:01, Robert Relyea wrote:
That's an instrumentation issue. It was true back in 1995/6 when the
code was added I don't know how true it is today. My guess is the
biggest compatibility issue is self-issued certs, not CA issued certs...
but then again most of those are
On 09/08/13 18:12, Brian Smith wrote:
No, each combination is hard-coded into its own distinct code point that is
registered with IANA:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.
This is a design choice based on the fact that many crypto modules
Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline
requirements
Date: Thu, 8 Aug 2013 17:10:36 +
From: Kelvin Yiu kelv...@exchange.microsoft.com
To: jeremy.row...@digicert.com jeremy.row...@digicert.com, 'Gervase
Markham' g...@mozilla.org
CC: 'CABFPub' pub
Hi Brian,
On 09/08/13 03:30, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
Suggestions for improvements are encouraged.
Thanks for this. Here are my questions:
* Can you provide some background or references on exactly how
ciphersuite construction
On 17/06/13 10:58, Chris Newman wrote:
I think these would be good usability issues to address. When I
contributed that code, I was a Sun Microsystems employee and Sun was an
NSS contributor. However, I can not maintain or update that code as my
present employer does not have a code
On 17/06/13 17:11, Robert Relyea wrote:
On 06/17/2013 10:58 AM, Chris Newman wrote:
I'll mention one other usability issue. I am getting pressure from my
employer to stop using NSS due to the MPL 2 license. I got less
pressure when I could use NSS under the LGPL 2.1 branch of the
tri-license.
On 21/03/13 23:19, Kai Engert wrote:
We are no longer using Mozilla'a CVS server, but have migrated to
Mozilla's HG (Mercurial) server.
Hooray! :-)
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 13/02/13 20:55, David Dahl wrote:
The main issue is: What does Mozilla actually need here? What is
Mozilla's official policy or thinking on a crypto API for the DOM?
As you are the Mozillian with most experience in this area, I'd say that
insofar as we will ever have an official policy, it's
On 09/03/12 17:56, Brian Smith wrote:
The first question is: Should we change our UI to be the same as
other browsers? My answer is no. It *is* a good idea to show the root
certificate's organization name in this part of the UI. But, it is
also important to show all the intermediate
On 19/02/12 04:30, Jan Schejbal wrote:
A different interesting approach for a punishment could be removal of
the ability to create Sub-CAs. This would not put a CA out of business
like other solutions, but hurt it and most importantly, remove an
extremely risky ability.
This could probably be
On 09/02/12 12:54, Rob Stradling wrote:
We've calculated that there are currently ~53,000 revoked Server
Authentication certs that were issued by Comodo's CA systems, each with
a serial number of 16 bytes (+ a leading zero byte if required to ensure
it's not treated as a negative number). That
On 13/01/12 00:01, Brian Smith wrote:
Ryan seems to be a great addition to the team. Welcome, Ryan!
Ryan - could you take a moment to introduce yourself? (Apologies if I
missed an earlier introduction.)
* We will drop the idea of supporting non-NSS certificate
library APIs, and we
On 04/01/12 00:59, Brian Smith wrote:
5. libpkix has better AIA/CRL fetching: 5.a. libpkix can fetch
revocation information for every cert in a chain. The non-libpkix
validation cannot (right?). 5.b. libpkix can (in theory) fetch using
LDAP in addition to HTTP. non-libpkix validation cannot.
On 29/11/11 17:34, Brian Smith wrote:
What I said/meant is that inquiries regarding legal issues should be
made to Mozilla Legal instead of the technical areas of bugzilla or
the technical mailing lists. I do not know if anybody has contacted
our legal team or if there is a reason to. I just
On 16/11/11 16:38, Filipe wrote:
I want to use some encryption standards on the add-on. However, a
javascript implementation does not present the best efficiency. I was
wondering if it is possible to use NSS or PSM as a xpcom component
(like using nsIProcess or so) in order to run some crypto
On 11/10/11 05:02, Nelson B Bolyard wrote:
I'd say it's going to be difficult for the typical scripting language to do
the recommended instructions. How about putting the distrusted certs and
their trust objects in a separate file in the CVS repository?
What particularly do you think is
On 11/06/11 12:03, Michael Ströder wrote:
This means if the user accidently sent in contact information in an
e-mail footer this information is also disclosed. If not already there
you should put a strong hint on the web page that the signed S/MIME
messages should not contain any private data
Summary: in order to promote the ubiquity of OCSP stapling, please test
Apache httpd 2.3.x and submit your results. Then, Apache might switch it
on by default.
Apache httpd 2.3.x has recently entered beta, so presumably a stable
2.4.0 release is on the horizon. This will be the first stable
On 01/03/11 19:30, Wan-Teh Chang wrote:
I just expressed my interest in being a mentor for an NSS project on that page.
Do mentors need to propose projects? I thought it's the students who
should submit proposals as part of the applications. I think it's
better that way because it implies the
On 25/02/11 14:17, Jean-Marc Desperrier wrote:
Gervase Markham wrote:
Are any of you interested in submitting a proposal for a Summer of Code
project for Bugzilla this year, and mentoring it?
https://wiki.mozilla.org/Community:SummerOfCode11:Brainstorming
NSS has done several projects
On 25/02/11 23:55, John Dennis wrote:
Yes, that's a deficiency. The lack of a project page is part due the
fact I'm the only person supporting the project and the difficulty of
getting the right Mozilla mojo to maintain public pages. So I do
apologize for that, it really should be done.
File
Hi NSS team,
Are any of you interested in submitting a proposal for a Summer of Code
project for Bugzilla this year, and mentoring it?
https://wiki.mozilla.org/Community:SummerOfCode11:Brainstorming
NSS has done several projects in the past (recently, RSA-PSS signatures
and some TLS
On 05/02/11 21:13, Nelson B Bolyard wrote:
2) After 14 years of working on SSL/TLS for browsers, I can tell you that
browsers will all ignore the paragraph that says Clients SHOULD NOT allow
users to force a connection I suppose that surprises no-one.
It's all about precedent. If all
On 01/02/11 18:08, Matej Kurpel wrote:
@Q4: I am doing this as my diploma thesis, it works for Windows Mobile
phones/PDAs and is tested with Firefox and Thunderbird. Certificate
login works fine in Firefox.
Can you tell us a bit more about this?
How does what you are doing compare to
On 01/02/11 20:02, Marsh Ray wrote:
Whether or not client certs count as a second factor is somewhat
philosophical. In some sense, the private key stored in the browser
functions as another something you know like a password. If the PC is
pwned, they can get the private key too.
If your
On 01/02/11 23:03, Robert Relyea wrote:
1) use request/not require certificate. If a certificate is supplied,
that will show up in the initial handshake. The certificate will tell
the server which account and you can bypass login altogether. If no
certificate is supplied, you can bounce to user
Dear crypto-hackers,
Your thoughts on the following problem would be appreciated.
Goal: fix bug 570252. Provide 2-factor authentication for some Bugzilla
accounts.
https://bugzilla.mozilla.org/show_bug.cgi?id=570252
Sub-goal: do it in a way which doesn't involve purchasing or running
On 22/10/10 19:23, Nelson B Bolyard wrote:
This is clearly a failure of the new newsgroup moderation, and of the
news-mail gateway's filter ... unless those things are not yet in place.
They are not yet in place; as the tracking bug says, both Giganews and
Google have hit various problems
On 20/10/10 19:36, Nelson B Bolyard wrote:
I think I'm responsible for (moderate) this group, and I only just learned
about this from this posting of yours. Nonetheless, I'm
quite happy for this group to be among your guinea pigs. Thanks.
Hi Nelson,
I'm sorry, I thought you were looped in
At 11pm Pacific Time on Tuesday night (6am UTC on Wednesday morning) we
are implementing[0] the new discussion forums anti-spam plan[1] on the
following guinea pig groups:
mozilla.community.philippines
mozilla.governance.mpl-update
mozilla.dev.tech.crypto
mozilla.tools
This has been agreed
On 21/07/10 07:26, Amax Guan wrote:
I think basically it's because they have too much Cert to issue (One for
each user), it cost too much money, and they do not want anyone else to
know how many users they have, and their names, including the CA.
Right. I am not suggesting that they get client
On 20/07/10 04:23, Amax Guan wrote:
I've got a problem help China Construction Bank(CCB for short)
support Firefox. CCB has its own CA root, used to issue certificate to
his users, and they issued some server cert using this cert.
Do you know why they cannot buy a cert from a trusted CA,
On 21/05/10 12:11, Eddy Nigg wrote:
And your whole arguing starts to become ridiculous.
Not at all. He is saying that the browser cannot tell whether a
certificate problem is the result of an attack or the result of a
misconfiguration. And that's absolutely correct. Isn't it?
Otherwise
On 21/05/10 05:36, Matt McCutchen wrote:
I'm not claiming that the user knows. I only said that if there is in
fact no impersonation, then the error is a false positive.
This seems a fine definition to me.
If the browser says OMG - someone might be trying to MITM you, and
no-one is, that's
On 18/05/10 15:54, johnjbarton wrote:
I mean that starting a design from the point of view that the users have
faulty judgment will almost certainly lead to software that fails.
If users did not have faulty judgement, and always made correct security
decisions, then there would be no
On 18/05/10 05:20, johnjbarton wrote:
Many of our potential users are inexperienced computer users, who do not
understand the risks involved in using interactive Web content. This
means we must rely on the user's judgement as little as possible. As
Edward Felten says, given the choice between
On 17/05/10 23:16, Robert Relyea wrote:
A more telling quote is:
For example, much of the
advice concerning passwords is outdated and does little
to address actual threats, and fully 100% of certificate
error warnings appear to be false positives.
Although he now admits that
On 23/04/10 19:33, Nelson B Bolyard wrote:
With my list moderator hat on, I ask this list:
what is your opinion of the Hack in the Box posts to this list?
Spam.
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 16/04/10 06:15, Nelson Bolyard wrote:
How does it signify unencrypted Javascript or CSS content?
Some of them use alert(). Hacky, but effective. The idea is that you
invoke it as required rather than having it turned on all the time. It's
for web authors, not for every-day users.
Gerv
On 14/04/10 12:15, Developer wrote:
Why I can not know what part of page is unencrypted?
I see a warning of some parts are unencrypted, but what parts?
There are bookmarklets and greasemonkey scripts which will search for
and highlight the unencrypted content.
Gerv
--
dev-tech-crypto
On 26/03/10 19:04, Kai Engert wrote:
thanks a lot for your feedback. I've created a graphical presentation
for the client authentication part:
http://kuix.de/mozilla/sslauth/cli-v1-pres/
I still haven't had a chance to look at this :-(( I'm very sorry.
(I do have a good excuse, though:
Hi Kai,
I've been looking at your documents, but I do think this is a case where
a picture is worth a thousand words. Do you have any plans to provide UI
mockups?
On 16/03/10 23:12, Kai Engert wrote:
In short, we'd like to stop the current prompts and implement a better
user interface.
I
On 17/03/10 14:57, Wan-Teh Chang wrote:
Please use the official page instead:
https://wiki.mozilla.org/Community:SummerOfCode10
You can't edit that page :-) Put stuff on the Brainstorming page and
I'll move it over.
Gerv
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
On 15/03/10 18:47, Wan-Teh Chang wrote:
None of us has signed up to be a SoC mentor. I don't know if the
deadline has passed.
No relevant deadlines have passed :-) If someone in this group wants to
offer to be Hanno's mentor, then Hanno can put that information in his
application and we
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
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
Firefox uses OCSP but, by default, any response other than a definite
is revoked response is treated as is not revoked. There is a user
pref that allows the user to change that, so that any response other
than is not revoked is treated as is revoked.
IMO, we need to be smarter about that.
On 24/06/09 23:49, Nelson B Bolyard wrote:
S/MIME's protection of message authenticity, integrity and confidentiality
are unbroken and unsurpassed. It is implemented in most Windows, Mac and
Linux email MUA's today. But only a small minority of mail users use MUAs
that reside on their own
On 15/06/09 18:18, Glen Beasley wrote:
I can do the same for the NSS and NSPR?
The wisest thing to do would be to complete the migration and then put a
redirect in place. Is anyone actively working on migrating the remaining
content?
Gerv
--
dev-tech-crypto mailing list
On 14/05/09 00:38, Nelson B Bolyard wrote:
I suppose that, on principle, you're right. In the past, I would have
readily done so. But today my idealism is severely tempered by the
pragmatic realization that there are now hundreds of open bugs and RFEs
that I have filed, some years old, that
On 11/05/09 20:32, Nelson B Bolyard wrote:
Ideally, one could tell Tryserver to Take Firefox source from the current
branch for FF 3.0.x or FF 3.5 (from CVS or Hg, as appropriate), plus NSS
from CVS tag X, plus this small patch, and build it, but presently that
does not seem possible.
Your
On 04/05/09 20:27, Andrews, Rick wrote:
Are there any safeguards in place to prevent this hack from succeeding?
Of course not. Code is code - you can make it do anything. It's just
ones and zeroes. They could make the hacked version show your evil
website while having the URL bar display
On 07/04/09 15:38, Jean-Marc Desperrier wrote:
No, the keygen tag is just too bad to be updated to something really
useful.
Then you need to persuade Hixie not to standardize it, otherwise people
will be using it for a long time :-)
Gerv
--
dev-tech-crypto mailing list
On 26/02/09 11:05, Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
[...]
Only CAs are relevant if at all. You don't expect that 200 domain names
were registered by going through anti-spoofing checking and
measures, do
On 23/02/09 23:54, Eddy Nigg wrote:
How to prove? Does Mozilla buy domain names (or purchase certificates)
from time to time in order to govern its policies?
We rely on good citizens like you to let us know when there's a problem
:-) We don't regularly attempt to break the security of CA cert
On 23/02/09 17:58, Paul Hoffman wrote:
Jean-Marc, you have fallen for Gerv's wishful thinking and security
theater. There are multiple TLDs on that list that have policies that
say *nothing* about preventing homograph spoofing.
Every TLD on that list should have a published set of characters
On 19/02/09 17:36, Ian G wrote:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
You'll need to elaborate on what you are saying here, because the way I
read it, he _hates_ the new FF3
Eddy Nigg wrote:
So IMO you get points for prompt disclosure and fixes, but in the end
you messed up just like Comodo and CertStar did.
Nonono :-)
I see the main differences as followed and I believe the main
differences are policy wise (and allow me to comment on this since you
made the
Jean-Marc Desperrier wrote:
Gerv, what about changing the Firefox SSL page/implementation so that in
that situation, for those 99% of the market, it gives the most
informative information, non scary, non blocking possible ? Even when
there was an error in the configuration ?
I'm not sure we
Robertss wrote:
Thanks, Gerv! I went through each of the providers websites and found
their main support pages. I have added links to them on this page:
http://www.sslshopper.com/ssl-certificate-not-trusted-error.html
I can tell you that you have covered 96% of the CA market with the list
you
Paul Hoffman wrote:
Having a separate policy list would help the technology folks focus
on what they do best. It would also help keep the policy people keep
their discussion out of bits-on-the-wire and up in the what should
we be doing layer.
OK, then.
Nelson B Bolyard wrote:
In Mozilla products, no roots have ever been SGC enabled.
Some roots were, and still are, marked as trusted for SSL Step Up.
Here's a list.
Is the marking internal to or external to the cert? The fact that you
say no certs have ever been SGC-enabled makes me suspect
Robertss wrote:
Thanks for pointing this tool out. I actually helped create it. I
included a link to a page that explains why an error is given when an
Intermediate certificate cert is missing but I didn't include specific
instructions on how to fix it because each certificate provider is
Jean-Marc Desperrier wrote:
But by far the most interesting thing on the site is the list of ssl
sites that are *still* using compromised keys, established through that
extension :
http://www.codefromthe70s.org/sslblacklist-badcerts.aspx
Hmm. walmart.com is the big hitter on that list.
Does anyone know where I can find a definitive list of browsers for whom
SGC is helpful? That is to say, a list of browsers for which, if I
connected to a site with an SGC certificate, would provide a higher
grade of encryption than if I connected to an identical site with a
non-SGC certificate?
I just came across this:
http://www.sslshopper.com/ssl-checker.html
Rather nice, particularly for people with intermediate cert chain
errors. It would be even better if there was an independent version of
such a tool, which could link you through to the fix it pages for
certificate providers who
Eddy Nigg wrote:
On 01/05/2009 01:36 AM, Nelson B Bolyard:
3. I wonder if the non-developer topics are already within the scope of
another extant low-traffic list, namely dev-security (a.k.a.
mozilla.dev.security), except that I think the new list does not belong
in the dev hierarchy.
Nelson B Bolyard wrote:
3. I wonder if the non-developer topics are already within the scope of
another extant low-traffic list, namely dev-security (a.k.a.
mozilla.dev.security), except that I think the new list does not belong
in the dev hierarchy.
In an ideal world, it wouldn't, but it
Florian,
Thank you for bringing this to my attention.
Florian Weimer wrote:
But the EV certificate was issued to SEB AG, a different legal
entity. (SEB AG, in turn, is part of Skandinaviska Enskilda Banken
AB.)
Are you able to outline the exact corporate relationship between these
three
Ben Bucksch wrote:
I propose to announce that we'll stop supporting MD5 in 3 months, and
ask website owners to get new certs.
On the basis of any known risk?
The current attack requires the attacker to be able to get a cert signed
for a key they control. If all CAs stop using MD5 (which they
Paul Hoffman wrote:
I propose that Mozilla form a new mailing list,
dev-policy-trustanchors. The topics for that list would include:
- All new trust anchors being added to the Mozilla trust anchor pile
- Proposals for changes to the Mozilla trust anchor policy -
Complaints about particular
Florian Weimer wrote:
Section 18 does not require that the domain holder is aware of the
application.
Section 18 requires that the domain holder _be_ the applicant.
To verify Applicant's registration, or exclusive control, of the domain
name(s) to be listed in the EV certificate, the CA MUST
Jan Schejbal wrote:
I suggest an universal mechanism (integrated or as an extension) than
can be fed rules about certificates, CAs and sites and showing warnings
or interrupting connections where necessary.
I'm sure such a flexible system would have its uses. Coordinate with the
NSS and PSM
Eddy Nigg wrote:
As I see it, our case indeed was a bug, the Comodo case was negligence.
There is no clear line between one and the other. You are saying the
Comodo case was negligence because the bug was so obvious that they
should have spotted it. But the obviousness of bugs is a gradated
Ian G wrote:
On Thu, Jan 1, 2009 at 1:29 PM, Gervase Markhamg...@mozilla.org wrote:
Ian G wrote:
My personal view of Mozilla is this: the ecosystem is developer-led.
But the ecosystem isn't our representative on the CAB Forum. Our
current representative is Johnathan Nightingale, our Human
Eddy Nigg wrote:
For example?
Anything out of this list: https://www.startssl.com/?app=30#requirements
You want us to make a IV certificate which can be issued to businesses
without verifiable physical existence and business presence?
You mean that want a price point in between DV and EV?
Ian G wrote:
Hmm. Then I misunderstand completely. Are we talking about Mozilla
delivering updates to Mozilla users, or are we talking about general
code-signing certificates for the ecosystem of plugin developers?
My understanding was the former. If it's the latter, this entire
discussion
Florian Weimer wrote:
Organizations not on this list can usually get an EV certificate
through a corporate sponsor. The EV process does not verify that the
party to which the certificate is issued is the actual end user, or
that it is the legal entity which controls the domain name mentioned
Ian G wrote:
My personal view of Mozilla is this: the ecosystem is developer-led.
But the ecosystem isn't our representative on the CAB Forum. Our
current representative is Johnathan Nightingale, our Human Shield and
security and user experience expert.
Gerv
Ian G wrote:
2. In general, such a group will reject any proposal that appears to
favour one member against another; but they will accept any proposal
that requires the same amount of additional work, and increases the
power of the group. In other words, rejection of internal competition,
Ian G wrote:
Hmmm, odd that Frank views EV as ecommerce and here we see another view
of EV as technical delivery of updates.
I think that's a misrepresentation of both Frank's and my position. I
don't think Frank said that EV was _only_ for ecommerce, and I certainly
didn't say that it was
1 - 100 of 200 matches
Mail list logo
