All in all, what do you want to do? Just keep trusted certificates
or improve the numbers of HKPS Servers in the pool?
So how many certificates are issued with OCSP Stapling? 0.001%? And
of course you need OCSP for that (which is not the case right now,
but yes you do not have the problem with a trusted CA). And what
about pool servers that do not use/do not support OCSP? You want to
kick out 95% of all pool servers because they do not support HKPS?
Great...
But let's go on and imagine we use Letsencrypt for HKPS. So I want a
new certificate, generate a DNS challenge and send it over to?
Kristian? Where is the difference with the current way of manually
signing a CSR? Or you want an API so you can change the records
yourself? How do you verify that and what keeps somebody from
randomly issuing certificates to other people over that API using
his key? You really want anybody to change the zone data? Or you
really rely on Kristian to set the TXT Records for 100 certificates
every month? What do you do if something happens and your
certificate expires? Then you still have your browser warning (or
worse...).
Feel free to propose something how this might work (and maybe setup
a test environment for that)...
I agree that well audited, highly secured CAs are better than a
single CA running somewhere on a simple server. but what keeps the
CA from issuing certificates without OCSP stapling? And even with
OCSP Stapling and revocation checking, if I have a trusted
certificate I can simply set a HPKP Header (lets just imagine these
things really work) so my leaf certificate is the only one that is
trusted and serve that to everybody that connects to my server and
kill all other trusted certificates for a very long time :)
FWIW, if you really want a serious discussion about this, you
probably should stop calling everything you dont agree stupid,
because right now you are the one behaving childish. I think we have
bigger problems if aliens invade, but You are pretty sure that a CA
would never issue rogue certificates (remember Symantec and Google?
;))
But just my 2 cents...
Am 14.01.18 um 13:25 schrieb Heiko
Richter:
Am 14.01.2018 um 13:04 schrieb Moritz
Wirth:
Certificate Revocation is broken in most browsers today so
there is no reliable way to revoke a certificate (especially
if you do not use OCSP).
They are ways to deal with that and any given trusted ca does so
(OCSP stampling and the must-staple header in certs just to name
one of them). Having an untrusted CA like "Kristian-CA" makes it
impossible to deal with that. Is there OCSP or any other kind of
revocation checking available that is supported by all (or most)
clients? I think not...
I don't think that it would be a big problem to get trusted
certificates for HKPS, however the trust problem stays the
same and it comes with other problems.
- You give up authority to a third party. Imagine, you
validate the chain of a certificate to the root and the
intermediate changes (because of compromise/BR Changes,
whatever), it would break the HKPS implementation of all
clients.
1) thats how it is with every CA (including "Kristian-CA").
2) exchanging the intermediate CA is completely immaterial as long
as it is not revoked. class-3-rollovers are happening daily and
they are done in a completely transparant way the users won't
notice.
3) Is there an intermediate ca to encrease security on
"Kristian-CA"? I Think not....
4) I would trust a large, trusted, audited CA anyday over a
"Kristian-CA". That's why they have audits secure their Root-CAs
offline in vaults whereas "Kristian-CA" is just a selfsigned
certificate, probably stored on some server that's connected to
the internet 24/7 and has not class 3 cert to increase security.
4) What kind of stupid argument is that? What happens if
"Kristian-CA" is compromised? Or is that unthinkable? Perhaps you
could set some time aside to discuss what will happen to the certs
if aliens invade, too....
- Trusted certificates may cost some money (except for
Letsencrypt but we have the validation problem there...)
We have no validation problem at Let's Encrypt. Just read my
previous message, I'm not willing to type it all again.
- It is still possible for an attacker to get a certificate
and do bad things with it so there is no advantage of
selfsigned/Kristians certificates over trusted certificates
(except the browser warnings..)
Anything is possible. The problem is not if some social
engineering can give somebody a certificat. The problem is how can
you revoke that cert (with "Kristian-CA" you cannot, with Let's
Encrypt and OCSP-stapling you can). The other prblem is whether
you are trusted by the users. If they receive error messages on a
daily basis or are asked to import "Kristian-CA" that's just wrong
and leaves them clueless and ignorant in case such a message is
really needed because of a revoked cert. Selfsigned certs and
untrusted ca certs belong in experimental environments and
learning children. In the real world there are better ways to deal
with security and trust and since letsencrypt you can have them
for free.
I am not sure how many people really use HKPS over the web
browser, most people just land on Port 11371 or Port 80.. For
the SKS clients it does not matter if the certificate is
widely trusted as it has the root included.
Well, just because GnuPG is fucked up in terms of certificate
validation doesn't mean you should use faulty certificates. Also
Several Browsers are moving to "All-HTTPS", so it's time to stop
the 90s childish self-signed certificate crap and get serious
about using well-established technologies. It's a sad day that
your argument for not caring about correctly established
certificate chains is that GnuPG is faulty and doesn't check
certificates correctly.
Best regards,
Moritz
Am 14.01.18 um 11:45 schrieb Heiko
Richter:
PS: Everything you wrote would have been true in 1998. The
world of SSL has evolved since then......
-------- Weitergeleitete Nachricht --------
Am 14.01.2018 um 10:27 schrieb dirk astrath:
> Hello,
>
>> fist of all CACert is total crap. They have been removed from the linux
>> distributions they were (falsely) included in and no browser ever
>> trusted them because they can't seem to pass the security audits. I
>> realize this comment will probably cause me a lot of ranting but it has
>> to be said that having certficates signed by CACert is no better then
>> signing them yourself.
>
> We could now start a flame-war against CAcert and/or PGP, for or
> against different styles of Web-Of-Trust, for or against different
> tools to be installed to use the this Web-Of-Trust or inclusion in
> mail- or webclients/browsers/distributions ... or not.
>
> But we should not do it here ... ;-)
>
> (NB: There is a difference between selfsigned and CAcert ... see below)
If the ca certificate is self-signed an untrusted by *all* browsers
there is no difference at all. CACert failed all audits and has been
removed from all browsers and operating systems with good reason. Having
a certificate signed by them or signing it yourself makes *no*
difference in terms of security and trust.
Furthermore it is not the question if *you* trust that certificate and
if *you* installed the CACert root into you ca store. The question is
about the error messages a visitor will receive. With CACert,
Kristian-CA and self-signed that message will be
"hkps.sks-keyservers.net" is not trustworthy. With Let's Encrypt the
message will be "You are surfing on a secure site".
>
>> Just use Let's Encrypt certificates. They are short lived certificates
>> and through the dns-01 challenge you will stay in control as you can
> (..)
>> That way you can drastically increase the amount of servers included in
>> the hkps pool while decreasing your workload and and having a huge plus
>> in security and trust through the validatable certificates.
>
> Using LE (or any other being-in-the-browser-CA) will not easily be
> possible.
Sorry, but this is just a flat-out-lie.
Let's Encrypt has the DNS-01 challange where the admin produces a
verification code that Kristian has to publish into his DNS zone through
a txt record. As soon as this is done the admin can create a certificate
that includes the pool hostname *and* his personal individual
hostname(s) and is valid for 3 months. Re-certification can be automated
by the admin through a daily cronjob that will re-cert any certificate
near it's expiry date. If some admin needs to be thrown out Kristian can
just remove the challenge code for his server from the dns zone and the
resigning will fail. Furthermore inclusion of an ip address in the hkps
pool can be automated by checking if the host answers with a valid
certificate.
>
> For your Keyserver you can use a Certificate issues by any CA as long
> as it should not contain one of the pool names. On my server I decided
> to use Let's Encrypt.
You can of course but certificate validation will fail if the user comes
to you through the pool hostname. It's ugly, impolite and just rude to
confront the user with such a message. And a web-of-trust that greets
it's users with a this-site-is-not-trusted message ist just stupid.
>
> To contain one (or more) of the pool names the certificate has to be
> issued (or provided) by the owner of this domain (in this case Kristian).
That's another lie, the admin can create the certificate himself if the
dns-01 challenge is used (see above).
>
> But ...
>
> Kristian will not hand over the private key for a pool-certificate to
> anybody. If he would nearly "anybody" would be able to get the private
> key and CA-signed certificate (as it's outside of Kristians control)
> ... which would not strengthen the security of a pool-certificate.
Why should he have to hand ofer a private key? The admin creates the
certificate himself (see above).
>
> Another way is setting up a CA by Kristian especially for this purpose
> to create certificates only for keyserver-pool-names (and your
> servername). Unfortunately this local CA is in the same status as your
> self-signed certificate or CAcert: Not included in any mail-clients or
> browsers.
>
Having your own private CA that is not trusted by browsers ist just as
bad as using CACert. Greating users (who potentially don't know what
they are talking about) with a this-site-is-insecure message just
stupid, especially when a better alternative is available.
> But ...
>
> This special "Kristian-CA"-case has advantages even without being in
> the mail-clients/browsers:
>
> The software to be used to "ask" the keyserver-pools can contain the
> root-certificate of this CA ...
>
> ... and ... signing your webserver-key by "Kristian-CA" will show
> others, that your server is a trusted server of the keyserver-pool (a
> status you will not get by using a self-signed certificate).
This way has only disadvantages. Especially because the revocation
status of a certificate cannot be checkt by a normal user. If
Kristian-CA revokes a certificate, the user will have a message that is
the same (or almost the same) as the message he always receives. So he
will just click ignore. This reeks of stupidity and incompetence.
>
> Kind regards,
>
> dirk
_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel
_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel
|