Thunderbird and Pretty Easy Privacy - current status

[R Kent James]

As many of you know, the Thunderbird Council has been talking to the
Pretty Easy Privacy project (PEP) about how the two groups might be able
to work together to best serve users.

The Council, on behalf of the Thunderbird project, wishes to thank PEP
for their interest and their kind offers of help, which have been many
and generous. We continue to hope that Thunderbird and PEP will have a
fruitful collaboration in the fullness of time. However, the two groups
have together agreed that it will be much easier to assess how best to
work together after some key milestones have been reached. Those
milestones are:

1) A new Thunderbird Council has been chosen
2) A fiscal home for Thunderbird has been chosen
3) An alpha version of a PEP/Enigmail addon is available

The choice of a fiscal home will have a large effect on what sorts of
additional help the Thunderbird project might need in the future. And
the availability of a working version of PEP's technology which can be
tested in Thunderbird will make it much easier for members of the
Thunderbird community to evaluate it and consider integration options.

So the Council, on behalf of its future self, looks forward to
re-opening discussions with PEP at the appropriate time.

Kent James
(on behalf of the Thunderbird Council)

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[BA]

Dear Kent,

On Feb 24, 2016, at 7:32 PM, R Kent James <ke...@caspia.com> wrote:
> So the Council, on behalf of its future self, looks forward to
> re-opening discussions with PEP at the appropriate time.

We look forward to working with the new TB Council in the near future.

Kindest regards,
-Berna
—
Berna Alp, p≡p project
b...@pep-project.org

[Ben Bucksch]

R Kent James wrote on 24.02.2016 19:32:
> 3) An alpha version of a PEP/Enigmail addon is available

Please note that the later we get involved, the less influence we can
have on the result.

If your concern is that PEP drops something on us that we can't accept,
then we better get involved earlier rather than later. As you know, cost
of change increases 10-fold each step of the way.

Ben

[Gervase Markham]

On 25/02/16 13:27, Ben Bucksch wrote:
> R Kent James wrote on 24.02.2016 19:32:
>> 3) An alpha version of a PEP/Enigmail addon is available
>
> Please note that the later we get involved, the less influence we can
> have on the result.

True, but it's hard to evaluate something you've never seen.

> If your concern is that PEP drops something on us that we can't accept,
> then we better get involved earlier rather than later. As you know, cost
> of change increases 10-fold each step of the way.

PEP are, of course, responsible for their own schedules but my
understanding is that this milestone is not too far away.

Gerv

[Patrick Brunschwig]

On 25.02.16 14:27, Ben Bucksch wrote:
> R Kent James wrote on 24.02.2016 19:32:
>> 3) An alpha version of a PEP/Enigmail addon is available
>
> Please note that the later we get involved, the less influence we can
> have on the result.
>
> If your concern is that PEP drops something on us that we can't accept,
> then we better get involved earlier rather than later. As you know, cost
> of change increases 10-fold each step of the way.

PEP is a product by an independent organization - the Thunderbird
community by will only have limited influence on the product.

But, and this is most important, PEP "only" provides services that are
a) invisible to users, and
b) quite easily pluggable into an application via a clearly defined API.

Therefore, the influence you are talking about will mostly target
Enigmail, not PEP. If Enigmail should become a part of Thunderbird, then
I expect this is something we will certainly need to clarify - I'm open
for such discussions.


-Patrick

[Joshua Cranmer 🐧]

On 2/25/2016 9:09 AM, Patrick Brunschwig wrote:

On 25.02.16 14:27, Ben Bucksch wrote:

R Kent James wrote on 24.02.2016 19:32:

3) An alpha version of a PEP/Enigmail addon is available 

Please note that the later we get involved, the less influence we can
have on the result.

If your concern is that PEP drops something on us that we can't accept,
then we better get involved earlier rather than later. As you know, cost
of change increases 10-fold each step of the way.

PEP is a product by an independent organization - the Thunderbird
community by will only have limited influence on the product.

PeP was trying to ask us to integrate PeP into the product by default.

