Discuss mailing list

[Amunak <amunak AT amunak.net>]

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 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-----
      
      
      

--------
You are a member of the OpenNIC Discuss list. 
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org