Kaspar Brand wrote, On 2008-12-27 03:21:
Michael Ströder wrote:
I personally don't know whether the current Mozilla implementation of
crypto.generateCRMFRequest includes the private key of an encryption
cert.
Only if you tell it do so, and only if it's a key-exchange-only key. [1]
Fost1954 wrote, On 2008-12-27 06:54:
*_With other words (adapted from N. Bolyard):_*
b) Is there any way for a Firefox user to detect that his CA has requested
[the] private key [to be transmitted] ?
_Possible Answer by Kaspar Band: _ ...an Encryption Key Copy warning
dialog will be
Reed Loden wrote:
On Sat, 27 Dec 2008 13:55:45 +0100
Michael Ströder mich...@stroeder.com 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
After having read the posts related to the unbelievable event, I
understand the event involved an approved CA and an external entity they
work with.
From my perspective, it's a CA's job to ensure competent verification
of certificate requests. The auditing required for CAs is supposed to
prove
On 12/28/2008 12:50 PM, Nelson B Bolyard:
I also think we need a page or two on developer.mozilla.org that fully
documents both thekeygen tag and the crypto.generateCRMFRequest method.
The existing documentation is very incomplete. Thekeygen tag, for
example, accepts many more arguments than
Nelson B Bolyard wrote:
I also think we need a page or two on developer.mozilla.org that fully
documents both the keygen tag and the crypto.generateCRMFRequest method.
+1
The existing documentation is very incomplete. The keygen tag, for
example, accepts many more arguments than are now
On 28/12/08 12:13, Kai Engert wrote:
If we'd like to be strict, we could remove CAs from our approved list if
they have shown to be non-conforming in the above way.
Yes, we could! But this is what we call a blunt weapon. It is also a
dangerous weapon. Consider (all) the consequences in
On 28/12/08 12:13, Kai Engert wrote:
From my perspective, it's a CA's job to ensure competent [stuff].
OK.
The auditing required for CAs is supposed to prove it.
This might be a bit too strong. Let's look at that.
What audits do is confirm criteria, and provide an opinion that the
On 12/28/2008 02:46 PM, Ian G:
1. Certs: All end-users who rely on these certs will lose. That probably
numbers in the millions. All subscribers will lose, probably in the
thousands. The CA will lose; potentially it will lose its revenue
stream, or have it sliced in half (say), which is what we
On 12/28/2008 03:23 PM, Ian G:
[1] disclosure, I work as an auditor
Since you are making a claim here of being an auditor - and specially in
the context of WebTrust or similar criteria, can you please also
disclose which formal training and titles you have? For which audit firm
are you
(following is just for the record so as to deal with the response. No
new info is in here for other readers.)
On 28/12/08 14:21, Eddy Nigg wrote:
On 12/28/2008 02:46 PM, Ian G:
1. Certs: All end-users who rely on these certs will lose. That probably
numbers in the millions. All
On 28/12/08 14:57, Eddy Nigg wrote:
On 12/28/2008 03:23 PM, Ian G:
[1] disclosure, I work as an auditor
Since you are making a claim here of being an auditor - and specially in
the context of WebTrust or similar criteria,
OK, to answer the implied question here, the criteria are those
On 12/28/2008 04:24 PM, Ian G:
1. Certs: All end-users who rely on these certs will lose. That probably
numbers in the millions. All subscribers will lose, probably in the
thousands. The CA will lose; potentially it will lose its revenue
stream, or have it sliced in half (say), which is what we
I wouldn't spend much work on keygen and crypto.generateCRMFRequest
because they don't match today's needs anyway. You cannot even as an
issuer control PIN code settings (policy) unless you have a pre-configured
crypto
container, i.e. these mechanisms are tools for toy PKIs.
Serious PKIs use
2008/12/28 Nelson B Bolyard nel...@bolyard.me
I think the question is: is there any way for a web site to suppress
that [private key transmission warning-] dialog?
Yes: this should be the point. Having the certainty, that a warning dialog
cannot be suppressed when a private key is to be
I'm trying to create a simple Java RMI application with a custom
factory that uses JSS SSL classes. So I created a simple server and
client factories that create SSLServerSocket and SSLSocket instances
correspondingly. But when my client tries to lookup in the registry,
the following happens:
Hi Kai,
long reply, I appreciate the grounding in actual policies and practices!
This allows us to explore what we really can and cannot do.
(I've cut two of your comments out to other posts where they might be
generally intersting for the wider audience.)
On 28/12/08 12:13, Kai Engert
On 28/12/08 15:42, Eddy Nigg wrote:
On 12/28/2008 04:24 PM, Ian G:
I was clearly replying to the later part:
The CA will lose; potentially it will lose its revenue stream, or have
it sliced in half (say), which is what we would call in business circles
a plausible bankrupcy event.
It's not
On 28/12/08 15:47, Anders Rundgren wrote:
PKIX are not aware of the problem because PKIX don't do browsers,
they do ASN.1.
Who does browsers?
iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
Anders Rundgren wrote:
I wouldn't spend much work on keygen and crypto.generateCRMFRequest
because they don't match today's needs anyway.
Anders, does the word keygen trigger an automatic response in your
news bot? ;-}
Your comment is not relevant in this context. Off course the *existing*
Michael Ströder wrote:
Anders Rundgren wrote:
I wouldn't spend much work on keygen and crypto.generateCRMFRequest
because they don't match today's needs anyway.
Anders, does the word keygen trigger an automatic response in your
news bot? ;-}
Well, some 1000h into its successor have left some
On 12/28/2008 01:13 PM, Kai Engert:
The current Mozilla CA Certificate Policy says:
6. We require that all CAs whose certificates are distributed with our
software products: ... provide attestation of their conformance to the
stated verification requirements ...
Kai, just to counter Ian's
On 12/28/2008 4:46 AM, Ian G wrote [in part]:
On 28/12/08 12:13, Kai Engert wrote:
If we'd like to be strict, we could remove CAs from our approved list if
they have shown to be non-conforming in the above way.
Yes, we could! But this is what we call a blunt weapon. It is also a
On 12/28/2008 09:45 PM, Reed Loden:
You can use any e-mail address as a Google Account, so yes, I
really think so. Patricia's reply confirms this, too.
Reed, Servage is a hosting company, their MX record isn't that of
Google, but their own. This email account is not hosted with Google. You
Anders Rundgren wrote, On 2008-12-28 07:52:
[...] most organizations are more concerned about sent data than received
[...]
This is one reason (out of many) that Mozilla's S/MIME mail clients require
that the sender be an implicit recipient of any encrypted messages sent.
It ensures that the
(Note: this is almost completely off-topic as relates to the OP's message.)
REAL programmers do everything they can to point out flaws of things
that don't meet their needs, but are easier to use, older,
more-debugged, and sufficient for those cases that don't require the
ability to trust code
Michael Ströder wrote, On 2008-12-28 04:38 PST:
Nelson B Bolyard wrote:
I also think we need a page or two on developer.mozilla.org that fully
documents both the keygen tag and the crypto.generateCRMFRequest method.
+1
The existing documentation is very incomplete. The keygen tag, for
On Sun, Dec 28, 2008 at 6:24 AM, Ian G i...@iang.org wrote:
(following is just for the record so as to deal with the response. No new
info is in here for other readers.)
I would very much appreciate it if you would stop using fear,
uncertainty, and doubt to manipulate the audience into
On Sun, Dec 28, 2008 at 9:28 AM, Ian G i...@iang.org wrote:
On 28/12/08 17:06, David E. Ross wrote:
How about the users of Mozilla products who might lose money or even go
bankrupt because they trusted a root certificate from such a CA? No,
such losses are not known (yet). What did happen,
On 29/12/08 00:37, Kyle Hamilton wrote:
On Sun, Dec 28, 2008 at 9:28 AM, Ian Gi...@iang.org wrote:
On 28/12/08 17:06, David E. Ross wrote:
How about the users of Mozilla products who might lose money or even go
bankrupt because they trusted a root certificate from such a CA? No,
such losses
On Sun, Dec 28, 2008 at 3:42 PM, Ian G i...@iang.org wrote:
On 29/12/08 00:37, Kyle Hamilton wrote:
Considering that trustability is viewed as a binary state, it's the
only weapon that Mozilla has.
Yes. This is reason for concern.
FWIW, I agree.
Alright, I propose that, in a new thread,
On 29/12/08 00:36, Kyle Hamilton wrote:
On Sun, Dec 28, 2008 at 6:24 AM, Ian Gi...@iang.org wrote:
Unlike you, Eddy actually runs a certifying authority. This means
that he has operational experience with not only the technical sides
of things, but also the legal sides of things.
I
On 12/29/2008 03:09 AM, Ian G:
The point I have made is that the discussion of Comodo's operations is
outside scope of this forum. You may feel that you have an opinion, and
you have a right to it. However, this forum is not for the investigation
of breaches or failures to comply with policies.
On 12/28/2008 3:45 PM, Kyle Hamilton wrote [in part]:
CertStar was found out, only due to the diligence of someone on this
list. How many other RAs haven't been found out yet? We can't know,
because Comodo won't say. This affects the confidence I have in their
system (i.e., it removes ALL
David E. Ross wrote, On 2008-12-28 21:40 PST:
Now that it is known that a subordinate reseller operating under one CA
issued certificates without authenticating the identity of the
subscribers, we know that the theoretical concern expressed (before all
this) about resellers is no longer
On Sun, 28 Dec 2008 22:13:53 +0200
Eddy Nigg eddy_n...@startcom.org wrote:
On 12/28/2008 09:45 PM, Reed Loden:
You can use any e-mail address as a Google Account, so yes, I
really think so. Patricia's reply confirms this, too.
Reed, Servage is a hosting company, their MX record isn't
On 12/28/2008 9:42 AM Eddy Nigg cranked up the brainbox and said:
On 12/28/2008 04:24 PM, Ian G:
No, I'm afraid there is an agreement to list the root, under a policy.
Once listed, Mozilla has to operate according to its side of the bargain.
Apparently you are reading something I haven't.
37 matches
Mail list logo