>Now, if the discussion can be steered to how Mozilla's crypto can succeed at
>becoming as popular as Skype may be, WITHOUT it having to resort to
>- closed source,
>- proprietary designs (restricted intellectual property),
>- being a closed system with no interoperability,
>that may be worthwhile
Per the CA schedule (for which I need to update dates), the next CA on
the list for public comment is SECOM Trust, which has applied to add a
new root CA certificate to the Mozilla root store and enable it for EV,
as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?
Eddy Nigg wrote, On 2008-12-05 04:48:
> On 12/05/2008 09:17 AM, Nelson Bolyard:
>> Ian,
>>
>> Now, in contrast to that, I have been led to believe that Skype's:
>> - protocols, security designs and parameters are proprietary, secret, have
>> not been openly published, and thus not subjected to publ
Anders Rundgren wrote:
When any of you guys have made a *public* write-up on how you
would address the [related] issues mentioned on p.2 in this document
http://webpki.org/papers/web/A.R.AppliedPKI-Lesson-1.pdf
you are ready for the real discussion.
That's easy since there's not need for end-2-
Anders wrote:
> When any of you guys have made a *public* write-up on how you
> would address the [related] issues mentioned on p.2 in this document
> http://webpki.org/papers/web/A.R.AppliedPKI-Lesson-1.pdf
> you are ready for the real discussion.
1. How is the purchaser (P) going to select an
Michael Ströder wrote:
>> Secure e-mail must be destroyed, or to be more correct;
>> replaced by something that actually works for ordinary people.
>Oh, come on! You simply want to sell something new. That's not something
>I can take serious.
I'm not selling anything except maybe a vision of a m
Anders Rundgren wrote:
Michael Stroder wrote:
I'm often working while traveling by train. I'm off-line then. I want
the encrypted e-mail ready to be in the [Outgoing] folder - protected
right from the beginning.
This does not appear to be a general requirement. Presumably
most people have ot
On 12/05/2008 10:54 PM, Anders Rundgren:
This is why IM kills S/MIME because the latter does not
require awkward saving of keys in eternity.
Anders, the issue is the way a program decides to store a message. IM is
instantly, but if your IM history is stored in an encrypted form by the
very
Michael Stroder wrote:
>I'm often working while traveling by train. I'm off-line then. I want
>the encrypted e-mail ready to be in the [Outgoing] folder - protected
>right from the beginning.
This does not appear to be a general requirement. Presumably
most people have other documents that woul
Anders Rundgren wrote:
Michael Ströder wrote:
That there should be as you claim mainly a "UI problem" is an opinion
that has some support in the literature ("Jonny can't encrypt"),
but I feel that it is much deeper than that; security should probably
as in the case of Skype be transparent, not n
Thanks for tips! Could you point me to the line in spec where it says
that slots can only be added. I cant find the place where it forbids
removing.
On 12/5/08, Robert Relyea <[EMAIL PROTECTED]> wrote:
> Martin Paljak wrote:
>> Thanks!
>>
>> I was only trying to figure out if there is any differe
Martin Paljak wrote:
Thanks!
I was only trying to figure out if there is any difference in 2.11 vs
2.20 handling.
2.20 allows slots to be added during the lifetime of a cryptoki
application.
Can you also explain how NSS handles the feature or any gotchas in
implementing support for hotplugg
Michael Ströder wrote:
>> That there should be as you claim mainly a "UI problem" is an opinion
>> that has some support in the literature ("Jonny can't encrypt"),
>> but I feel that it is much deeper than that; security should probably
>> as in the case of Skype be transparent, not needing any UI
Anders Rundgren wrote:
This is almost like a discussion about "theory" versus "practice".
I agree here. ;-)
As a researcher in this field, I'd hoped that the gap would diminish over
time but it seems that is actually widening!
Well, it turned out that some researchers do not have personal p
Thanks!
I was only trying to figure out if there is any difference in 2.11 vs
2.20 handling.
2.20 allows slots to be added during the lifetime of a cryptoki
application.
Can you also explain how NSS handles the feature or any gotchas in
implementing support for hotpluggable PC/SC readers?
Anders Rundgren wrote:
That there should be as you claim mainly a "UI problem" is an opinion
that has some support in the literature ("Jonny can't encrypt"),
but I feel that it is much deeper than that; security should probably
as in the case of Skype be transparent, not needing any UI at all.
I
Anders Rundgren wrote:
Ian G wrote:
Michael Ströder wrote:
If the private key is no longer available, yes, encrypted data
technically cannot be decrypted anymore.
Note the decision here to store the email in private-key encrypted form,
instead of (for example) cleartext or re-encrypting it w
Ian G wrote, On 2008-12-04 22:58:
> (I discovered some other oddities about S/MIME recently: revocation
> seems to be incongruent with key distribution. I can distribute a new
> cert only in an S/MIME signed email, but I can't distro any updates to
> my key situation. When I lose a key, all
Ian G wrote:
Michael Ströder wrote:
Eddy Nigg wrote:
On 12/05/2008 08:58 AM, Ian G:
> When I lose a key, all the old encrypted email is no
longer readable ... which presumably happens when revocation happens as
well.
For your protection, yes.
???
If the private key is no longer availabl
Martin Paljak wrote, On 2008-12-05 07:03:
> Hi!
>
> PKCS#11 modules advertise its versions in two different places: in the
> structure returned by C_GetFunctionList and in C_GetInfo. What happens
> if those versions mismatch or which one has higher priority?
Answering only for NSS,
NSS igno
Ian G wrote:
>Michael Ströder wrote:
>> If the private key is no longer available, yes, encrypted data
>> technically cannot be decrypted anymore.
>Note the decision here to store the email in private-key encrypted form,
>instead of (for example) cleartext or re-encrypting it with the master
>pass
Michael Ströder wrote:
Eddy Nigg wrote:
On 12/05/2008 08:58 AM, Ian G:
> When I lose a key, all the old encrypted email is no
longer readable ... which presumably happens when revocation happens as
well.
For your protection, yes.
???
If the private key is no longer available, yes, encryp
Kyle Hamilton wrote, On 2008-12-04 10:57:
> On Sat, Nov 29, 2008 at 3:57 PM, Frank Hecker
> <[EMAIL PROTECTED]> wrote:
>> The primary reason CAs apply to have certificates included into NSS, and the
>> primary reason we have a policy about this, is because CAs want their
>> customers' SSL certific
Eddy Nigg wrote:
On 12/05/2008 08:58 AM, Ian G:
> When I lose a key, all the old encrypted email is no
longer readable ... which presumably happens when revocation happens as
well.
For your protection, yes.
???
If the private key is no longer available, yes, encrypted data
technically ca
On 12/5/2008 4:08 AM, Eddy Nigg wrote [in part]:
> On 12/05/2008 08:58 AM, Ian G [also in part]:
>
> > When I lose a key, all the old encrypted email is no
>> longer readable ... which presumably happens when revocation happens as
>> well.
>
> For your protection, yes.
That's contrary to the wa
Hi!
PKCS#11 modules advertise its versions in two different places: in the
structure returned by C_GetFunctionList and in C_GetInfo. What happens
if those versions mismatch or which one has higher priority? Does the
version number change the way NSS (or Firefox in that matter) behaves?
--
On 12/05/2008 12:56 PM, Eddy Nigg:
In this respect, Globalsign might implement it exactly in the same way.
We might however ask them or read their CPS instead.
I had another look at http://www.globalsign.com/support/csr/autocsr.html
and apparently they aren't sending the PKCS12 file by email
On 12/05/2008 03:20 PM, Anders Rundgren:
I doubt that Ian promotes the things you claim he does.
The tone and arguments highly suggests exactly that.
That there should be as you claim mainly a "UI problem" is an opinion
that has some support in the literature ("Jonny can't encrypt"),
but I
Eddy Nigg wrote:
>Nelson wrote:
>> Now, in contrast to that, I have been led to believe that Skype's:
>> - protocols, security designs and parameters are proprietary, secret, have
>> not been openly published, and thus not subjected to public scrutiny
>> - components are all proprietary. Their cli
On 12/05/2008 01:03 PM, Anders Rundgren:
And it goes on and on
http://news.cnet.com/8301-17939_109-10110382-2.html
while security communities are talking about perfect solutions for
a minority of security-conscious users...
This is almost like a discussion about "theory" versus "practice".
As a
On 12/05/2008 09:17 AM, Nelson Bolyard:
Ian,
Now, in contrast to that, I have been led to believe that Skype's:
- protocols, security designs and parameters are proprietary, secret, have
not been openly published, and thus not subjected to public scrutiny
- components are all proprietary. Their
On 12/05/2008 08:58 AM, Ian G:
> When I lose a key, all the old encrypted email is no
longer readable ... which presumably happens when revocation happens as
well.
For your protection, yes.
I don't know if there is even anyone working on Tbird security;
Yes
thing about this was that Moz
On 12/04/2008 02:49 PM, Ian G:
Telephony was provided to the masses and it's inherently insecure.
Skype provided VoIP to the masses. And it was secure.
You keep claiming it and I tell you that it's not. Of course we can
continue forever here. But it doesn't come close to the same security
And it goes on and on
http://news.cnet.com/8301-17939_109-10110382-2.html
while security communities are talking about perfect solutions for
a minority of security-conscious users...
This is almost like a discussion about "theory" versus "practice".
As a researcher in this field, I'd hoped that t
On 12/05/2008 11:38 AM, Rob Stradling:
It's considered a very bad practice I think.
Eddy, could you expand on this point?
I don't think WebTrust prohibits CAs from generating/retaining private keys
for users.
Retaining the private keys of users requires a key escrow service,
reasonable prot
On Wednesday 03 December 2008 12:22:19 Eddy Nigg wrote:
> On 12/02/2008 08:16 PM, Ian G:
> > Right, CAs won't have the private keys, unless they do. I imagine a
> > corporate CA can do what it likes, and doesn't need the consent of the
> > user.
>
> Sure, but they aren't in my list of CA roots.
>
>
Anders Rundgren wrote:
This is BTW not too different to PayPal which I guess works so well
because it owns the entire customer-base and doesn't have to mess
with other competing/collaborating partners.
Ahhh... Paypal :) Now there is a poignant example.
Paypal is awful. Its security is woefu
Nelson Bolyard wrote:
Ian,
Previously in this thread, you wrote:
For me, the purpose of this debate is finding out what users can expect from
Mozilla by way of security.
Thank you for taking the time to lay out your views!
The answers to that quest probably include these properties:
- op
Nelson wrote:
>> For me, the purpose of this debate is finding out what users can expect from
>> Mozilla by way of security.
>The answers to that quest probably include these properties:
>- open, openly specified, not secret,
>- inner workings subjected to public scrutiny.
>- security claims indep
39 matches
Mail list logo
