Discuss mailing list

[Erich Eckner <opennic AT eckner.net>]

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

Hi,

I got now acme2certifier running locally for private use. It needed a few 
fixes (which - thanks to being written in python - are quite easy to 
perform in-situ) and I expect more issues to surface, once the user base 
broadens (for example, I only tested with certbot, and I only tested http 
and dns challenges).

I suggest the following roadmap (open for discussion/suggestions, of 
course):

1. I set up a public-facing acme certifier on a not-so-secure host of mine 
(sry, I only have a virtual server available, which will be insufficiently 
secure for a CA, obviously) based on 
https://github.com/grindsa/acme2certifier. We treat this as experimental, 
but everyone is encouraged to get certificates for their opennic domains, 
use them and report issues to me. I try to fix them (of course, I would 
also be thankful about help, here :-D) and turn the proof-of-concept into 
a production-ready setup.

2. Meanwhile, we figure out, how the key infrastructure should look like: 
Who should hold what key, what should be the default validy duration, 
resign period, etc.

3. At some point, when we're satisfied with the status of 1 and 2, we set 
up the real CA (installation according to 1, design according to 2) and 
switch from using CA-1 to CA-3. Or, we might even switch gradually 
(depending on what we want in 2) and simply advertise CA-1 as 
non-experimental at some point.

What do you think?

regards,
Erich

On Sun, 24 May 2020, Amunak wrote:

> We definitely need to allow for a "standard" approach where
> root/intermediate certificates can be installed "as usual", either by users
> or by (hopefully, maybe, sometime) OS/browser vendors. Without such standard
> approach a lot of use cases cannot be even accounted, and OpenNic's support
> of software and infrastructure would be extremely limited.
>
> However it would also be reasonable to try and make a simple solution for
> end users - something like a browser extension that would (1) give end users
> access to OpenNic domains and that could verify the certificates
> automatically would be an amazing solution. Unfortunately I kind of doubt
> browsers support this for security reasons.
>
> Regardless it's nice to see people finally at least thinking about this.
>
> Amunak
>
> On 2020-05-24 16:38, Erich Eckner wrote:
>       -----BEGIN PGP SIGNED MESSAGE-----
>       Hash: SHA256
>
>       Hi,
>
>       I don't want perfect be the enemy of good, but:
>
>       I think, the "good" solution should be smoothly extendable
>       towards "perfect". Which a
>       other-than-standard-X.509-infrastructure is not, IMHO.
>
>       btw: I'm currently testing
>       https://github.com/grindsa/acme2certifier which is advertised as
>       horribly experimental, but is written in python (so the
>       build/installation process is not as horrible as with go stuff),
>       is actually understandable and currently gives me certificates
>       (with openssl as backend, so we're quite flexible there) which
>       for some reason have no purpose set, currently.
>
>       I would rather use acme2certifier (or some similar tool) for a
>       "good" solution and improve it continuously towards "perfect".
>       Yes, it does not currently securely support ASN and probably
>       many other things, that one might wish for, but from everything
>       I tested so far, this is the only software which was feasible to
>       set up and get running.
>
>       regards,
>       Erich
>
>       On Sun, 24 May 2020, postmaster wrote:
>
>             Greetings,
>
>             I know I am a totally ignorant regarding this
>             subject but:
>             A) Lets assume a temporary solution to satisfy only
>             the browser-requirements
>             B) Lets assume we begin to prefer ONE browser
>             C) Lets assume we do this and more towards OpenNIC
>             becoming a CA or part of another CA
>
>             THANK YOU SO MUCH for spending your time and effort
>             on this!
>
>             Regards,
>             Sandor
>
>             On 2020-05-24 04:42, Erich Eckner wrote:
>                   On Sun, 24 May 2020, Rouben wrote:
>
>                         Hi Erich et al,
>
>
>                   Hi Rob,
>
>                   I'll answer inline (as I usually do).
>
>                         My apologies in advance for
>                         a wall of text. I also want
>                         to repeat that I am
>                         in no way a crypto expert,
>                         and don't claim to fully
>                         understandany of the
>                         above, especially the
>                         algorithms/math/cryptography
>                         behind it, just the
>                         high-level concepts and
>                         "advanced end-user" level
>                         implementation thereof.
>
>                         First, I was referring to a
>                         distributed WoT model by
>                         monkeysphere. Their
>                         browser extension approachis
>                         intriguing and could work
>                         for us... the only
>                         issue is, browser
>                         extensions, especially those
>                         that rely on "native
>                         messaging hosts" (extra
>                         software that needs to be
>                         set up in order to
>                         interactwith the end-user's
>                         OS), are a pain in the ass
>                         to install. It's
>                         more painful than simply
>                         installing a CA cert, I
>                         think,unless we wrap the
>                         browser extension into a
>                         super easy installer for
>                         each major platform.
>
>
>                   I find a browser extension sub-optimal
>                   and certificates which only
>                   work with a browser extension
>                   insufficient: There are many other ways
>                   to interact with the web besides "a
>                   browser". For example, I need ssl
>                   certificates which can be natively
>                   validated by my linux package
>                   manager, curl and openssl itself. Also I
>                   doubt, that browser
>                   extensions cover all the range of
>                   strange browsers (old internet
>                   explorers, text-only browsers, ...)
>
>
>                         Second, I was referring to
>                         Blakely-Shamir secret
>                         sharing that was available
>                         in the commercial and
>                         freeware versions of PGP,
>                         but doesn't seem to be
>                         available in GnuPG (GPG) and
>                         Open/LibreSSL. Here's 
> therelevantdocumentation:https://knowledge.broadcom.com/external/article?legac
>                         yId=HOW
>                         TO42097
>
>                         Note, this is not the same
>                         as "shared secret", i.e.
>                         just copying the private
>                         key and sending its copies
>                         to each person. More
>                         infohttps://en.wikipedia.org/wiki/Secret_sharing
>
>
>                   Yes, I'm aware of that algorithm
>                   (basically, it is similar to RAID).
>                   My concern was, that it required the
>                   creation of a (combined) secret
>                   key, which *then* gets splitted. But I
>                   guess, I'm asking for too much
>                   (in terms of what is already implemented
>                   in software, not what is
>                   possible theoretically), if I want that
>                   there was never the secret key
>                   existent, only parts thereof.
>
>
>                         PGP (the commercial
>                         software) did this neatly.
>                         In a nutshell this feature
>                         allowed to split a PGP
>                         private key into N parts,
>                         each with its own
>                         individual owner and owner's
>                         unique passphrase. In order
>                         to conduct any kind
>                         of crypto operations with
>                         this split key (decryption
>                         and signing), M out of
>                         N owners needed to perform
>                         it, where M < N. The way it
>                         was implemented was
>                         cool too; each owner of a
>                         split key piece could
>                         perform the operation
>                         asynchronously and on their
>                         own, and pass on the
>                         intermediate output of the
>                         operation to the group. Once
>                         a sufficient number of
>                         owners (i.e. M)
>                         performed the operation, the
>                         final output (e.g. decrypted
>                         text, or signed
>                         data/cert) was generated.
>                         For example:
>
>                         ACME Inc has 3 employees
>                         (N=3), Bob, Alice and Joe.
>                         They create a "split"
>                         secret key and each has
>                         their own share of the key
>                         with its own unique
>                         passphrase. They decide on a
>                         2 out of 3 key sharing
>                         policy (M=2), where any
>                         2 of them are required to
>                         perform secret key
>                         operations. The public key
>                         is
>                         not split, and available on
>                         ACME's company website.
>
>                         Carl, a customer of ACME,
>                         uses the public key on the
>                         company's website to
>                         encrypt a sensitive document
>                         and sends it to ACME's
>                         public mailbox.
>
>                         Bob gets Carl's encrypted
>                         email, and uses his share of
>                         the secret key to
>                         produce an intermediate
>                         called Bob1. Bob then passes
>                         on Bob1 to Alice.
>                         Alice's email is set to
>                         autoreply that she's on
>                         vacation until next week.
>                         Bob then passes Bob1 to Joe.
>                         Joe, receives Bob1 and
>                         decrypts it with his
>                         share of the shared secret
>                         key. Since 2 shares of the
>                         keys were used, Joe
>                         obtains the fully decrypted
>                         document sent by Carl. Joe
>                         then shares Carl's
>                         decrypteddocument with the
>                         group.
>
>
>                   Yes, in order for us to meaningfully use
>                   this split-key scheme, there
>                   would be some support needed from the
>                   software (I'll ask on the
>                   openssl-users mailing list, if openssl
>                   supports something like this) -
>                   it would make no sense for us to glue
>                   the private key together
>                   somewhere to extend the validity of the
>                   intermediate ca certificates
>                   ...
>
>
>                         Here's a "democratic CA"
>                         example:
>                         Suppose OpenNIC has 3
>                         elected "cert signers" and a
>                         policy where 2 out of 3
>                         of them need to agree to
>                         sign the cert. You see where
>                         I am going with this?
>
>
>                   yes, this sounds loveley.
>
>                         Just replay the Carl, Alice,
>                         Bob and Joe example above
>                         replacing
>                         Carl'sdocument with Carl's
>                         intermediate CA cert signing
>                         request (CSR) and
>                         "decryption" with "signing",
>                         and the ACME Inc corporate
>                         key with the root CA
>                         cert private key. This could
>                         be used to allow a group of
>                         people to "vote"
>                         whether or not to sign a
>                         candidate's (Carl's) CA cert
>                         with the root CA
>                         cert's private key. And yes,
>                         you could do this in PGP
>                         (not GPG, AFAIK) out
>                         of the box to allow an
>                         organization to split the
>                         responsibility of PGP key
>                         owner identity verification
>                         among a group of people.
>
>                         They key features here were
>                         that:
>                         1. Any secret (including
>                         private/secret key) can be
>                         split into a N of M type
>                         scenario. This can be
>                         achieved with the
>                         Shamir/Blakely secret
>                         sharing
>                         algorithm. An open source
>                         implementation of this is
>                         called gfshare, and is
>                         available as a DEB package
>                         on Ubuntu.
>                         2. IMPORTANT: the shares can
>                         be used by different people
>                         on different
>                         machines at different times
>                         to produce intermediate data
>                         (encrypted?) that
>                         can be securely passed
>                         around to the individual
>                         secret key share holders, so
>                         they can use their key
>                         shares/parts independently
>                         at a time/place convenient
>                         for them.
>                         3. Once the sufficient
>                         number of shareholders used
>                         their shares of the
>                         shared secret key, the
>                         message is fully decrypted.
>                         4. Presumably none of the
>                         shareholders were able to
>                         reconstruct the original
>                         "split" secret key,i.e. Joe
>                         was not able to reconstruct
>                         and captire the
>                         full secret key from Bob's
>                         intermediate message Bob1.
>
>                         The problem here is that the
>                         gfshare implementation won't
>                         work, because it
>                         can't be used to produce an
>                         intermediate output
>                         ("partially encrypted") that
>                         can be passed on to the
>                         remaining shareholders. This
>                         *was* possible with
>                         PGP. AFAIK neither GPG (GNU
>                         Privacy Guard) not
>                         Open/LibreSSL offer this out
>                         of the box. I'm not sure
>                         why, because I think in a CA
>                         scenario, the root
>                         cert'sprivatekey could be
>                         "protected" this way.
>
>                         The man 
> pageofgfsharehttp://manpages.ubuntu.com/manpages/focal/en/man7/gfshare.7.htmldo
>
>                         es offer an interesting
>                         scenario that can be used to
>                         back up a master GPG
>                         private key used to certify
>                         its subkeys. Basically the
>                         idea is that when you
>                         create a GPG key, you have
>                         one master key that's only
>                         allowed to certify
>                         (i.e. edit the key, such as
>                         add/edit/remove subkeys,
>                         extend validity, etc),
>                         and you also have 3 separate
>                         subkeys that are used
>                         exclusively for signing,
>                         encryption/decryption and
>                         authentication. This is
>                         described in detail
>                         here:https://github.com/drduh/YubiKey-Guidein
>                         conjunction to using a
>                         hardware token, like a
>                         YubiKey, to store all the
>                         subkeys. The "master" key
>                         is stored offline, and is
>                         never used on a machine that
>                         goes online. In a
>                         sense, the "master" key is
>                         like the CA Key of your GPG
>                         key, while the
>                         signing, encryption and auth
>                         keys are like the certs you
>                         use for specific
>                         functions. In theory,
>                         instead of storing your
>                         master key in cold storage,
>                         you could use gfshare to
>                         split it up between N
>                         places, and securely store
>                         each shard in different
>                         places. You'd need a certain
>                         number of these shards
>                         to reconstruct the master
>                         key in order to edit your
>                         GPG keypair (eg. do this
>                         every year to extend its
>                         validity). You could also do
>                         the same with the
>                         revocation certificate for
>                         your key and use the same
>                         method to reconstruct
>                         it if your GPG key ever gets
>                         compromised.
>
>                         In case of personal GG keys,
>                         I understand the above is
>                         quite "cypherpunk"
>                         level hardcore, but hey,
>                         it's nice to know it's
>                         possible. In the context of
>                         a CA, I think it's quite
>                         useful... but alas, I lack
>                         the skills/understanding
>                         here to be of any further
>                         help/use.
>
>
>                   The problem I see with this is, that
>                   each time you want to do
>                   something with your key (e.g. sign the
>                   intermediate ca), someone must
>                   assemble it from the shards. This
>                   requires us to send (parts of)
>                   private key material around, which is
>                   undesirable. Additionally, you
>                   must put extra-trust into that someone,
>                   that he will delete the
>                   reconstructed private key properly after
>                   signing (and only signing
>                   what consent was reached, etc.).
>
>                   If it turns out to be impossible to have
>                   a distributed secret key
>                   which does not need to be sent around in
>                   order to actually sign
>                   something, I'm in favour of having
>                   multiple root CAs for now (to
>                   increase the bus factor) and trust, that
>                   the owners of those CAs
>                   handle it properly and only sign what
>                   the community has consent about.
>
>
>                         Rouben
>
>
>                   regards,
>                   Erich
>
>
>
>
>                   --------
>                   You are a member of the OpenNIC Discuss
>                   list.
>                   You may unsubscribe by emailing
>                   discuss-unsubscribe AT lists.opennicproject.org
>
>
>             -- 
>             Low-Cost No-Risk Pilots for Transitioning to
>             Industry 4.0 - a Linux User Group for the
>             Manufacturing Sector
>
>       -----BEGIN PGP SIGNATURE-----
>
>       iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7KhvAACgkQCu7JB1Xa
>       e1oIXQ//YLBceciwYp+Sae4l0QqWAUYCs2ZlH6FZIxxU5W5F6u6dBEii1PLZeXvO
>       WC1fJy9EEYoBw2eMeXsE4G3n8VkkGPxV5criq2a3ZuP6Kz08TKRH+DdfJ1eGubFZ
>       Z/ywbZAPJjuCFPG7WvA74xjOYVomb9024xzkVTuDhLDiEnMV6aC7t+3Ou6MHfoLr
>       iHP56xfLQH3Allh6dKpP5Y8Cab2YmV8KX3WD4b3AZHL4uY46jikVQkiOazxtmHN6
>       xJASBuJ8bAj98LnNvqMvp7UOkPUg+wQdjPMsfuNqTOLhHxNvwEOEri36j0k9p3ip
>       hCvQmgY3hC7HpaSzyRCpc66aYs5efdm7+j7tkYwwaB3VrbGBTORcVCFBvY032Tqy
>       uJddddi7YO262AsfAHU6MdbzOxC7TzgdWeLVNemozbVmyDy/m+v6Y7krBB7qqPcD
>       mhXLlKJ5QOEtHJBfUsns/HW20iAg2DZKm3xAQCdMx95bUGppQXXCy/eMlvvT1kCO
>       aH3BuAcV5SD5VmXyJ5Xtw1cy+oqpXw4XumKiXOw8eLqbjmkfAn3/GORjRfHk51ir
>       aXuuLpYUVHJGxJV/i+bCbhF15ndYMgIEqt6z1Khvdw9+Y2Dmyr0nAUJmuPre44vQ
>       7gUSgarrxzZQi3Xwc9jijyB0gop3+cWRQplDZq2lSxOjDz0TvMU=
>       =lQu9
>       -----END PGP SIGNATURE-----
>
>
> --------
> You are a member of the OpenNIC Discuss list. 
> You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7MvWwACgkQCu7JB1Xa
e1qAFQ//VUiuLO4vCdByMW0jWo2acBqhlwxPq8D/N+aG2iMYF0Kln3sQKshQJ+S3
zqHovZ+dFvzDQLdF8uhiAmPzGTqAw7QopAX/p3HSU3Qxcdqcn92aHl1NJdxkh2Ok
ATrP9WY72YdTyMIylXDXZcyO/Af4zfaDbox88PO0ZSv4ujhUoGLAzW4Kf5FtNiqL
TkbfY2G1hHOlysC/EjLmk2V9V6x4i1e5sSCGt7uWw6ven4qHJ01YYcNah8NAJ8/N
WejC8zKBhnwzSZNRD5Z8QglI8Xvd4utEeMIIpD9TH74Y74UmQ0RfjcUYpUHzxXsJ
A2ZbvtpRHotD5OV662go1TWGoyoIwPcL5L1/u8y7iBgDEGzon+12z9psFI4p0oJB
JsLef6/Q94qYNLARMExx5mSCIVUwiPPwYj90s2YKTAP16rtV4qpOc+cCskVccXFu
FcR4KsyS4o0tkiMprkzLcYc8KeExxIicobSy5qEAiSsz6EIis8FVFTelyjLWRZnJ
0kEAQu4svEMvxJ/y4NWgso5JjWBkZHnMjpAJE1+2MdsRYfiLKzmrV/udMMQDSMz5
cinpvKEqmQvcNx7r9xJk4pXFgWZk0UdEQmqQNrBYu4RAfqE8AptKamNbV43to2UG
o34NjPlkrIrgsvByELetRNP42VsrRISLdFe3LzJXgD52i5It8hQ=
=6dWg
-----END PGP SIGNATURE-----