Discuss mailing list

[postmaster <postmaster AT welcome.factoryfouroh.net>]

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