Proposal: config for weak, normal, strong algos

[Bernhard Reiter]

Hi,

attached a proposal to help dealing with environments
where a crypto policy strongly prefers or rejects some algos.
It is an idea of generalisation of what we (Intevation and g10code)
may need for the https://wiki.gnupg.org/Gpg4vsnfd2015 contract.

What do you think?

AdTHANKSvance for your feedback,
Bernhard


**DRAFT**
(ber20160310-1)

Goal of the proposal:

How to improve the configuration mechanism in GnuPG v>2.1
to enable admins and users to define and deal
with less and more preferred sets of algorithms.

== Why? to support different policies

This is useful to assist users that want (or have) to
follow a stronger policy towards a group of communication partners.
One example is when dealing with documents that are 
classified as restricted by a government organization.

Each federation or organization is likely to have their own
variant of technical policies. In addition it will change over this.
Therefore, the algorithms shall be configurable, 
so that the same product revision can work in several settings.

== Stay inter-operable and usable
There are a number OpenPGP and CMS installations with already existing 
asymmetric keys out there, so it desirable to stay interoperable 
as much as possible.
Usually a user that has to use a stronger crypto policy with some users
also wants to communicate with many others 
that do not have this requirement.
In order for a crypto application to say usable,
it has to support sending to both groups well.

For a trained user it will be good enough if she 
sees a noticeable warning when trying to use something that is not strong.

So GnuPG has to know which algorithms are considered strong
and has to give this information to the frontends interacting
with the user.

== What needs to be configured
All algorithms that are used cryptographically
are subject of a crypto policy, especially:

# Random numbers
# Symmetric ciphers
# Asymmetric ciphers
# Digest algorithms (crypto hash functions)
# Trust model
# Key derivation function

Not necessary for GnuPG v>2.1 to configure is
the block chain mode CFB as the OpenPGP standard (RFC4880)
only allow this one.

== making a difference for reading, writing and creating

The use of algorithms may be considered different when
# an encrypted document is coming in. The software could decrypt,
  even if less desirable algorithms were used.
# If a document is signed or encrypted, here a minimum strength
  of algorithms should be used, though still tolerable for
  interoperability with old installations.
# When creating a key-pair for asymmetric crypto use in the future,
  a higher minimum strength must be used.

== Proposed model: weak, normal and strong sets

Right now GnuPG (v=2.1.11) already as two sets of algorithms:
weak and normal. For example the option {{{--weak-digest}}}
can be mark digest algorithms as //weak//.

We propose to add options for {{{--strong-digest}}}
and similar {{{weak}}} and {{{strong}}} options
similar for all algorithms that need configuration.

All non-mentioned algorithms are considered to be in //normal// set.

=== Bitlength

Just like the 
[[https://gnupg.org/faq/whats-new-in-2.1.html#keylist|new format of 
keylistings in 2.1]]
we propose to specify an greater or lesser bit length for the algorithms
with a '+' or '-' where this is appropriate, e.g.
{{{--strong-cipher-algo=rsa3072+}}} or
{{{--weak-cipher-algo=rsa1024-}}}.

== Disallowing use or force warnings

GnuPG (v=2.1.11) can already allow and disallow the use
of weak digest algorithms with the option {{{--allow-weak-digest-algos}}}.

If any strong algorithms are configured by the options outlined above,
we propose that they are prefered by default and that the
application MUST issue a noticeable warning if a //normal//
algorithm is to be used. These warnings can be avoided by not
configuring //strong// algorithms.

(Optional) GnuPG should also check that at least one working
combination of strong algorithms is configured if one is configured at all.

Algorithms can be disallowed by declaring them //weak// and
a proposed {{{--disallow-weak-algos}}}.


== Admin ability to restrict user choice

Many crypto policies will allow the user to still send out
encrypted documents with normal but not strong settings,
if they do not desire the strong settings for this communications.
However they will want to force that weak algorithms may
not be used as all and the warning are mandatory.
In addition the set of algorithms considered strong may be fixed.

This there must be a configuration option that can only be changed
by the administrator of the computer and cannot overridden by the user.

We propose do use a file protected by the administration rights
of the operating system, e.g. {{{/etc/gnupg/gpg.conf}}} or
{{{/etc/gnupg/gpg-agent.conf}}}.
That is read additionally to the users configuration file.

An exclamation mark ("!") in front of the configuration line
could be used to mark this configuration as fixed for the user.
If there is no mark a user can override a system wide configuration 
entry with her own settings.

== weak set defaults

MD5 is an compiled in weak digest algorithm.

== default strong set

Default could be an empty strong set.
Organizations could provide a set of configuration files to their
admins that matches their policy.

-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160310/7b618f63/attachment.sig>