Therefore, the influence you are talking about will mostly target
Enigmail, not PEP. If Enigmail should become a part of Thunderbird, then
I expect this is something we will certainly need to clarify - I'm open
for such discussions.

I actually do think Enigmail, or at least the PGP encryption/decryption mechanical parts, should be integrated (and tested) into Thunderbird, even independently of whatever happens with PEP. I was more or less holding off on discussing this until my nsMsgSend rewrite progressed to a stage where I could figure out what the successor to nsIMsgComposeSecure should look like, since the current interface is not that answer.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Ben Bucksch]

Patrick Brunschwig wrote on 25.02.2016 16:09:
> But, and this is most important, PEP "only" provides services that are
> a) invisible to users, and
> b) quite easily pluggable into an application via a clearly defined API.

Backdoors and insecure designs are invisible, too :).

This needs serious investigation - on protocol design and code level -
before we can integrate it.

We'll also need review from a wide crypto community.

Gervase Markham wrote on 25.02.2016 16:59:
> True, but it's hard to evaluate something you've never seen.

Exactly. That's my point.

The 2 projects should rather approach each other and work together, and
in the process build mutual trust, than TB kicking back and waiting for
a finished PEP product, and then simply saying yay/nay. That's not
likely to be a fruitful process, IMHO.

Ben

[BA]

Please allow us (Berna, Volker and Patrick) a little more time to get back to you with a concrete timeline, because once you see how Enigmail/p≡p works, most discussions will quickly cease due to the nonintrusive nature and extreme ease of use of the new plug-in. We intend to provide you with betas as soon as possible, to allow for feedback and input. I can also arrange for those who would like to venture into ‘hostile territory’  and receive a copy of the p≡p for Microsoft Outlook plug-in, which will be launched very shortly.  p≡p for Outlook plug-in illustrates the concept of privacy by default as envisioned in Enigmail/p≡p as well. Just let me know.

p≡p was perturbed about the past announcements re Thunderbird and hence offered TB a reliable support system, as TB is critical to the crypto-community and furthermore TB can have an even bigger global privacy impact with Enigmail/pEp built in. Our proposition was conceived as a win-win for all the stakeholders and it’s still relevant as far as we are concerned.

Warmest regards,

-Berna Alp

— 

[Patrick Cloke]

Ben,

I'm not sure if you've been following the conversation, but the points
you've brought up have been discussed in depth before.

On 2/25/16 2:35 PM, Ben Bucksch wrote:
> Patrick Brunschwig wrote on 25.02.2016 16:09:
>> But, and this is most important, PEP "only" provides services that are
>> a) invisible to users, and
>> b) quite easily pluggable into an application via a clearly defined API.
>
> Backdoors and insecure designs are invisible, too :).
>
> This needs serious investigation - on protocol design and code level -
> before we can integrate it.
>
> We'll also need review from a wide crypto community.

We (the Thunderbird community) recognize this and also recognize that
we're not crypto experts (i.e. we're not in a place to do this).

> Gervase Markham wrote on 25.02.2016 16:59:
>> True, but it's hard to evaluate something you've never seen.
>
> Exactly. That's my point.
>
> The 2 projects should rather approach each other and work together,
> and in the process build mutual trust, than TB kicking back and
> waiting for a finished PEP product, and then simply saying yay/nay.
> That's not likely to be a fruitful process, IMHO.

We've been in discussions with pEp and have had conversations with them
about their technology. The keyword in the statement was an *alpha*
version. This implies that there is still time to change
direction/influence designs.

Note that some of us did see a version of pEp's software for Outlook
last fall, but how exactly it would work within Thunderbird has not been
discussed as a detailed plan nor as a prototype.

--Patrick

[Volker Birk]

On Thu, Feb 25, 2016 at 08:35:24PM +0100, Ben Bucksch wrote:
> We'll also need review from a wide crypto community.

FYI: we hired Sektion 1 to do such a review, and publish all details:

https://sektioneins.de/

We will adapt on their findings.

