Discuss mailing list

[Erich Eckner <opennic AT eckner.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Walter,

On Fri, 29 May 2020, Walter H. wrote:

> On 29.05.2020 09:20, Erich Eckner wrote:
> > On Fri, 29 May 2020, Walter H. wrote:
> > > > > how would you S/MIME sign an email using any OpenNIC domain as sender 
> > > > > and not assuming that the recipient has installed anything 3rd party?
> > > >
> > > > Ah, you are talking about getting certificates to be *used* on opennic 
> > > > domains for email? Then I misunderstood your first email, sry.
> > > no problem, but this should be the first step ..., before talking about 
> > > SSL certificates on domains from a 'parallel universe' ...
> >
> > I don't see, why we need encryption/signing on a medium (email on opennic 
> > tlds) that noone uses,
> for the explanation and reasons see below
> > because it cannot interact with the rest of the world,
>
> the same with all other things, welcome in the 'parallel universe' ;-)

you missed my point: The parallel universe is no problem, if the user only 
has to configure stuff, he/she controls (e.g. which dns resolver to use), 
but not stuff, he/she does not control (his/her mail server's resolver).

> > I (and I suspect many others, too) have three reasons upon which they 
> > select the certificate:
> >
> > 1. price
> > 2. convenience
> > 3. usability/security model
> >
> > regarding 3, pgp and s/mime work out similarily good (coverage of 
> > compatible correspondents might differ)
> not really, s/mime has broad support mostly out-of-the-box, with pgo it is 
> different;

That's what I meant with "coverage of compatible correspondents".

> > regarding 1, I prefer to choose "priceless" - which is provided by 
> > letsencrypt for TLS and makes no difference on the pgp/smime front 
> > (because, luckily, my university offers free certificates)
> not only your university also there is a CA which offers S/MIME for free, 
> valid for 1 year; another CA offers them only valid for 3 months - the same 
> with Let's encrypt TLS certs;
> > regarding 2, I prefer "less effort" - and that's the reason, why I choose 
> > pgp. Also, that's the reason, why I asked you, whether there is an 
> > automatic S/MIME certificate distribution mechanism.
>
> what do you mean by automatic distribution mechnism?

I expect to not show up somewhere in person to get my certificate (I 
guess, the priceless CA does fulfill this requirement - my university did 
not). Also, I expect no work involved on the CA end for handing out 
certificates. Especially the later condition I mean by the label 
"automatic distribution mechanism". (Just like there is no work involved 
for handing out certificates via ACME).

So let me ask you once more: How are S/MIME certificates being distributed 
(e.g. from this CA which does it for free)? We could add this to our CA, 
too. I see no problem with that.

> as I see your mails come with hexadecimal cheese-cake as a result of nearly 
> no PGP support out-of-the-box;
> and I don't think this it is intended like that ...
>
> here is a difference in comparison to TLS; PGP is a parallel universe, which 
> is no more than self signed and due to the rare out-of-the-box support in 
> mail agents more waste than sense;

gpg is more than only self signed. But since this part of the discussion 
heads in the wrong direction (pgp vs. s/mime), I'll not go into more 
detail, here.

> (my mail agent also has no PGP support out of the box)
>
> TLS is part of nearly every browser now; I don't think we are talking about 
> oldies like IE 1.0 or so;
>
> therefore my hint; get S/MIME working with OpenNIC domains, then TLS works, 
> too;

S/MIME will never work on OpenNIC, because email will never work on 
OpenNIC. ("never" = "not within a few decades")

Also: I don't see, why that would be true. Why should TLS suddenly work if 
S/MIME works?

> > If it would be convenient (and still priceless), I would probably get an 
> > S/MIME certificate, too.
> >
> > The "parallel universe" argument applies better to S/MIME than to TLS:
>
> not really, with TLS its the same;

ok, maybe I misphrased that. What I meant, was, that the "parallel 
universe" argument applies better to *email* than to *browsing* (and 
other services, to which you connect directly: imap, ssh, ftp, ...).

> with both you have to manually add the root certificate into the cert store 
> to prevent certchain broken errors or similar ...
>
> but the impact of doing this is more critical with TLS than with S/MIME

ok, I see your point.

