On Sat, 27 Dec 2008 13:55:45 +0100
Michael Ströder wrote:
> Patricia,
>
> we saw several strange things from Certstar during the last days, not
> just one mistake:
>
> 1. Spam e-mail to StartCom customers showing dubious business
> practices
Spam wasn't just sent to StartCom customers... From
I am a user. I am worried about MITM attacks.
Unlike most users, I'm technically and legally savvy enough to know:
1) Why to perform my due diligence
2) How to perform my due diligence
3) How to add the root into my store
However, I have additional problems that I can't deal with through
the st
On 12/27/2008 10:36 PM, Florian Weimer:
As a downstream distributor of Mozilla code,
StartCom is also a downstream distributor of Mozilla code...
I'd hate to roll out updates (especially security updates)
...which happens every two month anyway...
just because CAs start to play games with
On 12/27/2008 11:07 PM, Michael Ströder:
I meant the RA should also be audited during the CA audit.
This in turn would be similar to this
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_unconstrained_subordinate_CAs
At this stage I'm not proposing to
Florian Weimer wrote:
> Even if you've got the certificate, you need to attack IP routing or
> DNS. If you can do that, chances are that you can mount this attack
> against one of the domain-validating RAs, and still receive a
> certificate. So the browser PKI is currently irrelevant for practica
Eddy Nigg wrote:
> On 12/27/2008 05:10 PM, Michael Ströder:
>> Frank Hecker wrote:
>>> (Plus the expense of a full WebTrust for
>>> CAs audit is likely an order of magnitude higher than Certstar's
>>> probable revenues.)
>>
>> It's Comodo's business decision whether they delegate some tasks to an
>
* Eddy Nigg:
> On 12/27/2008 05:38 PM, Florian Weimer:
>>> Isn't that, by itself, a very good reason to take immediate action?
>>> Security should be default-fail rather than default-pass.
>>
>> This is not about security, this is about the presence or absence of
>> an obscure browser warning.
>
>
On 12/27/2008 03:07 PM, Gervase Markham:
This is extremely common. Certificates change hands. Failing to honour
root certificates which are no longer owned by the companies which
created them would break a significant proportion of the web. Microsoft
does not have a policy preventing this.
In
On 27/12/08 20:01, Eddy Nigg wrote:
On 12/27/2008 05:38 PM, Florian Weimer:
Isn't that, by itself, a very good reason to take immediate action?
Security should be default-fail rather than default-pass.
This is not about security, this is about the presence or absence of
an obscure browser warn
On 12/27/2008 05:38 PM, Florian Weimer:
Isn't that, by itself, a very good reason to take immediate action?
Security should be default-fail rather than default-pass.
This is not about security, this is about the presence or absence of
an obscure browser warning.
Huuu? Have you understood the
On 12/27/2008 05:10 PM, Michael Ströder:
Frank Hecker wrote:
(Plus the expense of a full WebTrust for
CAs audit is likely an order of magnitude higher than Certstar's
probable revenues.)
It's Comodo's business decision whether they delegate some tasks to an
external RA or not and whether the r
Michael Ströder wrote:
If e.g. a Linux distributor wants to ship Firefox and trims the list of
pre-installed trusted root CA certs is it still allowed to distribute
the resulting code as Firefox?
That's a decision for the people at the Mozilla Corporation who work
with Linux distributors and o
Frank Hecker wrote:
> John Nagle wrote:
>>As a user of SSL certificates in our SiteTruth system, which
>> attempts to identify and rate the business behind a web site, we're
>> concerned about CA reliability and trust. We've been using Mozilla's
>> approved root cert list for our system, and a
Ian G wrote:
> That "earlier story" has no real place here, IMHO. This is a forum for
> the discussion of technical, crypto, root and general PKI issues, by
> either dictat or convention. It is not a forum for the airing of
> general business complaints.
I agree that the effects of this whole st
On 12/27/2008 5:48 AM, Michael Ströder wrote [in part]:
> ro...@comodo.com wrote [in part]:
>> On Dec 24, 2:13 am, "Paul C. Bryan" wrote:
>>> 2. Are resellers subject to the same audits that Comodo presumably had
>>> to undergo to get its root certs added to Mozilla? Who performs, and
>>> who veri
* Paul C. Bryan:
> Presumably it was Comodo that underwent an audit to be added to
> Mozilla's roots, and Comodo should not be allowed to delegate trust to
> their resellers for domain validation. If, today, trust is delegated
> to their resellers, then we can't trust Comodo, period.
Many of the
On 12/27/2008 5:07 AM, Gervase Markham wrote [in part]:
> Hi John,
>
> You raise some important questions, but it's worth having clarity on a
> few matters of fact.
>
> John Nagle wrote [also in part]:
>>1.AddTrust, a company which apparently no longer exists, has an
>> approved
>> ro
* Hendrik Weimer:
> Frank Hecker writes:
>
>> My intent is to balance the disruption that would be caused by pulling
>> a root vs. the actual security threat to users. Right now we have no
>> real idea as to the extent of the problem (e.g., how many certs might
>> have been issued without proper
Ian G wrote:
> On 27/12/08 13:43, Eddy Nigg wrote:
>> So? Mozilla really shouldn't care about the business revenues of some
>> CAs. How is that relevant?
>
> Well, a normal lesson of business is that we can't get business people
> to agree to something if their revenues go down... PKI is business
Frank Hecker wrote:
> John Nagle wrote:
>>2.CertStar must separately undergo an audit to WebTrust standards,
>> and the audit report must be published.
>
> Certstar isn't a CA, and thus the WebTrust for CAs criteria are not
> necessarily a good fit for it.
If a CA delegates some tasks
Thank you:
"[…] Unfortunately Thawte's enrollment interface does not work
without Javascript. […]Thawte could silently change the behaviour of the
cert enrollment web
interface. […] to be 100% sure [the private key is not transferred] you have
to check that every time you go through this process.
On 27/12/08 13:43, Eddy Nigg wrote:
On 12/27/2008 02:16 PM, Ian G:
Indeed, this is the "Verisign buyout model"; outsource something new,
get huge, get bought out by Verisign.
What has that to do exactly with what Paul agreed to?
It doesn't matter in business principle whether it outsources a
On 27/12/08 13:34, Gervase Markham wrote:
sayrer wrote:
The truth is that we are basically unable to act without a lot of
collateral damage. We should keep this in mind with future security
technology. Relying on companies willing to take money for doing
absolutely nothing (not even the bare min
John Nagle wrote:
As a user of SSL certificates in our SiteTruth system, which
attempts to identify and rate the business behind a web site, we're
concerned about CA reliability and trust. We've been using Mozilla's
approved root cert list for our system, and are considering whether
we should
Eddy Nigg wrote:
> On 12/27/2008 02:34 PM, Gervase Markham:
>> One of the points of EV was to allow us to act against a CA without
>> massive collateral damage. We can remove EV status from a root without
>> disabling the root entirely.
>
> Which unfortunately isn't really effective for the issue
Gervase Markham wrote:
> We (Mozilla) would expect Comodo to be issuing certificates under any
> root it owns, whether the name on the root is its own or another's,
> in compliance with the Mozilla CA policy and the audits it has
> passed.
> [..]
> There are root certificates in the store which bea
ro...@comodo.com wrote:
> On Dec 24, 2:13 am, "Paul C. Bryan" wrote:
>> 2. Are resellers subject to the same audits that Comodo presumably had
>> to undergo to get its root certs added to Mozilla? Who performs, and
>> who verifies such audits? How often are they performed?
> No, the RAs are not su
Ian G wrote:
> On 26/12/08 00:36, Michael Ströder wrote:
>> Paul Hoffman wrote:
>>> At 7:16 PM +0100 12/25/08, Michael Ströder wrote:
I'd tend to punish a rogue CA by removing their root CA cert from NSS.
>
> I do not see a rogue CA. The evidence of the posts here suggests a flaw
> leading t
On 27/12/08 02:21, Paul C. Bryan wrote:
On Dec 26, 4:40 pm, Ian G wrote:
With respect:
This is a forum for the discussion of technical, crypto, root and general PKI
issues, by either dictat or convention. It is not a forum for the airing of
general
business complaints.
Are you characteriz
Hi John,
You raise some important questions, but it's worth having clarity on a
few matters of fact.
John Nagle wrote:
>1.AddTrust, a company which apparently no longer exists, has an
> approved
> root CA certificate. This in itself is troublesome.
This is extremely common. Certifi
patri...@certstar.com wrote:
> On Dec 27, 1:22 am, "David E. Ross" wrote:
>> I find these failures of Certstar's QA processes alarming when you
>> consider the purpose of certificates. That is, if you can't get a
>> simple canned message correct and allow several certificates to be
>> signed with
patri...@certstar.com wrote:
>
> How about creating certificate type that
What do you mean with "certificate type" here?
> is registered in a central
> database and require all CAs to check this DB before issuing new
> certificates? Once in that database no certificates could be issued
> for thi
On 12/27/2008 02:49 PM, Gervase Markham:
However, it doesn't seem to have made it to this list yet:
https://wiki.mozilla.org/Module_Owners_Activities_Modules
Mitchell and others are on the verge of creating this module now upon
request from Nelson, see mozilla.governance.
--
Regards
Signer
On 12/27/2008 02:34 PM, Gervase Markham:
One of the points of EV was to allow us to act against a CA without
massive collateral damage. We can remove EV status from a root without
disabling the root entirely.
Which unfortunately isn't really effective for the issue we are facing
today. Removin
I'll also mention that these CAs are supposed to be audited to
"financial services" levels. The root that it chains to is
EV-enabled.
The fact that audits didn't pick up on the discrepancies that Eddy
found between Comodo's CP/CPS and Robin's statements suggests that
Comodo's playing dirty pool,
Kyle Hamilton wrote:
> How would this work? Split nssckbi out to be managed by the non-code
> module owner, though a coder would need to be enlisted to finalize the
> decisions made by that person?
Non-code module arrangements don't require code changes.
As I understand it, having a "CA Certific
On 12/27/2008 02:16 PM, Ian G:
Indeed, this is the "Verisign buyout model"; outsource something new,
get huge, get bought out by Verisign.
What has that to do exactly with what Paul agreed to?
It doesn't matter in business principle whether it outsources a function
to a reseller, to its emplo
Dan Colascione wrote:
> Frankly, that's even *more* disturbing. It means that there are almost
> certainly unverified certificates in the wild, and that this problem
> is pervasive.
You mean, you wouldn't be disturbed at all if Comodo had done loads of
auditing and found absolutely no problems wha
sayrer wrote:
> The truth is that we are basically unable to act without a lot of
> collateral damage. We should keep this in mind with future security
> technology. Relying on companies willing to take money for doing
> absolutely nothing (not even the bare minimum they agreed to) is not a
> pleas
Michael Ströder wrote:
> Given the large amount of self-generated server certs this problem
> already exists.
Large number != large % of visits. A million Joe Publics might use the
Internet for 5 years to do their online shopping without once
encountering a self-signed cert or a certificate error
Kaspar Brand wrote:
> Michael Ströder wrote:
>> I'd love to have an option to forbid CRMFRequest calls...
>
> Not too difficult to achieve, actually. Just add this line to your
> prefs.js:
>
> user_pref("capability.policy.default.Crypto.generateCRMFRequest", "noAccess");
>
>> I personally don't
On 27/12/08 04:47, Paul C. Bryan wrote:
On Dec 26, 5:38 pm, Nelson B Bolyard wrote:
Clearly several participants in this discussion were surprised that a CA would
delegate the duty of validating domain control to an RA, and some opined
that a CA ought to perform that duty itself.
I certainly
On 27/12/08 12:09, patri...@certstar.com wrote:
On Dec 27, 3:21 am, Nelson B Bolyard wrote:
3) If some CAs agree to such an approach, and others do not, is it still
valuable?
This is also what Eddy pointed out. Everyone in the trusted group
would need to participate but browser vendors could
Michael Ströder wrote:
> I'd love to have an option to forbid CRMFRequest calls...
Not too difficult to achieve, actually. Just add this line to your
prefs.js:
user_pref("capability.policy.default.Crypto.generateCRMFRequest", "noAccess");
> I personally don't know whether the current Mozilla imp
On Dec 27, 3:21 am, Nelson B Bolyard wrote:
> I think you're suggesting a cooperative agreement among CAs, whereby
> once a cert was issued for a domain name by one CA, other cooperating
> CAs would refuse to issue a cert for that same domain name.
> Is that what you're suggesting?
Yes, but only
45 matches
Mail list logo