Yours,
VB.
--
Volker Birk, p≡p project
mailto:v...@pep-project.org http://www.pep-project.org

[R Kent James]

On 2/25/2016 11:35 AM, Ben Bucksch wrote:
> The 2 projects should rather approach each other and work together,
> and in the process build mutual trust, than TB kicking back and
> waiting for a finished PEP product, and then simply saying yay/nay.
> That's not likely to be a fruitful process, IMHO.

I agree 100%, Ben.

But you need to separate PEP from Enigmail, so there are 3 projects here.

Thunderbird has a long history with Enigmail, and there is a lot of
experience in the PGP community with Enigmail. The issue of
incorporating Enigmail into Thunderbird is more a matter of convenience
to our users, as well as increasing the visibility of Enigmail (and PGP)
as an encryption option. But I've mentioned to Patrick several times,
including today, that one of the obstacles to incorporating Enigmail
into Thunderbird is the separation of the Enigmail dev community from
Thunderbird (the "work together" part), as compared for example to
calendar or chat. (The other issues are UI effects on users that are not
using PGP, and licensing issues). These are all solvable issues, and I
sincerely hope that we can get them solved so that we can ship Enigmail
in the next major version of Thunderbird. This is independent of any
cooperation with PEP.

The reason that we keep linking PEP and Enigmail is that, as we
understand it, PEP is proposing an encryption solution that is based on
Enigmail, with additional components supplied by PEP. So Enigmail is a
necessary but not sufficient part of incorporating PEP technology into
Thunderbird.

Concerning PEP, I think that we can say there have been some severe
cultural clashes to working together. Yet Berna is trying hard to figure
us out, and I am enthusiastic about the possibility of PEP making PGP
encryption much more straightforward than it is now, and more widely
adopted. So there is hope, but it will take some time to, as you say,

"approach each other and work together, and in the process build mutual

trust". That's mostly what the recent statement is about. Nobody from
Thunderbird want to be in a situation where we are "simply saying
yay/nay" (or even worse, agreeing a priori to say "yay" because we are
accepting funding from PEP). What would help is someone familiar with TB
to work with PEP, or someone from PEP to work with Thunderbird.

:rkent

[BA]

Dear Patrick,

On Feb 25, 2016, at 9:20 PM, Patrick Cloke <pat...@cloke.us> wrote:
>
> We've been in discussions with pEp and have had conversations with them
> about their technology. The keyword in the statement was an *alpha*
> version. This implies that there is still time to change
> direction/influence designs.
>
> Note that some of us did see a version of pEp's software for Outlook
> last fall, but how exactly it would work within Thunderbird has not been
> discussed as a detailed plan nor as a prototype.

Thanks for your remark. I’d like to emphasize once more that we are very open to suggestions from the community to make p≡p even easier and more secure! We welcome your ideas, opinions and experience if anyone would like to be involved further in the design of Enigmail/p≡p or the technology under the hood, pls drop me/us a line.

As Volker mentioned in his e-mail, Sektion Eins is doing a full external code review of p≡p which will be published.

Kind regards,
-BA
—

[Klaus Hartnegg]

> Am 25.02.2016 um 21:37 schrieb R Kent James <ke...@caspia.com>:
> The reason that we keep linking PEP and Enigmail is that, as we understand it, PEP is proposing an encryption solution that is based on Enigmail, with additional components supplied by PEP.

I am not (yet) a PEP expert, but from their talks I conclude that for PEP it is irrelevant whether Enigmail is also integrated into Thunderbird. These two plugins are independend of each other. They only both share the requirement that Enigmail must be installed. If it is not, then the PEP installer installs it.

However the teams for both plugins should talk to each other, to prevent interference. They should agree on using the same version of Enigmail, or make sure that they use separate copies of it. And they should make sure that the uninstaller of one does not erase the Enigmail copy which is still used by the other.

--
Message sent from a mobile device, please excuse brevity and typos

[BA]

On Feb 25, 2016, at 9:37 PM, R Kent James <ke...@caspia.com> wrote:

