[ML] Previous Mailing List Discussion

The purpose of the Encryption Working Group is to devise an official Root Certification Authority system for issuing server certificates to OpenNIC domains and user certificates to OpenNIC members.

Moderator: Encryption WG

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

[ML] Previous Mailing List Discussion

Postby JonahAragon » Mon Jan 09, 2017 6:10 pm

The main mailing list chain devolved a bit, these were the emails I thought were the most insightful for future use. Relevant parts are bolded. Hopefully this new board will have more constructive discussion :) Locked because we shouldn't need to add more, but we can reference this in future drafting.

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Re: [ML] Previous Mailing List Discussion

Postby JonahAragon » Mon Jan 09, 2017 6:13 pm

To: discuss@lists.opennicproject.org
From: Amunak <amunak@amunak.net>
Date: Thu, 5 Jan 2017 01:35:25 +0100
Subject: Re: [opennic-discuss] Need for a OpenNIC TLD CA

There could simply be a task group for handling the key, and ideally
we'd strive to have similar measures as cacert for handling the root
cert as cacert (http://www.cacert.org/policy/SecurityPolicy.html).
We
could perhaps also cooperate with cacert to have our intermediate
certificates cross-signed by them which would help with trust of our
certificates.

Ideally even access to the intermediate certificates (which would be
always limited to issuing certs for single TLD
) would be audited, but we
could also just give it to the hands of TLD operators (provided they can
be trusted and are willing to have proper security practices). But there
could simply be an audited API to generate certificates for TLDs that
the registration systems could use to issue certificates. Then there
could also be a public list of issued certs which would help greatly
with potential issues.


So I'm all for having a CA, it only makes sense, but there need to be
good security measures and procedures set in place in order for it not
to be prone to abuse. If someone mishandles the root cert, all trust is
broken. Same with intermediate certs - if you don't even know what
(fradulent) certs were issued you may as well throw the intermediary
away and start over. Fixing issues (even stuff like malicious TLD/T2
operators) is comparatively easier than re-issuing potentially hundreds
or thousands of certificates that people actually use.



Dne 05.01.2017 v 1:00 Jonah Aragon napsal(a):
> I think spreading the public key digitally would be fine...
>
> The issue I was referring to originally had nothing to do with
> distribution at all. I was more thinking about generation of the
> private key for the OpenNIC Root Certificate. Whoever has those
> conceivably has complete control over the Root, and I don't think
> that's a great idea.
>
> For storage I was thinking the private key would be split among the
> Tier 1 operators in sections. No one person should continue to have
> the entire key. Since we would be using Intermediate CAs in my
> scenario, there would be little use for the private key to be used
> outside of the initial generation of those Intermediates and their
> eventual renewal, which would be a relatively rare occurrence.
>
> I'm not sure what a better solution to key generation that would
> satisfy everybody would be though...
>
> Jonah

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Re: [ML] Previous Mailing List Discussion

Postby JonahAragon » Mon Jan 09, 2017 6:15 pm

Date: Fri, 06 Jan 2017 13:41:12 -0700
From: Jeff Taylor <shdwdrgn@sourpuss.net>
To: discuss@lists.opennicproject.org

You mean like the LDAP storage servers which contain all the info for
dyn/free/geek/gopher/indy/oss/parody/pirate domains?
Yes, anyone can
check that information if they have the proper access. And if I
re-enable the whois server, everyone could see the general information.

On 01/05/2017 05:25 AM, Jonah Aragon wrote:
> Just pointing out nobody can reasonably verify domain ownership except
> TLD operators. There isn't like a centralized list of registrations or
> anything ;)
>
> Jonah
>

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Re: [ML] Previous Mailing List Discussion

Postby JonahAragon » Mon Jan 09, 2017 6:18 pm

Date: Mon, 9 Jan 2017 12:59:08 +1100 (AEDT)
From: opennic@ned-ludd.com
To: discuss@lists.opennicproject.org
Subject: Re: [opennic-discuss] Need for a OpenNIC TLD CA

Hello,

As one who was once heavily involved with the internal CA for a
major banking institution I have to weigh in here.

On Mon, 9 Jan 2017, Jonah Aragon wrote:

> 1. Root CA is created and the key is kept completely offline.

This is standard practice for CAs. Additionally, the machine
used to generate Intermediate Issuer keys is kept offline as
well: no network connection at all. When new certificates are
issued, all root CA stakeholders must be physically present to
enter their portion of the key passphrase.


