Discuss mailing list

[Erich Eckner <opennic AT eckner.net>]

-----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 the 
> > > relevantdocumentation:https://knowledge.broadcom.com/external/article?legacyId=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 page 
> > > ofgfsharehttp://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-----