> The reason that we keep linking PEP and Enigmail is that, as we understand it, PEP is proposing an encryption solution that is based on Enigmail, with additional components supplied by PEP. So Enigmail is a necessary but not sufficient part of incorporating PEP technology into Thunderbird.

Just to clarify: Although both Enigmail and p≡p could be independent solutions working with TB, we agreed to collaborate and join forces as such is in the interest of the public and privacy around the world. Due to that decision, both are required for a successful Enigmail/p≡p solution. The nice thing about p≡p in general is that it does not affect users who send unencrypted e-mails and the TB interface could theoretically not change at all.

> Concerning PEP, I think that we can say there have been some severe cultural clashes to working together. Yet Berna is trying hard to figure us out, and I am enthusiastic about the possibility of PEP making PGP encryption much more straightforward than it is now, and more widely adopted. So there is hope, but it will take some time to, as you say, "approach each other and work together, and in the process build mutual trust". That's mostly what the recent statement is about. Nobody from Thunderbird want to be in a situation where we are "simply saying yay/nay" (or even worse, agreeing a priori to say "yay" because we are accepting funding from PEP). What would help is someone familiar with TB to work with PEP, or someone from PEP to work with Thunderbird.

Is there a TB contributor who would like to be involved in p≡p? Maybe we should explore that option next.
-ba

[Nomis101 🐝]

Am 24.02.16 um 19:32 schrieb R Kent James:

> 3) An alpha version of a PEP/Enigmail addon is available
>

I am really looking forward to try this out. :-) I'm regularly visiting
the pEp homepage to see if there are any news about this.

[BA]

On Feb 25, 2016, at 10:48 PM, Nomis101 🐝 <Nomi...@web.de> wrote:
> I am really looking forward to try this out. :-)

Super! We can’t wait to share it with everyone ;-)

> I'm regularly visiting
> the pEp homepage to see if there are any news about this.

I can tell, you are amongst the few who can abbreviate our name accurately :-)

[BA]

On Feb 25, 2016, at 11:16 PM, Klaus Hartnegg <hart...@uni-freiburg.de> wrote:
>
> I am not (yet) a PEP expert, but from their talks I conclude that for PEP it is irrelevant whether Enigmail is also integrated into Thunderbird. These two plugins are independend of each other. They only both share the requirement that Enigmail must be installed. If it is not, then the PEP installer installs it.
>
> However the teams for both plugins should talk to each other, to prevent interference. They should agree on using the same version of Enigmail, or make sure that they use separate copies of it. And they should make sure that the uninstaller of one does not erase the Enigmail copy which is still used by the other.

There are no 2 plug-ins nor will there ever be, therefore no danger of interference. The p≡p and Enigmail teams are working closely together to provide one better product for the TB and crypto community - we strongly believe only by working together we will make a difference and hence we at p≡p are delighted to provide our engine to the next version of Enigmail, named Enigmail/pEp.

I hope my answer brings more clarity.

[Volker Birk]

On Thu, Feb 25, 2016 at 11:16:06PM +0100, Klaus Hartnegg wrote:
> > Am 25.02.2016 um 21:37 schrieb R Kent James <ke...@caspia.com>:
> > The reason that we keep linking PEP and Enigmail is that, as we understand
> > it, PEP is proposing an encryption solution that is based on Enigmail, with
> > additional components supplied by PEP.
> I am not (yet) a PEP expert, but from their talks I conclude that for PEP it
> is irrelevant whether Enigmail is also integrated into Thunderbird. These two
> plugins are independend of each other. They only both share the requirement
> that Enigmail must be installed. If it is not, then the PEP installer
> installs it.

That's a misunderstanding. Enigmail/p≡p (which will be the outcome of our
cooperation) will be a full featured Enigmail including a default mode (“Junior
Mode”) where it is using p≡p engine for key management, trust rating and so
forth. Enigmail still will provide an “Expert Mode” where people who want to
manage their crypto themselves can do it like they're used to.