> CA certificates are granted for every TLD operator, to give them the
> ability to grant certificates to their users for each domain registered.

The trick here will be to restrict them to issuing certs for
just their own TLD. I don't believe such a restriction exists
for certs. The only mechanism I can suggest is an active,
post-hoc revocation of any inappropriately issued certs. This
brings with it a whole separate management issue.


> The Root CA public certificate is available on the website for
> download and installation into users' systems. Once that
> certificate is installed, all certificates created by the Root
> and Intermediates will show as trusted in users' browsers.

Often the intermediate will have to be explicitly trusted as
well, unless the certs are provided in a chain file.


> 2. Root CA is created and the key is kept completely offline. A single
> Intermediate "live" certificate is granted for use by every OpenNIC domain.
> TLD operators will be able to use an API system to give certificates to
> their users, but all certificates will come from that single source.

A common, credential-based system poses its own risks. I would
not recommend exposing any parts of the issuing mechanisms to
unauthorised use by providing them online. Since we can assume
OpenNIC users have a certain level of technical skill we could
oblige them to provide TLD issuers with CSRs and get the issuer
to follow a more or less manual process. Given the likely low
volume of certificates this should not be an onerous task.


Regards,
--
Chris Gillings

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Re: [ML] Previous Mailing List Discussion

Postby JonahAragon » Mon Jan 09, 2017 6:18 pm

To: discuss@lists.opennicproject.org
From: Amunak <amunak@amunak.net>
Date: Mon, 9 Jan 2017 18:51:12 +0100
Subject: Re: [opennic-discuss] Need for a OpenNIC TLD CA

Dne 09.01.2017 v 2:59 opennic@ned-ludd.com napsal(a):
> Hello,
>
> As one who was once heavily involved with the internal CA for a major
> banking institution I have to weigh in here.
>
> On Mon, 9 Jan 2017, Jonah Aragon wrote:
>
>> 1. Root CA is created and the key is kept completely offline.
>
> This is standard practice for CAs. Additionally, the machine used to
> generate Intermediate Issuer keys is kept offline as well: no network
> connection at all. When new certificates are issued, all root CA
> stakeholders must be physically present to enter their portion of the
> key passphrase.
>
>> CA certificates are granted for every TLD operator, to give them the
>> ability to grant certificates to their users for each domain registered.
>
> The trick here will be to restrict them to issuing certs for just
> their own TLD. I don't believe such a restriction exists for certs.
> The only mechanism I can suggest is an active, post-hoc revocation of
> any inappropriately issued certs. This brings with it a whole
> separate management issue.
>

There is an extension that can restrict certificates to a certain TLD.
It's not supported in all clients (some don't validate against it) but
it should still be used.

The actual solution should be (in my opinion) to not give full access to
the private key for intermediate certs to the TLD operators but rather
only provide them with an API to generate/sign certs that would:

1) enforce generating only for the correct TLD
2) log and publicly show all requests so that anyone can audit them and
make sure that (for example) a certificate wasn't signed if noone
requested it

>> The Root CA public certificate is available on the website for
>> download and installation into users' systems. Once that certificate
>> is installed, all certificates created by the Root and Intermediates
>> will show as trusted in users' browsers.
>
> Often the intermediate will have to be explicitly trusted as well,
> unless the certs are provided in a chain file.

This is the responsibility of the server operators - just like with
"regular" CAs and certificates you need a chain file they'll have to use
a chain file for certificates issued for OpenNIC TLDs so this is a
non-issue.


>
>> 2. Root CA is created and the key is kept completely offline. A single
>> Intermediate "live" certificate is granted for use by every OpenNIC
>> domain.
>> TLD operators will be able to use an API system to give certificates to
>> their users, but all certificates will come from that single source.
>
> A common, credential-based system poses its own risks. I would not
> recommend exposing any parts of the issuing mechanisms to unauthorised
> use by providing them online. Since we can assume OpenNIC users have
> a certain level of technical skill we could oblige them to provide TLD
> issuers with CSRs and get the issuer to follow a more or less manual
> process. Given the likely low volume of certificates this should not
> be an onerous task.

While I agree that we should want everyone to use CSRs and just have the
requests signed and certificates generated all this can be automated so
that the process is easy and auditable.


>
> Regards,
>

Amunak


Return to “Encryption”

Who is online

Users browsing this forum: No registered users and 1 guest