> > For TLS (e.g. https://acme.libre), you merely need to configure your local 
> > host to resolve via opennic and you're good to go.
>
> No. this is only true for HTTP, not for HTTPS
>
> exact that is the joke with this 'parallel universe';
>
> > For email (e.g. to be able to send to info AT acme.libre), you would need to 
> > configure your mail server to resolve opennic
>
> and that's it; the same with HTTP
>
> with HTTP over SSL/TLS and S/MIME you have exact the same problems; with the 
> big difference, that manually trusting a HTTPS server using a certificate 
> your browser can't validate because of missing root, ... is an absolute NoGo;

I see your point, but you missed mine again: How do I tell my gmail 
account, that it should happily send to help AT acme.libre? This will never 
work (same "never" as above). However, it is trivial for me to visit 
http://acme.libre.

> > - and many mail servers are not operated by their users.
> welcome in the parallel universe ;-)

This has nothing to do with "parallel universe". It simply illustrates, 
that you need different levels of control for the different tasks 
"browsing opennic" and "sending emails to opennic".

> > > I think it would be good to achieve it first on s/mime signing E-mails by 
> > > official CA signed certificates;
> >
> > I think, this whole discussion about S/MIME certificates for opennic tlds 
> > is purely academic, because literally noone uses opennic tlds for email.
> not really, the way S/MIME works is just a little bit more individual;
>
> just thinking of this:
>
> you send me an S/MIME signed mail using a self-signed certificate; as I don't 
> expect that this mail is sent to several mail adresses (recipients, people) 
> at the same time, you can give me a call, or what ever on a different channel 
> informing me about this, and the trust is given; but does anyone connecting 
> to a HTTPS server with self signed certificate get this information on a 
> different channel, too?
>
> that's why I said, that about the NoGo above ..., and by the way, receiving 
> an E-mail from you, is really only from you, but
>
> browsing to  https://www.example.com/ is not just www.example.com also any 
> other host, involved building the page on my browser ...
> just think of things like <script src="https://...";> inside HTML ...
>
> if you would really only allow requests to the one and only host presented in 
> the URL line of the user agent, then there would be rearly no page be useful 
> nor functional/operable ...

I don't really understand, what you want to say with that and what your 
suggestion is for the roadmap.

I understand, that you have concerns adding some strange root ca into the 
browser's trust anchor database (vs. lesser concerns for doing so with 
S/MIME). But I don't see any real alternative, here.

How would we step from S/MIME certificates of opennic domains to TLS 
certificates of opennic domains (if the former worked - which I doubt will 
ever happen, because email will not work fully)?

To me, it sounds, like you would like to wait for the far-away (my 
opinion) milestone of being able to send/receive email from/to opennic 
tlds to/from the rest of the world, then get officially validated S/MIME 
certificates for these and somehow get officially validated TLS 
certificates this way. Do you honestly expect, that at some point, gmail, 
letsencrypt and other "big players" will resolve opennic tlds? Do you 
really want to wait until then with pushing forward TLS certificates on 
opennic domains?

> Greetings,
>
> Walter

regards,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7Q3gAACgkQCu7JB1Xa
e1qtxhAAqLhPPIri+phnD1HMExfr0w7hp6/XdafGheJ4vBfdgpocvV+9dmP8DYV2
1Nj8jMh22HFEd4zeiAgZCAGH39Xvc7Y1Jm3b/tA21GqxVa3uUXdyCz9d8uBdHJM+
ZgxMGR/BUK334DV0wRr/jKfU8qvy1hsMryz3V1wT3keyIxcV1EB95Q++9pA06XO2
0oD+VJLUGN0uX8qXTAQQFDH0y0ph5jt5gPP8NTPkrNcGdiaLxK7g7bTfHmMtSqZJ
A4zRvB2Bb2hPRqNprj/UHrdRgPe8kJ3bPCVE8S5VmmTHpKZFJHDdNUj9nxW4KsXe
bmIBMp+1ax7mMV+PkbDb0PT7WWmdD05VUtphq/Kj7gWdis/rztOv7Bd1Bayixes1
DBiJqsv28NCI6Lcua2Ep7j00gx5teTsyWOt6LHzszYANUoFuTqgde75/7jCZuXqs
YB/ExfKIcQ2qKXsq2tcuznCqRA0uZOvqCYhBBAQInwxUGHNcApnAEaq93RpEPh/N
oeQslJofQt+Th2nvoa2JQXoX0jCFphHeIek5o0INjxpxyNh2DUP7rYN2X/LNpY5X
C6Ls/qdoGrnRN0p6sLfN+KL2nxEiDAbIme6/STeNq9eK7FSBJlk60htCojnlC6QC
fPg14cG1bVFv+S7J56Gf5MgJWCgoZb3tbroEmMt8S1gzQBO49Q0=
=PypX
-----END PGP SIGNATURE-----