Basically, p≡p will add a feature to Enigmail. p≡p will not sport a second
plugin.

[Matt Harris]

On 26/02/2016 8:18 AM, Nomis101 🐝 wrote:

Am 24.02.16 um 19:32 schrieb R Kent James:

3) An alpha version of a PEP/Enigmail addon is available

I am really looking forward to try this out. :-) I'm regularly visiting
the pEp homepage to see if there are any news about this.

I went to their foundation home page and clicked the link on the top of the page....  that ended my journey.


It is just this sort of error in the "secure by default environment" that leaves me concerned. 

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

--
“Against stupidity the gods themselves contend in vain.” ― Friedrich von Schiller, Die Jungfrau von Orleans

[Magnus Melin]

There might be many people who are interested in following that. If you're asking is there anybody who want's to be completely devoted to that atm, you might not see that many people raising their hands.

As far as I know there is currently no public p≡p activity to follow. It's indeed essential that such activities are opened up as soon as possible. Then you'll have people following and taking in bits and pieces and possibly step up their involvement as they see fit.

You might not have realized it, but Thunderbird and Mozilla in general are extremely bug focused. If the activity is not registered as a bug in bugzilla it basically do not exist . That's the workflow we follow and that's how people follow what's going on, get involved, have opinions on approaches and ultimately submit patches. In contrast: there are of course discussions on mailing lists and newsgroups but those are more about higher level policy and possible approaches. For concrete things to happen code-wise, that will always go through bugzilla.

On that subject - I do think for Enigmail to ship as a default plugin in Thunderbird we need to land the code in comm-central and also start using bugzilla as issue tracker for it. If not, you really don't get the needed fusion and trust between the communities that is needed to confidently ship it. We'd have a very odd situation that it ships (as default) and someone finds a problem, you'd have to say "hey, not our problem, go file a bug with those guys" - which is clearly unacceptable. We'd also not be able to for instance track release blockers in bugzilla and so on...
 
-Magnus

[Nomis101 🐝]

Am 26.02.16 um 00:31 schrieb BA:

But maybe still not accurately enought, because I couldn't find this "≡" on my keyboard. ;-)

[Axel Grude]

Dear Patrick,
could  you provide a download link? I would like to try again (unfortunately I lost my passphrase so I had to wait until my keyring revocation period expired) and maybe I can give some feedback on ease of / UX improvements if you like.


Axel

Subject: Re: Thunderbird and Pretty Easy Privacy - current status
From: Patrick Cloke
To: Tb-planning
Sent: Thursday, 25/02/2016 20:20:41 20:20 GMT ST +0000 [Week 8]

[Patrick Brunschwig]

On 25.02.16 20:35, Ben Bucksch wrote:
[...]

> Gervase Markham wrote on 25.02.2016 16:59:
>> True, but it's hard to evaluate something you've never seen.
>
> Exactly. That's my point.
>
> The 2 projects should rather approach each other and work together, and
> in the process build mutual trust, than TB kicking back and waiting for
> a finished PEP product, and then simply saying yay/nay. That's not
> likely to be a fruitful process, IMHO.

The two projects _are_ talking to each other, and (as Volker wrote) we
have quite concrete ideas how we want to integrate PEP into Enigmail.
From my perspective, the reason that there was little outcome so far is
mainly due to resource restrictions on both projects.

-Patrick

[BA]

On Feb 25, 2016, at 9:37 PM, R Kent James <ke...@caspia.com> wrote:

The reason that we keep linking PEP and Enigmail is that, as we understand it, PEP is proposing an encryption solution that is based on Enigmail, with additional components supplied by PEP. So Enigmail is a necessary but not sufficient part of incorporating PEP technology into Thunderbird.

Please see 'Enigmail and p≡p' cooperation announcement, for further details:

https://enigmail.net/index.php/en/home/news/29-enigmail-pep

We take this very seriously and we’re very happy with the way this is progressing.

Concerning PEP, I think that we can say there have been some severe cultural clashes to working together. Yet Berna is trying hard to figure us out, and I am enthusiastic about the possibility of PEP making PGP encryption much more straightforward than it is now, and more widely adopted. So there is hope, but it will take some time to, as you say, "approach each other and work together, and in the process build mutual trust".  That's mostly what the recent statement is about. Nobody from Thunderbird want to be in a situation where we are "simply saying yay/nay" (or even worse, agreeing a priori to say "yay" because we are accepting funding from PEP). What would help is someone familiar with TB to work with PEP, or someone from PEP to work with Thunderbird.

Kent, thank you for your kind words! I'm looking forward to working more closely together. I agree, there were cultural clashes, because we're coming from very different ends of the Free Software Community as well as different backgrounds. Having said that, I personally believe, that we can help as well as elevate each other’s project, and we are fully committed to improving our relationship.

Moreover, critics are very welcome – especially from experts in making e-mail user friendly for so many people across the world.

Warmly,

-b

— 

[BA]

On Feb 26, 2016, at 9:10 AM, Nomis101 🐝 <Nomi...@web.de> wrote:

because I couldn't find this "≡" on my keyboard. ;-)

Maybe this will help ;-)

How to enter the "≡" of p≡p ?

On windows

Pls hold down Alt, pressing the + on the numeric keypad, followed by 2261

On Linux

Pls hold Ctrl+⇧ Shift and type U followed by 2261

On Mac

Pls hold down the ⌥ Option, and then type 2261 (on Unicode Hex Input keyboard) 

In TeX

In math mode just state $\equiv$. 

If Unicode isn't supported, ASCII representation is “pEp"

-b

— 

Berna Alp, p≡p project

b...@pep-project.org

[Patrick Brunschwig]

On 26.02.16 09:08, Magnus Melin wrote:
[...]

> On that subject - I do think for Enigmail to ship as a default plugin in
> Thunderbird we need to land the code in comm-central and also start
> using bugzilla as issue tracker for it. If not, you really don't get the
> needed fusion and trust between the communities that is needed to
> confidently ship it. We'd have a very odd situation that it ships (as
> default) and someone finds a problem, you'd have to say "hey, not our
> problem, go file a bug with those guys" - which is clearly unacceptable.
> We'd also not be able to for instance track release blockers in bugzilla
> and so on...

Kent and I are aware of this. It is one of the topics we will certainly
have to address. There is no obstacle on my side for such a shift.

-Patrick

[Nathan Tuggy]

On 2016-02-25 20:29, Matt Harris wrote:

On 26/02/2016 8:18 AM, Nomis101 🐝 wrote:

Am 24.02.16 um 19:32 schrieb R Kent James:

3) An alpha version of a PEP/Enigmail addon is available

I am really looking forward to try this out. :-) I'm regularly visiting
the pEp homepage to see if there are any news about this.

I went to their foundation home page and clicked the link on the top of the page....  that ended my journey.


It is just this sort of error in the "secure by default environment" that leaves me concerned.

It’s a sad day when privacy-oriented, bug-savvy Thunderbird contributors can’t recognize a CAcert-signed website.

​

-- 
Nathan Tuggy [:tuggyne]
nat...@tuggycomputer.com

[Matt Harris]

On 27/02/2016 3:17 AM, Nathan Tuggy wrote:

It’s a sad day when privacy-oriented, bug-savvy Thunderbird contributors can’t recognize a CAcert-signed website.

​

No  it is reflective of my concerns,  are we going to have these sort of meaningless errors just pop up in Thunderbird as well?  It might be a sad day,  but our users are not privacy oriented,  bug savy or contributors.  They just want the link they clicked to work.  To paraphrase what I have been told many times.  I do not care where it goes,  or if it is malicious or not,  that is why I have an anti virus program.

Mozilla refused to include CAcert Bug 215243 refers.  That was back in 2009.  The last update at CAcert was in 2010.  Their todo list refers. 

Is P=P based on using certificates from a CA that can not get itself integrated into Firefox?  I really do not know as to view the source code I need to trust an organization that I am not exactly sure I do trust, and the web site is really devoid of any other information at all about what he technology is,  or how it is proposed to work.


Matt

[Volker Birk]

On Sat, Feb 27, 2016 at 04:58:32PM +1030, Matt Harris wrote:
> On 27/02/2016 3:17 AM, Nathan Tuggy wrote:
> >It’s a sad day when privacy-oriented, bug-savvy Thunderbird contributors

> >can’t recognize a CAcert <http://www.cacert.org/>-signed website.

> No it is reflective of my concerns, are we going to have these sort of
> meaningless errors just pop up in Thunderbird as well?

Neither this “error” is meaningless (actually, it's not an error), nor you will
have something like this in a mass product.

If you'll have a look on p≡p's business homepage, it's this:

https://prettyeasyprivacy.com/

Please check the certificate. You'll see that's the Let's encrypt compromize.

But there is a very good reason to have a CAcert for the source code: actually,
this is one of the only concepts for X.509, which really can transport trust.
And accessing the source code of a security relevant software is a thing where
a MITM is a relevant attack vector.

> It might be a sad day, but our users are not privacy oriented, bug savy or
> contributors.

I'm fully agreeing to this statement. But it's sad exactly the same way, that
the same users don't care for the source code. And if you'll have a look on
what is using a CAcert, it's just the source code, nothing else. Everything
where you have to just click to get it to work is using Let's encrypt – for
the exact reason you're giving here.

> Is P=P based on using certificates from a CA that can not get itself
> integrated into Firefox?

No. p≡p in no way is dependent on CAcert. Hernani is working on a whitepaper
about how p≡p is working. We've it now in the review process. After it's ready,
I will give a note here.

[Sebastian]

On 02/27/2016 07:28 AM, Matt Harris wrote:
> On 27/02/2016 3:17 AM, Nathan Tuggy wrote:
>> It’s a sad day when privacy-oriented, bug-savvy Thunderbird

>> contributors can’t recognize a CAcert <http://www.cacert.org/>-signed

>> website.
> No it is reflective of my concerns, are we going to have these sort
> of meaningless errors just pop up in Thunderbird as well? It might be
> a sad day, but our users are not privacy oriented, bug savy or
> contributors. They just want the link they clicked to work. To
> paraphrase what I have been told many times. I do not care where it
> goes, or if it is malicious or not, that is why I have an anti virus
> program.
>
> Mozilla refused to include CAcert Bug 215243

> <https://bugzilla.mozilla.org/show_bug.cgi?id=215243> refers. That

> was back in 2009. The last update at CAcert was in 2010. Their todo

> <http://wiki.cacert.org/Audit/ToDo>list refers.

>
> Is P=P based on using certificates from a CA that can not get itself
> integrated into Firefox? I really do not know as to view the source
> code I need to trust an organization that I am not exactly sure I do
> trust, and the web site is really devoid of any other information at
> all about what he technology is, or how it is proposed to work.

The organization and community of CACert is in a really bad state
currently. Community and board strongly disagree. CACert has a great
idea, but not a trustworthy organization at the moment.
I can't think of any reasons to use certificates signed by them, as
there's now letsencypt anyway. pep.foundation uses such a certificate.
(so why does cacert.pep.foundation even exist?)

But that's not the point here.
- pEp wants to reach non-exerienced users, they don't know of CACert
- the certificate is only valid for cacert.pep-project.org, thus also
gives a ssl_error_bad_cert_domain for https://pep-project.org/

Sebastian
>
>
> Matt

>
>
> _______________________________________________
> tb-planning mailing list
> tb-pl...@mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>
> --

> python programming - mail server - photo - video - https://sebix.at
> cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

[Sebastian]

Hi

On 02/27/2016 12:31 PM, Volker Birk wrote:
> If you'll have a look on p≡p's business homepage, it's this:
>
> https://prettyeasyprivacy.com/

Thanks for pointing this out. There are so many pEp-websites out there
:) One about the product, the project and the foundation.

Your mail also addresses some issues I raised in my mail on this topic,
which I wrote before yours arrived (because of list moderation?).

Sebastian

> Please check the certificate. You'll see that's the Let's encrypt compromize.
>
> But there is a very good reason to have a CAcert for the source code: actually,
> this is one of the only concepts for X.509, which really can transport trust.
> And accessing the source code of a security relevant software is a thing where
> a MITM is a relevant attack vector.
>
>> It might be a sad day, but our users are not privacy oriented, bug savy or
>> contributors.
> I'm fully agreeing to this statement. But it's sad exactly the same way, that
> the same users don't care for the source code. And if you'll have a look on
> what is using a CAcert, it's just the source code, nothing else. Everything
> where you have to just click to get it to work is using Let's encrypt – for
> the exact reason you're giving here.
>
>> Is P=P based on using certificates from a CA that can not get itself
>> integrated into Firefox?
> No. p≡p in no way is dependent on CAcert. Hernani is working on a whitepaper
> about how p≡p is working. We've it now in the review process. After it's ready,
> I will give a note here.
>
> Yours,
> VB.
>
>

> _______________________________________________
> tb-planning mailing list
> tb-pl...@mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>
> --

[Volker Birk]

On Sat, Feb 27, 2016 at 01:23:44PM +0100, Sebastian wrote:
> The organization and community of CACert is in a really bad state
> currently. Community and board strongly disagree.

That's actually true. I learned from this conflict on FOSDEM.

> CACert has a great idea, but not a trustworthy organization at the moment.

I see this point different.

> I can't think of any reasons to use certificates signed by them, as
> there's now letsencypt anyway.

CAcert and Let's encrypt are trying to solve totally different problems.

CAcert is trying to solve the problem that the concept of commercial CAs
is not trustworthy at all (which is the case).

Let's encrypt is trying to solve the problem that way too many people
don't encrypt their webservers, which to have is better than nothing, and
together with TOFU/CP is a compromize.

The two projects are fighting at different fronts.

> pep.foundation uses such a certificate.

https://pep.foundation is using a Let's encrypt certificate.
https://cacert.pep.foundation is using a CAcert certificate.

https://prettyeasyprivacy.com is using a Let's encrypt certificate.
https://cacert.pep-project.org is using a CAcert certificate.

Or, sorted:

All, which may be used by end users is using Let's encrypt certificates:

https://pep.foundation
https://prettyeasyprivacy.com

All, which is depending on trust is using CAcert certificates. The domain names
give this information, so it's not a surprise. Because security relevant things
are being read by security interested people, this is signalled:

https://cacert.pep.foundation
https://cacert.pep-project.org

https://prettyeasyprivacy.com is for business customers. So it makes no sense
to use CAcert at this point of time. http://pep-project.org is making a
political statement by pointing to the topic not using a “CA of the list” – the
trust problem still is unsolved. TOFU and Certificate Pinning are helpers, but
don't solve the problem.

> - pEp wants to reach non-exerienced users, they don't know of CACert

Yes. And that's why we're not using CAcert certificates on websites for
non-experienced users.

> - the certificate is only valid for cacert.pep-project.org, thus also
> gives a ssl_error_bad_cert_domain for https://pep-project.org/

https://pep-project.org/ is nowhere linked or used. Actually it's a bug that it
does not give an error and deliver nothing.

[Gervase Markham]

On 26/02/16 16:47, Nathan Tuggy wrote:
> It’s a sad day when privacy-oriented, bug-savvy Thunderbird contributors

> can’t recognize a CAcert <http://www.cacert.org/>-signed website.

If you don't have the CAcert root installed in your browser, then how do
you _know_ it's a CAcert-signed website? It says it is in the cert, but
anyone (CAcert or not) can create a cert that says that. The only way to
tell is if it chains up to the CAcert root.

This is the whole point of trust anchors. If you are saying that it's
safe to "recognise" a CAcert-signed website by looking for "CAcert" in
the certificate with an unknown issuer, than you've missed the point of PKI.

Gerv