[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

cfrg                                                       K. Mindermann
Internet-Draft                                           iC Consult GmbH
Intended status: Informational                                   L. Teis
Expires: 21 April 2021                                   18 October 2020


                          Secure Crypto Config
               draft-kaimindermann-securecryptoconfig-00

Abstract

   Choosing secure cryptography algorithms and their corresponding
   parameters is difficult.  Also, current cryptography APIs cannot
   change their default configuration which renders them inherently
   insecure.  The Secure Crypto Config provides a method that allows
   cryptography libraries to change the default cryptography algorithms
   over time and at the same time stay compatible with previous
   cryptography operations.  This is achieved by combining three things
   standardized by the Secure Crypto Config: (1) A process that is
   repeated every two years, where a new set of default configurations
   for standardized cryptography primitives is published in a specific
   format. (2) A Secure Crypto Config Interface that describes a common
   API to use cryptography primitives in software (3) using COSE to
   derive the parameters from output of cryptography primitives,
   otherwise future changes of the default configuration would change
   existing applications behavior.

Note to Readers

   Comments are solicited and should be addressed to the GitHub
   repository issue tracker (https://github.com/secureCryptoConfig/
   secureCryptoConfig) and/or the author(s)

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Mindermann & Teis         Expires 21 April 2021                 [Page 1]


Internet-Draft                     SCC                      October 2020


   This Internet-Draft will expire on 21 April 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
       1.2.1.  Conventions and Definitions . . . . . . . . . . . . .   5
       1.2.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.3.1.  Secure Crypto Config Use Cases  . . . . . . . . . . .   5
       1.3.2.  Cryptography Use Cases  . . . . . . . . . . . . . . .   6
   2.  Requirements and Assumptions  . . . . . . . . . . . . . . . .   9
     2.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   9
     2.2.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  12
   3.  Security Levels . . . . . . . . . . . . . . . . . . . . . . .  12
     3.1.  Security Level 1 - Low  . . . . . . . . . . . . . . . . .  12
     3.2.  Security Level 2  . . . . . . . . . . . . . . . . . . . .  12
     3.3.  Security Level 3  . . . . . . . . . . . . . . . . . . . .  12
     3.4.  Security Level 4  . . . . . . . . . . . . . . . . . . . .  13
     3.5.  Security Level 5 - High . . . . . . . . . . . . . . . . .  13
     3.6.  Security Level Constraints  . . . . . . . . . . . . . . .  13
       3.6.1.  Information classification  . . . . . . . . . . . . .  13
       3.6.2.  Longevity . . . . . . . . . . . . . . . . . . . . . .  13
       3.6.3.  Constrained Devices . . . . . . . . . . . . . . . . .  14
       3.6.4.  n-Bit-Security  . . . . . . . . . . . . . . . . . . .  14
       3.6.5.  Attacker Resources and Capabilities . . . . . . . . .  14
   4.  Consensus Finding Process and entities  . . . . . . . . . . .  15
     4.1.  Consensus Finding . . . . . . . . . . . . . . . . . . . .  15
       4.1.1.  Regular Process . . . . . . . . . . . . . . . . . . .  15
       4.1.2.  Emergency Process . . . . . . . . . . . . . . . . . .  16
       4.1.3.  Requirements for Selection of Cryptography Algorithm
               and Parameters  . . . . . . . . . . . . . . . . . . .  17
     4.2.  Entities  . . . . . . . . . . . . . . . . . . . . . . . .  17



Mindermann & Teis         Expires 21 April 2021                 [Page 2]


Internet-Draft                     SCC                      October 2020


   5.  Publication Format and Distribution . . . . . . . . . . . . .  17
     5.1.  Versioning  . . . . . . . . . . . . . . . . . . . . . . .  18
     5.2.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     5.3.  Secure Crypto Config IANA Registry  . . . . . . . . . . .  18
       5.3.1.  Example for Secure Crypto Config IANA Registry  . . .  19
       5.3.2.  Utilized Algorithm Registries . . . . . . . . . . . .  19
     5.4.  Data Structures . . . . . . . . . . . . . . . . . . . . .  20
     5.5.  Human readable format . . . . . . . . . . . . . . . . . .  21
     5.6.  Official Secure Crypto Config Repository  . . . . . . . .  22
       5.6.1.  Location of Secure Crypto Config Repository . . . . .  22
       5.6.2.  Format of Secure Crypto Config Repository . . . . . .  22
       5.6.3.  Integrity/Signing process . . . . . . . . . . . . . .  23
   6.  Secure Crypto Config Interface  . . . . . . . . . . . . . . .  24
     6.1.  Semantic Versioning . . . . . . . . . . . . . . . . . . .  24
     6.2.  Deployment of (custom) Secure Crypto Config with
           Interface . . . . . . . . . . . . . . . . . . . . . . . .  24
       6.2.1.  Delivery of Secure Crypto Config with Interface . . .  26
       6.2.2.  Using a custom Secure Crypto Config Repository  . . .  26
       6.2.3.  Integrity Check . . . . . . . . . . . . . . . . . . .  26
     6.3.  Application Programming Interface (API) . . . . . . . . .  27
       6.3.1.  Methods and Parameters  . . . . . . . . . . . . . . .  27
       6.3.2.  Automatic Parameter Tuning  . . . . . . . . . . . . .  27
       6.3.3.  Output of readable Secure Crypto Config . . . . . . .  28
     6.4.  TODOs . . . . . . . . . . . . . . . . . . . . . . . . . .  28
   7.  Cryptography Library Implementation Specification . . . . . .  28
   8.  Cryptography Algorithm Standards Recommendation . . . . . . .  29
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
     9.1.  Consensus Finding . . . . . . . . . . . . . . . . . . . .  29
     9.2.  Publication Format  . . . . . . . . . . . . . . . . . . .  29
     9.3.  Cryptography library implementation . . . . . . . . . . .  29
     9.4.  General Security Considerations . . . . . . . . . . . . .  30
       9.4.1.  Special Use Cases and (Non-)Security Experts  . . . .  30
     9.5.  Security of Cryptography primitives and
           implementations . . . . . . . . . . . . . . . . . . . . .  30
       9.5.1.  Security Guarantees . . . . . . . . . . . . . . . . .  30
       9.5.2.  Threat Model / Adversaries  . . . . . . . . . . . . .  30
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  31
     11.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  32
     A.1.  JSON Secure Crypto Config . . . . . . . . . . . . . . . .  32
   Appendix B.  Example Java Interface using Secure Crypto Config  .  33
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  39
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39

1.  Introduction




Mindermann & Teis         Expires 21 April 2021                 [Page 3]


Internet-Draft                     SCC                      October 2020


1.1.  Motivation

   Cryptography needs standardization to work across various domains and
   to be interoperable between different implementations.  One domain
   that is not covered sufficiently by cryptography standards is the
   selection and maintenance of cryptography algorithms and their
   parameters.  Choosing an appropriate and secure cryptography
   algorithm alone is difficult.  Yet, even more difficult is the choice
   of the required and matching parameters for that algorithm (e.g.
   Argon2 has 10 input parameters (https://tools.ietf.org/html/draft-
   irtf-cfrg-argon2-10#section-3.1)).  After the choice has been made,
   all involved parties need to use exactly this configuration.  There
   is no specification on how the chosen cryptography configuration
   should be stored, distributed and retrieved.  Furthermore, supporting
   more than one configuration or being able to add future
   configurations is not defined.  That reduces software compatibility
   and increases maintenance efforts.

   Cryptography algorithm implementations, regardless of for one
   algorithm or multiple ones, offer some kind of Application
   Programming Interface for developers to use the algorithms.  Yet, in
   many cases these interfaces provide no abstraction from the
   underlying algorithm but expose much of the internal states and
   parameters.  Also the more abstracting interfaces, usually found in
   the standard libraries of programming languages, require users to
   have much cryptography experience to use them correctly and securely.
   Moreover, even approaches that tried to increase usability by
   providing defaults, these defaults become quickly outdated but cannot
   be changed in the interface anymore as applications using these
   defaults rely on that functionality.

   It sounds a lot like a problem for software engineering and not for
   cryptography standardization.  But software engineering alone cannot
   provide a programming interface for cryptography algorithms that also
   works for future algorithms and parameters and at the same time is
   able to change the default implementation easily.  Both the choice of
   the algorithm/parameters and the default behavior must be automated
   and standardized to remove this burden from developers and to make
   cryptography work by default and in the intended secure way.

   The Secure Crypto Config approaches this problem first by providing a
   regular updated list of secure cryptography algorithms and
   corresponding parameters for common cryptography use cases.  Second,
   it provides a standardized Application Programming Interface which
   provides the Secure Crypto Config in a misuse resistant way to
   developers.  Third, it leverages an already standardized format
   ([RFC8152]) to store the used parameters alongside the results of
   cryptography operations.  That ensures that future implementations



Mindermann & Teis         Expires 21 April 2021                 [Page 4]


Internet-Draft                     SCC                      October 2020


   can change their default cryptography algorithms but still parse the
   used configuration from existing data and perform the required
   cryptography operations on it.

   Each of these approaches could be used on its own.  Yet, the
   combination of them allows software to be more easy to maintain, more
   compatible to other cryptography implementations and to future
   security developments, and most importantly more secure.

   The Secure Crypto Config makes common assumptions that are not true
   for all possible scenarios.  In cases where security experts are
   indeed involved and more implementation choices have to be made, the
   Secure Crypto Config still allows the usage of predefined or even
   custom cryptography algorithms and parameters.

1.2.  Terminology

1.2.1.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.2.  Terms

   The terms "API", "attack", "authenticity", "availability", "break",
   "brute force", "cipher", "ciphertext", "classified", "classification
   level", "confidentiality", "cryptographic hash", "encrypt",
   "encryption", "initialization vector (IV)", "integrity", "key",
   "mode", "nonce", "password", "plain text", "plaintext", "protocol",
   "security", "security level", "threat", "trust", in this document are
   to be interpreted as described in [RFC4949].

   The term "hash" is used as a synonym for "cryptographic hash".

   The term "cryptographic primitive" is used in this document to
   describe a generic building block used in the field of cryptography
   e.g.  Hashing, symmetric encryption.

1.3.  Use Cases

1.3.1.  Secure Crypto Config Use Cases

   The Secure Crypto Config has the following main use cases:





Mindermann & Teis         Expires 21 April 2021                 [Page 5]


Internet-Draft                     SCC                      October 2020


   *  Centralized and regularly updated single source of truth for
      secure algorithms and their parameters for most common
      cryptography primitives and use cases.

   *  Both machine and human readable format to specify the above
      mentioned cryptography algorithm/-parameter configuration.  The
      format is also extensible to allow others (e.g. governmental or
      commercial organizations) to define their own set of cryptography
      configurations.

   *  Standardized cryptography API that not uses the Secure Crypto
      Config for the selection of the most recent cryptography
      configurations but also uses a standardized cryptography operation
      output format to enclose the chosen parameters.

1.3.2.  Cryptography Use Cases

   The Secure Crypto Config covers cryptography algorithm and parameter
   configurations for widely used cryptography use cases defined in the
   following sections.

1.3.2.1.  Symmetric Encryption

   Symmetric Encryption is an important cryptographic primitive
   especially as it is usually multiple magnitudes faster both for
   encryption and decryption than asymmetric cryptography.  Yet, the
   secret has to be shared with all participants.

   The only expected input parameters by cryptography users:

   *  plaintext

   *  secret key

   Expected output: ciphertext.

   Additional Parameters often required in practice:

   *  Algorithm

   *  Block-Mode

   *  IV

   *  Padding-Mode

   *  Authentication Tag size




Mindermann & Teis         Expires 21 April 2021                 [Page 6]


Internet-Draft                     SCC                      October 2020


   Possible secure usage:

   *  A256GCM;3;AES-GCM mode w/ 256-bit key, 128-bit tag

   *  ChaCha20/Poly1305;24;ChaCha20/Poly1305 w/ 256-bit key, 128-bit tag

1.3.2.2.  Asymmetric Encryption

   Beside symmetric encryption is asymmetric encryption another
   important cryptographic primitive to considered.

   The only expected input parameters for encryption:

   *  plaintext

   *  public key

   Expected output: ciphertext.

   The only expected input parameters for decryption:

   *  ciphertext

   *  private key

   Possible secure usage:

   *  RSA

   *  RSAES-OAEP w/ SHA-512,-42,RSAES-OAEP w/ SHA-512

1.3.2.3.  Hashing

   Hashing is an important cryptographic primitives and is often needed
   as a part of many other cryptographic use cases e.g. password
   derivation.

   The only expected input parameters by cryptography users:

   *  plaintext

   Expected output: hash.

   Possible secure usage:

   *  SHA-512 (TEMPORARY - registered 2019-08-13, expires
      2020-08-13);-44;SHA-2 512-bit Hash




Mindermann & Teis         Expires 21 April 2021                 [Page 7]


Internet-Draft                     SCC                      October 2020


   *  SHAKE256 (TEMPORARY - registered 2019-08-13, expires
      2020-08-13);-45;256-bit SHAKE

1.3.2.4.  Password Hashing

   The secure storage of passwords requires hashing.  Yet, password
   hashing requires that the hashing can not be performed very fast to
   prevent attackers from guessing/brute-forcing passwords from leaks or
   against the live system.  E.g. it is totally fine for users if the
   login takes 0.1 seconds instead of microseconds.  This results in
   special families of hash algorithms which offer additional tuning
   parameters.

   The only expected input parameters by cryptography users:

   *  plaintext

   *  hash-algorithm

   Expected output: hash.

   Possible secure usage:

   *  Argon2id

1.3.2.5.  Key Generation

   *  [ ] TODO should key generation be considered?  (Symmetric/
      Asymmetric)

   A key is necessary for many cryptographic use cases e.g. symmetric
   and asymmetric encryption.  Therefore, key generation is an important
   part while implementing cryptographic code.

   The only expected input is the intended use case.

   Expected output: key.

   Possible secure generation:

   *  Use of CSPRNG

   *  Keys derived via derivation function from passwords/other keys

1.3.2.6.  Digital Signatures

   Signing is an important and often needed cryptographic use case.  It
   is based on the principle of asymmetrical encryption.



Mindermann & Teis         Expires 21 April 2021                 [Page 8]


Internet-Draft                     SCC                      October 2020


   The only expected input parameters for signing:

   *  plaintext

   *  private key

   Expected output: signature.

   The only expected input parameters for verifying the signature:

   *  signature

   *  public key

   Expected output: valid/not-valid.

   Possible secure usage:

   *  ECDSA

   *  ES512;-36;ECDSA w/ SHA-512

2.  Requirements and Assumptions

2.1.  Requirements

   In the following all requirements are listed that regard the Secure
   Crypto Config or the Secure Crypto Config Interface.

   *  Security Level Requirements: The Secure Crypto Config should
      define different security levels.  E.g. information has different
      classification levels and longevity.  Additionally, cryptography
      operations could not or much slower perform on constrained
      devices, which should also be handled with the security levels.
      For each security level the consensus finding process and entities
      shall publish a distinct secure crypto config.

   *  Consensus Finding Process and entities:

      -  The Secure Crypto Config must be renewed regularly.

      -  The Secure Crypto Config must be renewable on-demand.

      -  There must be a guideline on which entities must agree to
         publish a new Secure Crypto Config.

      -  There must be a guideline on which entities may participate in
         the consensus finding process and how they may do so.



Mindermann & Teis         Expires 21 April 2021                 [Page 9]


Internet-Draft                     SCC                      October 2020


      -  There must be a guideline on how to determine broad
         availability of both cryptography algorithms and chosen
         parameters.

   *  Publication Format and Distribution Requirements:

      -  General:

         o  The Secure Crypto Config must be easily publishable by the
            committee.

         o  Standardized unique and distinct names for (1) cryptography
            algorithms (2) their parameters and (3) the combination of
            the algorithm with set parameters.  Otherwise ambiguity
            would make it harder for developers and cryptography
            implementors to make correct and secure choices.

         o  There must be a versioning that allows to distinguish
            between Secure Crypto Configurations and what is the latest
            Secure Crypto Config.

         o  There must be a deprecation process that ensures usage of
            outdated/insecure Crypto Configurations ceases.

         o  There must be an official source where this Secure Crypto
            Config is maintained and can be obtained from (e.g. via the
            WWW).

         o  The official source format of the Secure Crypto Config must
            be cryptographically protected to ensure its integrity and
            authenticity.

         o  Other published formats derived from the source format (e.g.
            for human readability on a webpage) do not have to be
            cryptographically protected but should be generated
            automatically from the source format.

         o  The official source should also provide information about
            the Secure Crypto Config Interface that should be utilized
            for the application of the Secure Crypto Config.

         o  The Secure Crypto Config must specify how it can be extended
            (e.g. more security levels) and how derivatives work.

      -  Human readable

         o  The Secure Crypto Config must have a human readable format.




Mindermann & Teis         Expires 21 April 2021                [Page 10]


Internet-Draft                     SCC                      October 2020


         o  The Secure Crypto Config must allow non-experts to find
            secure cryptography algorithms and appropriate parameters
            for common cryptography use cases.

         o  The Secure Crypto Config human readable publication format
            should only use easy to comprehend data structures like two-
            dimensional tables.

      -  Machine readable

         o  Cryptography libraries, regardless of the programming
            language, should be able to directly map (without extensive
            parsing) the Secure Crypto Config to their implementation

         o  Must be easy to verify which Secure Crypto Config is used /
            was used (e.g. in Continuous Integration platforms)

         o  Must be easy to verify the authenticity of the Secure Crypto
            Config (e.g. is this really what the CFRG has published)

   *  Cryptography library integration requirements:

      -  Easy to integrate by cryptography libraries

      -  Experts should still be able to use/access the unaltered output
         of cryptographic primitives

      -  Recommendation what should be the default Secure Crypto Config
         for a cryptography library (e.g. should it be the one with the
         highest security level or _only_ a weaker one?)

      -  Recommendation what should a cryptography library do if it can
         not support the parameters specified in the latest Secure
         Crypto Config.  (E.g. key size for RSA would be n*2 and the
         library supports only n)

      -  Recommendation on how a cryptography library should integrate
         the Secure Crypto Config so that it is up to date as soon as
         possible after a new Secure Crypto Config has been published

   *  General Requirements:

      -  Interoperability with other standards/formats (e.g.  [RFC8152])

      -  The Secure Crypto Config should cover most common cryptography
         primitives and their currently broadly available and secure
         algorithms.




Mindermann & Teis         Expires 21 April 2021                [Page 11]


Internet-Draft                     SCC                      October 2020


      -  The Secure Crypto Config should be protected against attackers
         as defined in Section 3.6.5

      -  The Secure Crypto Config should prevent non-experts to
         configure cryptography primitives in an insecure way.

      -  The Secure Crypto Config should not prevent experts from using
         or changing all parameters of cryptography primitives provided
         by a cryptography library/API.

2.2.  Assumptions

   The Secure Crypto Config assumes that both the proposed algorithms
   and the implementations (cryptography libraries) for the cryptography
   primitives are secure.  This also means that side-channel attacks are
   not considered explicitly.  It is also assumed that programmers,
   software engineers and other humans are going to use cryptography.
   They are going to make implementation choices without being able to
   consult cryptography and security experts and without understanding
   cryptography related documentation fully.  This also means that it is
   not considered best practice to assume or propose that only
   cryptography experts (should) use cryptography (primitives/
   libraries).

3.  Security Levels

   The Secure Crypto Config must be able to provide a secure parameter
   set for different security levels.  These security levels depend on
   the following security constraints: *Information classification
   (Secret, Confidential), Longevity (less than one day, more than a
   day), Constrained devices (constrained, not constrained)*. They are
   defined in Section 3.6 below.  The Secure Crypto Config provides 5
   common security levels for which official algorithm/parameter choices
   are published.

3.1.  Security Level 1 - Low

   Confidential information, regardless of the other two constraints

3.2.  Security Level 2

   Secret information, less than one day longevity, constrained device

3.3.  Security Level 3

   Secret information, less than one day longevity, non-constrained
   device




Mindermann & Teis         Expires 21 April 2021                [Page 12]


Internet-Draft                     SCC                      October 2020


3.4.  Security Level 4

   Secret information, more than a day longevity, constrained device

3.5.  Security Level 5 - High

   Secret information, more than a day longevity, non-constrained device

3.6.  Security Level Constraints

3.6.1.  Information classification

   Information classification within this document is about the
   confidentiality of the information.  Not all information is equally
   confidential, e.g. it can be classified into different classes of
   information.  For governmental institutions usually three classes are
   used: Confidential, Secret, or Top Secret.  The Secure Crypto Config
   considers only *Confidential* and *Secret* for its standardized
   security levels.  Further levels with other classifications can be
   added by other organizations.  Additionally, in common (non-
   governmental) use cases data is not labelled with an information
   class.  Hence, often only one class is chosen for the cryptography
   processing of all data.

   The Secure Crypto Config does not endorse a definition of the
   information classes, yet *Secret* information is to be considered to
   have higher confidentiality requirements than *Confidential*
   information.

3.6.2.  Longevity

   The time how long information has to be kept confidential can
   influence cryptography parameters a lot.  Usually what you talked
   about with your friends should be kept confidential for a life time.
   Yet, a public trade transaction must only be confidential until the
   trade was executed which can happen in milliseconds.  It directly
   influences a very important attacker resource: The time an attacker
   has to try to gain access to the confidential information.  The
   Secure Crypto Config considers only two ranges of longevity for its
   standardized security levels: *short longevity* of less than one day
   and *long longevity* of a day or more than a day.  Further levels
   with other longevity levels can be added by other organizations.









Mindermann & Teis         Expires 21 April 2021                [Page 13]


Internet-Draft                     SCC                      October 2020


3.6.3.  Constrained Devices

   For cryptography often complex computations have to be executed.
   Yet, not all environments have the same hardware resources available.
   E.g. it is not always the case that the used processors have
   dedicated cryptography hardware or even specialized execution units
   or instruction sets like [AESNI].  Detailed discussion and
   definitions can be found in [RFC7228].  Yet, their definitions are
   too concrete to be used in the Secure Crypto Config's standardized
   security levels.  Therefore, the Secure Crypto Config uses defines
   constraint devices not based on concrete processing power (e.g. 100k
   instructions per second):

   A device is constrained when it has *multiple orders of magnitudes*
   less resources than a current (not a new one, but broadly in use at
   the time of publication of a Secure Crypto Config!) standard personal
   computer.

   For example if a current standard personal computer can encrypt with
   1 GiB/s, a constrained device would be all devices that can only
   perform the same cryptography operation with less than 10 MiB/s.
   Resources can be everything important for cryptography like dedicated
   cryptography hardware, instruction sets, memory, power consumption,
   storage space, communication bandwidth, latency etc.  The Secure
   Crypto Config considers only *constrained* and *non-constrained* for
   its standardized security levels.  Further levels with other
   constrained resource definitions can be added by other organizations.

3.6.4.  n-Bit-Security

   n-Bit Security Level:

      A cryptographic mechanism achieves a security level of n bits if
      costs which are equivalent to 2^n calculations of the encryption
      function of an efficient block cipher (e.g.  AES) are tied to each
      attack against the mechanism which breaks the security objective
      of the mechanism with a high probability of success.  BSI

3.6.5.  Attacker Resources and Capabilities

   The Secure Crypto Config considers only the following same attacker
   resources and capabilities for all standardized security levels:

   *  The attacker knows all used algorithms and parameters except
      secrets according to Kerckhoffs's principle.






Mindermann & Teis         Expires 21 April 2021                [Page 14]


Internet-Draft                     SCC                      October 2020


   *  The attacker has access to the system used for cryptography
      operations and can utilize its cryptography operations apart from
      obtaining secrets.

   *  The attacker can utilize very high-performance computing resources
      such as super computers and distributed computing (e.g. this
      includes very high memory, storage, processing and networking
      performance)

   Further security levels with other attacker definitions can be added
   by other organizations.

4.  Consensus Finding Process and entities

   To provide a Secure Crypto Config it is necessary to agree upon a
   secure and appropriate cryptographic parameter set for each security
   level (see Section 3).  This must happen in a common consensus
   finding process which takes place during a regular intervals.  The
   consensuns finding process is based on the established RFC process
   during which the Secure Crypto Config Working Group decides in
   cooperation with the Crypto Forum Research Group (CFRG) and other
   institutions like the Bundesamt fuer Sicherheit in der
   Informationstechnik (BSI) or the National Institute of Standards and
   Technology (NIST) for a set of secure parameters.  After the
   successful decision the agreed on parameters can be added in the
   defined pulibcation data structures (see Section 5.4) and provided on
   the repository platform.

4.1.  Consensus Finding

   Consensus must be found two years after the last consensus was found.
   This ensures that there is a new Secure Crypto Config every two
   years, even if the configuration itself has not changed.  There is a
   regular process and an emergency process to release Secure Crypto
   Configurations.

4.1.1.  Regular Process

   The process has three phases that MUST be finalized within 2 years:

   *  (1) One year *Proposal phase* during which all participating
      entities must propose at least two cryptography algorithms and
      parameters per cryptography use case per security level.

   *  (2) Six months *Consensus finding phase* during which all
      participating entities must agree on a common Secure Crypto
      Config.




Mindermann & Teis         Expires 21 April 2021                [Page 15]


Internet-Draft                     SCC                      October 2020


   *  (3) Six months *Publication phase* ensures the publication of the
      final Secure Crypto Config AND allows the Secure Crypto Config
      Interface and other cryptography implementations to integrate the
      necessary changes.

   During the Proposal phase the proposed algorithms and all necessary
   parameters should be submitted in table form for each security level
   and defined cryptographic use case like proposed.  This table format
   is simply structured and is easy to read by human as the Consensus
   finding phase can only be done manually.  It is important that the
   parameters for each cryptographic use case depending on its security
   level can be found easily by the participants of the consensus
   finding process such that it is possible to get to an agreement
   faster.

4.1.2.  Emergency Process

   *  [ ] TODO How can the Working Group alter the Secure Crypto Config
      IANA registry / or use the RFC Errata process?

   In cases when a regularly still valid Secure Crypto Config would
   become insecure regarding either a proposed algorithm or a proposed
   parameter choice it must be revised with the following process:

   1.  Determine the insecure configuration.

   2.  Remove the insecure configuration.

   3.  Publish the revised Secure Crypto Config with a new patch
       version.

   4.  Mark the old (unrevised) Secure Crypto Config as deprecated.

   Examples for emergency cases are drastically better brute force
   algorithms or brute force performance (e.g. quantum computers/
   algorithms), drastically discovered flaws in proposed algorithms and
   their configurations.

   An applied emergency process results in the problem that currently
   used Secure Crypto Config Interface versions are no longer up-to-
   date, because they are still supporting the no longer secure
   algorithms.  Therefore the corresponding algorithms need to be marked
   as insecure.  If e.g. an proposed algorithm gets insecure this can be
   marked inside the corresponding Secure Crypto Config IANA registry
   entry as no longer proposed to make the users aware of its
   insecurity.  The Working Group itself can decide when to alter the
   Secure Crypto Config IANA registry.




Mindermann & Teis         Expires 21 April 2021                [Page 16]


Internet-Draft                     SCC                      October 2020


4.1.3.  Requirements for Selection of Cryptography Algorithm and
        Parameters

   The Secure Crypto Config MUST only propose cryptography algorithms
   and parameters that fulfill the following requirements:

   *  Cryptography algorithms and parameters have stable implementations
      in at least two different programming languages.

   *  Cryptography algorithms and parameters have a defined standard to
      store the algorithm and parameter identification alongside the
      result (e.g. like [RFC8152]).  This is required to ensure
      cryptography operation results can be processed even if the
      default parameters have been changed or the information has been
      processed with a previous version of the Secure Crypto Config.

   *  Cryptography algorithms that support parametrization to adapt to
      increased brute force performance and to allow longevity of the
      algorithm especially for hardware optimized implementations.

   The Secure Crypto Config SHOULD only propose cryptography algorithms
   and parameters that fulfill the following requirements:

   *  Cryptography algorithms and parameters are defined in a globally
      accepted standard which was suspect to a standardization process.

   *  Cryptography algorithms and parameters are licensed under a
      license that allows free distribution.

4.2.  Entities

   Entities that participate in the proposal phase SHOULD have
   significant cryptography expertise.  Entities that participate in the
   consensus finding phase MUST have significant cryptography expertise.
   Cryptographic expertise is defined by the Secure Crypto Config
   Working Group or the CFRG.

5.  Publication Format and Distribution

   In general the Secure Crypto Config is published via JSON-files in an
   official repository.  The Secure Crypto Config also utilizes IANA
   registries.









Mindermann & Teis         Expires 21 April 2021                [Page 17]


Internet-Draft                     SCC                      October 2020


5.1.  Versioning

   The Secure Crypto Config Format is regularly published in a specific
   year.  Therefore, the Secure Crypto Config format MUST use the
   following versioning format: *YYYY-PATCH*. YYYY is a positive integer
   describing the year (using the Gregorian calendar, and considering
   the year that has not ended in all time zones, cf. Anywhere on Earth
   Time) this specific Secure Crypto Config was published.  PATCH is a
   positive integer starting at 0 and only increasing for emergency
   releases.

5.2.  Naming

   Naming of official released SCCs must follow this format:

   "SCC_**Version**_LEVEL_**Security Level Number**"

   E.g. a Secure Crypto Config for Security Level 5 release in 2020 the
   first time (so no patch version) would be named:
   "SCC_2020-00_LEVEL_5"

   Naming of files is not regulated, only the content is standards
   relevant.  Yet, the Secure Crypto Config Files should use the
   mentioned naming convention as well adding a suffix (file type
   ending) ".json" to prevent ambiguity and remove implementation
   choices:

   "SCC_**Version**_LEVEL_**Security Level Number.json**"

5.3.  Secure Crypto Config IANA Registry

   *NOT NEEDED?, as the Secure Crypto Config uses other registries, e.g.
   COSE.  No final decision, yet.*

   *  [ ] TODO Naming convention.  Specification depending on crypto use
      case?

   *  [ ] TODO dash character "-" not possible in enum!

   The Secure Crypto Config requires one IANA Registry with the
   following columns:

   *  Secure Crypto Config release version: *YYYY-PATCH*

   *  Distinct *Algorithm-Parameter-Identifier* that uniquely identifies
      a cryptography algorithm and the parameters





Mindermann & Teis         Expires 21 April 2021                [Page 18]


Internet-Draft                     SCC                      October 2020


   *  Distinct and *constantly available reference* where all parameters
      are unambiguously defined

   *  (Optional) Short Description of the parameters

   Algorithm-Parameter-Identifier: MUST only consist of uppercase
   alphanumeric characters and underscores.  Depending on the use case
   the Algorithm Parameter Identifier can be constructed differently.
   We propose the following schemes:

   *  For symmetric encryption the name should look like
      *AlgorithmName_Mode_Padding_KeyLength_TagLength_NonceLength* (e.g.
      AES_GCM_NoPadding_256_128_128).

   *  For hashing as *HashAlgorithmName_KeyLength* (e.g.  SHA3_256).

   *  For asymmetric encryption and digital signatures
      *AlgorithmName_AuxiliaryAlgorithm_Padding_KeyLength* (e.g.
      RSA_ECB_OAEP_4096).

5.3.1.  Example for Secure Crypto Config IANA Registry

     +=========+=====================+===========+==================+
     | SCC     | AlgParam Identifier | Reference | Description      |
     | Version |                     |           |                  |
     +=========+=====================+===========+==================+
     | 2020-01 | AES_GCM_256_128_128 | [RFC8152] | AES 256 with GCM |
     |         |                     |           | and 128 bit tag  |
     |         |                     |           | and random nonce |
     +---------+---------------------+-----------+------------------+

                                 Table 1

5.3.2.  Utilized Algorithm Registries

   The Secure Crypto Config can only propose cryptography algorithms and
   parameters that have been standardized.  Therefore it refers to the
   following IANA registries:

   *  CBOR Object Signing and Encryption (COSE)
      (https://www.iana.org/assignments/cose/cose.xhtml)

   *  AEAD Algorithms (https://www.iana.org/assignments/aead-parameters/
      aead-parameters.xhtml)

   *  Named Information Hash Registry (https://www.iana.org/assignments/
      named-information/named-information.xhtml#hash-alg)




Mindermann & Teis         Expires 21 April 2021                [Page 19]


Internet-Draft                     SCC                      October 2020


   Used registries must define all required parameters for an algorithm
   to implement it without ambiguity.  E.g. implementations must not be
   able to choose other parameter values for a cryptography algorithm
   and parameter combination.

5.4.  Data Structures

   For each defined security level a distinct JSON-file must be
   provided.  These files must adhere to the common schema and shown in
   Figure 1 and described in the following.

   {
       "PolicyName": "SCC_SecurityLevel_Security Level Number",
       "Publisher": [
           {
               "name": "Publisher name",
               "URL": "URL corresponding to publisher"
           }
       ],
       "SecurityLevel" : "Security Level Number",
       "Version": "YYYY-Patch",
       "PolicyIssueDate": "YYYY-MM-DD",
       "Expiry": "YYYY-MM-DD",
       "Usage": {
           "SymmetricEncryption": [
               "Algorithm 1",
               "Algorithm 2"
           ],
           "AsymmetricEncryption": [
               "Algorithm 1",
               "Algorithm 2"
           ],
           "Hashing": [
               "Algorithm 1",
               "Algorithm 2"
           ],
           "PasswordHashing": [
               "Algorithm 1",
               "Algorithm 2"
           ],
           "Signing": [
               "Algorithm 1",
               "Algorithm 2"
           ]
       }
   }

                       Figure 1: General JSON format



Mindermann & Teis         Expires 21 April 2021                [Page 20]


Internet-Draft                     SCC                      October 2020


   *  SecurityLevel: Contains the number of the corresponding Security
      Level of the Secure Crypto Config

   *  PolicyName: Contains the name of the corresponding Secure Crypto
      Config according to the naming schema defined in Section 5.2

   *  Publisher: Contains an array of all parties that participated in
      the consensus finding process

      -  name: Name of the participating party

      -  URL: Put in the official URL of the named publisher

   *  Version: Contains version in the format defined in Section 5.1

   *  PolicyIssueDate: Date at which the Secure Crypto Config was
      published in the format: YYYY-MM-DD

   *  Expiry: Date at which the Secure Crypto Config expires in the
      format: YYYY-MM-DD

   *  Usage: Contains an array of objects for each cryptographic use
      case defined in Section 1.3.2.

      -  For each cryptographic use case, at least two agreed upon
         algorithms (see Section 4) with necessary parameters are
         included.  Each of these algorithms with its parameters is
         specified with its unique identification name defined in a IANA
         registry used by the Secure Crypto Config.

   This format allows custom algorithm/parameter definitions both by
   overwriting use cases completely or by adding only specific algorithm
   identifiers via custom configurations.

5.5.  Human readable format

   The Secure Crypto Config can not only be used in an automatic way,
   but also provide the cryptography algorithms and parameters for
   humans.  The human readable format must be derived from the JSON-
   files both to protect from copy-paste-errors and to validate the
   cryptographic signatures.  Yet, the human readable format or
   publication page itself must not be cryptographically protected.
   There should be one accessible resource, e.g. a webpage, where the
   source format (JSON-files) are automatically used for displaying them
   in appropriate ways (e.g. tables with various sorting and searching
   options).





Mindermann & Teis         Expires 21 April 2021                [Page 21]


Internet-Draft                     SCC                      October 2020


5.6.  Official Secure Crypto Config Repository

5.6.1.  Location of Secure Crypto Config Repository

   The needed Secure Crypto Config files should be published at an
   official Github repository.  There all current versions will be
   provided during the interval of the Publication phase (see
   Section 4.1.1).  Additionally all previously published files are
   still stored at this location even if new versions are published.

5.6.2.  Format of Secure Crypto Config Repository

   scc-repo
   - configs
     - 2020
       - 00
         - SCC_2020-00_LEVEL_1.json
         - SCC_2020-00_LEVEL_1.signature1
         - SCC_2020-00_LEVEL_1.signature2
         - SCC_2020-00_LEVEL_2.json
         - SCC_2020-00_LEVEL_2.signature1
         - SCC_2020-00_LEVEL_2.signature2
         - SCC_2020-00_LEVEL_3.json
         - SCC_2020-00_LEVEL_3.signature1
         - SCC_2020-00_LEVEL_3.signature2
         - SCC_2020-00_LEVEL_4.json
         - SCC_2020-00_LEVEL_4.signature1
         - SCC_2020-00_LEVEL_4.signature2
         - SCC_2020-00_LEVEL_5.json
         - SCC_2020-00_LEVEL_5.signature1
         - SCC_2020-00_LEVEL_5.signature2
       - 01
       - 02
     - 2021
     - 2022
     - 2023
     - 2024

       Figure 2: Example for Secure Crypto Config Repository content












Mindermann & Teis         Expires 21 April 2021                [Page 22]


Internet-Draft                     SCC                      October 2020


   scc-repo
   - configs
     - a
         - b
         - 0c1
         - ReallySecure
     - 0x1111
       - SCC_2020-00_LEVEL_1.json
       - SCC_2020-00_LEVEL_1.signature1
       - SCC_2020-00_LEVEL_1.signature2
       - SCC_2020-00_LEVEL_2.json
       - SCC_2020-00_LEVEL_2.signature1
       - SCC_2020-00_LEVEL_2.signature2
       - SCC_2020-00_LEVEL_3.json
       - SCC_2020-00_LEVEL_3.signature1
       - SCC_2020-00_LEVEL_3.signature2
       - SCC_2020-00_LEVEL_4.json
       - SCC_2020-00_LEVEL_4.signature1
       - SCC_2020-00_LEVEL_4.signature2
       - SCC_2020-00_LEVEL_5.json
       - SCC_2020-00_LEVEL_5.signature1
       - SCC_2020-00_LEVEL_5.signature2
     - asdf
     - afd
     - af

       Figure 3: Example for Secure Crypto Config Repository content
                         with custom naming scheme

   The Secure Crypto Config configuration files are expected to be in
   any folder hierarchy below the folder "configs"-folder.  Each JSON
   file should be accompanied by corresponding signature files that have
   the same filename without extension as the JSON file, suffixed by
   "-signatureX" where "X" is a counter starting at 1.

5.6.3.  Integrity/Signing process

   *  [ ] TODO what kind of signing process should be used?

      -  [ ] GPG?

      -  [ ] openssl?

      -  [ ] Git GPG signed commits?

      -  [ ] Use an SCC recommended signing algorithm/format





Mindermann & Teis         Expires 21 April 2021                [Page 23]


Internet-Draft                     SCC                      October 2020


   *  [ ] Can two signatures be put in one signature file?  Should they
      be put in the same file?

   *  [ ] Public Key distribution?! (In Github repo?)

   Each JSON-file should be accompanied by at least two signatures.
   Both signatures are stored in different files on the same level as
   their corresponding Secure Crypto Config file to reduce the parsing
   effort.  The signatures should be generated by entities defined by
   the Secure Crypto Config Working Group.  They are responsible to
   publish and renew the used public keys.  For signing of the
   corresponding Secure Crypto Config JSON files _openssl_ could be
   used.  The public keys needed for validation are published in the
   official repository of the Secure Crypto Config.

6.  Secure Crypto Config Interface

   This section describes the programming interface that provides the
   Secure Crypto Config.  The Secure Crypto Config Interface is generic
   and describes the API that should to be used by each programming
   language.

6.1.  Semantic Versioning

   The implementation of the Secure Crypto Config Interface MUST follow
   Semantic Versioning (https://semver.org/), which specifies a version
   format of *X.Y.Z* (Major.Minor.Patch) and semantics when to increase
   which version part.  It would be beneficial if the release of a new
   Interface version gets synchronized with the publication of a new
   Secure Crypto Config.  It should be possible to support the newly
   defined parameters of Secure Crypto Config in the interface as soon
   as possible.

6.2.  Deployment of (custom) Secure Crypto Config with Interface

   There are two different possibilities to work with the Secure Crypto
   Config: - The preferred option is to use the Secure Crypto Configs
   that will be delivered within the Interface.  In each new Interface
   version the current Secure Crypto Configs will be added such that
   always the newest Secure Crypto Configs at the time of the Interface
   release will be supported.  Previous Secure Crypto Configs will
   remain inside the Interface such that also older ones can still be
   used.  - Another option is to define a specific path to your own/
   derived versions of the Secure Crypto Configs with the same structure
   of the files as described in Section 5.4 but with other values than
   in the official ones.

   The Interface will process the Secure Crypto Configs as follows:



Mindermann & Teis         Expires 21 April 2021                [Page 24]


Internet-Draft                     SCC                      October 2020


   1.  Check if the path to the Secure Crypto Configs is a valid one.

   2.  Check if the "configs" folder exists.

   3.  For each folder following "configs" in the hierarchy look inside
       that folder and check the existence of JSON files that need to be
       considered.  This check will happen recursively for all folders
       inside the hierarchy.

   4.  For every JSON file found, look if there exists a signature.  If
       one is given, check if the signature is valid for the
       corresponding file.

   5.  Every files with a valid signature will be parsed and further
       processed.

   The parsing of each valid JSON file must be done as follows:

   1.  Readout all informations of all JSON files that need to be
       considered.  The information of each file is stored in a
       correspoding object.  With this procedure all JSON files need to
       be read only once which will contribute to the performance.

   2.  Parsing of security level: Check if it is a positive integer.
       All files not containing an (positive) integer number as security
       level value will be discarded.

   3.  Parsing of algorithm identifiers: Only the algorithm identifiers
       that are supported by the Interface will be considered and stored
       inside the corresponding object.  The supported algorithms are
       specified inside the interface (e.g. with an enmum).

   4.  Parsing of the version of all files: All files with values in the
       wrong format (see Section 5.1) will be excluded from further
       processing.  Find the latest (according to version) Secure Crypto
       Config file with the highest appearing security level (determined
       in previous step).  The path to this file will be used as default
       path used for each cryptographic use case if nothing else is
       specified by the user.  If two or more files with identical
       levels and version number are found, only the first one will be
       used, others are discarded.

   5.  The unique algorithm identifiers for the execution of a specific
       cryptographic use case will be fetched from the corresponding
       object (representing the JSON file determined beforehand) at the
       time the users invokes a method for a specific cryptographic use
       case.  The Interface will also provide a possibility to choose a
       specific algorithm (out of the supported ones) for executing the



Mindermann & Teis         Expires 21 April 2021                [Page 25]


Internet-Draft                     SCC                      October 2020


       desired use case.  In this case the specified algorithm is used.
       The identifiers will be compared with the supported ones in order
       of their occurrence inside the file.  If one matching identifier
       is found it will be used for execution.  If it is not a matching
       one the value will be skipped and the next one will be compared.
       If none of the algorithms inside the selected Secure Crypto
       Config can be found an error will occur.

6.2.1.  Delivery of Secure Crypto Config with Interface

   Each Secure Crypto Config Interface must be published in such a way
   that it uses (a copy of) the recent Secure Crypto Config repository.

   The Secure Crypto Config will be stored inside the subfolder "scc-
   configs" which should be located in the Interface's "src"-folder if
   existent.  The structure of the "scc-configs" folder will be the same
   as in the described hierarchy of the Github repository.  In any new
   version of the Interface the latest published Secure Crypto Config
   and its signatures must be used.

   If new Secure Crypto Configs will be published for which no published
   version of the Interface is available, the custom repository approach
   can be used as described in the following.

6.2.2.  Using a custom Secure Crypto Config Repository

   It is also possible to use a different path to the Secure Crypto
   Configs.  As also derived versions of the Secure Crypto Config for
   specific needs should be supported it will also be feasible to define
   a path to own or derived files which differentiate from the default
   "src/scc-configs/configs" folder.  For this case a method for setting
   and using a specific path must be provided by the Interface.

6.2.3.  Integrity Check

   *  [ ] TODO which public keys should be used?  (See above Integrity/
      Signing process Public Key distribution?!)

   The check for valid signature of the Secure Crypto Configs is always
   made before every actual usage of the Interface functionalities.  In
   this way it is possible to guarantee that the entity using the
   Interface only works with valid Secure Crypto Configs and circumvents
   the risk of forged file contents.  The public key needed for validity
   can be found in the official Github repository.  If own derived
   Secure Crypto Configs are created than it can be possible that no
   validation process is needed for these files.





Mindermann & Teis         Expires 21 April 2021                [Page 26]


Internet-Draft                     SCC                      October 2020


6.3.  Application Programming Interface (API)

6.3.1.  Methods and Parameters

   Intended methods and parameters included in the Java interface are
   described in Figure 5.

6.3.1.1.  Supported Algorithm Parameter Types

   *  [ ] TODO What is with parameters that have to be chosen during
      runtime? (e.g. the length of the nonce can be specified but not
      its content?)  Maybe refer to how the PHC String Format
      (https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-
      spec.md) describes how parameters must be defined and only allow
      constants and csprng generated content?

   Cryptography algorithms require different parameters.  The Secure
   Crypto Config Interface considers the following types of parameters:

   *  Parameter Size (e.g. key length in bit)

   *  Parameter Counter Content (e.g. nonce)

   *  Parameter Secure Random Content (e.g. nonce)

   *  Parameter User Automatic Tunable Content (e.g. memory consumption
      for Argon2 password hashing algorithm)

   *  Parameter User Defined Content (e.g. plaintext and key for
      symmetric encryption)

   *  Parameter Compound Parameter Content (e.g. counter + random =
      nonce)

6.3.2.  Automatic Parameter Tuning

   *  [ ] TODO is it possible to define new algorithm/parameter
      combinations on the fly (in extensions/derivations) or are only
      SCC IANA registry identifiers allowed/usable?

   It should be possible to have user specified parameters such as the
   key/nonce length explicitly given by the user, but also a performance
   mode which makes an evaluation for each configuration and give back a
   prioritized list for each configuration.  In this way it is possible
   to select parameters depending on systems properties.  Such a
   parameter choice would be beneficial e.g. in the case of Argon2
   (https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03) in which one
   parameter for the memory usage must be given.  This choice should be



Mindermann & Teis         Expires 21 April 2021                [Page 27]


Internet-Draft                     SCC                      October 2020


   chosen on the base of the corresponding system.  That kind of
   parameter selection can be seen e.g. in Libpasta Tuning
   (https://libpasta.github.io/advanced/tuning/), which returns a secure
   parameter set depending on executed evaluations.

6.3.3.  Output of readable Secure Crypto Config

   A Secure Crypto Config Interface must offer the following additional
   methods regarding the configuration - A method that returns a human
   readable version of the currently used Secure Crypto Config - A
   method that returns the currently used cryptography algorithm and
   parameters for a given use case - A method that validates the content
   of a Secure Crypto Config JSON file and one or more signatures

6.4.  TODOs

   *  The SCC could be provided on a suitable platform (?) and is
      accessible over the network (adversaries? e.g. http connection)

      -  [ ] e.g. should there be constants like "SCC_TOP_SECRET_LATEST"
         and "SCC_TOP_SECRET_LATEST".

      -  [ ] And like "SCC_TOP_SECRET_LATEST.AES" which points always to
         the latest Secure Crypto Config definition for AES parameters.

   *  [ ] TODO how should cryptography implementations, that implement/
      support SCC, generate the parameters?

   *  [x] What kind of parameters can be chosen based on the Secure
      Crypto Config? => E.g.  Should be all except the plaintext and the
      key for encryption algorithms.  Also many parameters can be
      generated based on cryptographically secure random numbers.

   *  [x] TODO The Secure Crypto Config Interface should include a
      performance evaluation mode which evaluates the performance of
      each configuration and returns a prioritized list for each
      configuration.  E.g. cf. Libpasta Tuning
      (https://libpasta.github.io/advanced/tuning/)

7.  Cryptography Library Implementation Specification

   Cryptography libraries should provide the above mentioned Secure
   Crypto Config Interface.  Until a common cryptography library
   provides the Secure Crypto Config Interface itself, there should be
   wrapper implementations that provide the Secure Crypto Config
   Interface and make use of the programming languages' standard
   cryptography library.




Mindermann & Teis         Expires 21 April 2021                [Page 28]


Internet-Draft                     SCC                      October 2020


8.  Cryptography Algorithm Standards Recommendation

   When new cryptography algorithm and/or parameter/mode/etc standards
   are created, they should contain a section mentioning the creating of
   the proposed secure parameter sets in the above mentioned IANA
   registries.  This ensures that new cryptography algorithms and
   parameter sets are available faster for the Secure Crypto Config
   Interface implementations to use.

9.  Security Considerations

   *  [x] TODO are some of the listed common issues relevant?:
      TypicalSECAreaIssues (https://trac.ietf.org/trac/sec/wiki/
      TypicalSECAreaIssues)

   *  [x] TODO check if security considerations of TLS 1.2 are relevant,
      especially appendix D, E and F (https://tools.ietf.org/html/
      rfc5246#appendix-D)

   *  [ ] TODO Are these appropriate security considerations?

9.1.  Consensus Finding

   *  Only trustworthy and cryptographic specialized entities should
      participate in the publication process of the Secure Crypto
      Config.  Otherwise a Secure Crypto Config with a weak and insecure
      parameter set could be provided.

9.2.  Publication Format

   *  The operators of the Secure Crypto Config must ensure that
      potential unauthorized parties are not able to manipulate the
      parameters of the published Secure Crypto Config.  Countermeasures
      to this are in place by utilizing git's gpg signatures and
      integrity as well as signatures for the published Secure Crypto
      Config files as well.

9.3.  Cryptography library implementation

   *  Integrity must be ensured if potential users want to fetch the
      provided Secure Crypto Config from the corresponding platform over
      the network e.g. by using a signatures.

   *  Users should only trust Secure Crypto Config issued from the
      original publisher with the associated signature.  Users are
      responsible to verify the provided signatures.





Mindermann & Teis         Expires 21 April 2021                [Page 29]


Internet-Draft                     SCC                      October 2020


9.4.  General Security Considerations

9.4.1.  Special Use Cases and (Non-)Security Experts

   The Secure Crypto Config does not apply to all use cases for
   cryptography and usage of cryptography primitives.  It is meant to
   provide secure defaults for the most common use cases and for non-
   expert programmers.  Additionally, non-experts may still implement
   vulnerable code by using the Secure Crypto Config.  Yet, it should
   reduce the vulnerabilities from making the wrong choices about
   parameters for cryptography primitives.

9.5.  Security of Cryptography primitives and implementations

   *  The Secure Crypto Config assumes that both the proposed algorithms
      and the implementations (cryptography libraries) for the
      cryptography primitives are secure as long as they are used with
      the correct parameters, states and orders of function calls.

9.5.1.  Security Guarantees

   The Secure Crypto Config makes a best effort to be as up-to-date with
   recent discoveries, research and developments in cryptography
   algorithms as possible.  Following this it strives to publish
   cryptography algorithms and corresponding parameter choices for
   common use cases.

   Yet, the Secure Crypto Config and the involved parties working on and
   publishing it doe not guarantee security for the proposed parameter
   configurations or any entity making use of it.  E.g. a new algorithm
   that can do brute-force attacks exponentially faster could be
   existing or published right after the publication of the most recent
   Secure Crypto Config was published itself.

9.5.2.  Threat Model / Adversaries

   There are different possibilities in which a potential adversary
   could intervene during the creation as well as after the publication
   of the Secure Crypto Config.  These attack scenarios must be
   considered and prevented.

   *  *Process:* During the creation process, it is necessary for
      selected institutions to agree on a secure parameter set.  It
      could be possible that one party wants to influence this process
      in a bad way.  As a result, it could be agreed on weaker parameter
      sets than originally intended.





Mindermann & Teis         Expires 21 April 2021                [Page 30]


Internet-Draft                     SCC                      October 2020


   *  *Publication:* After the publication of the Secure Crypto Config a
      potential attacker could gain access to the provided files on the
      corresponding platform and change the content to an insecure
      parameter set.

   *  *Content:* Depending on the distribution method of the Secure
      Crypto Config, it is also possible that an attacker could change
      the content of the Secure Crypto Config as man-in-the-middle.
      Especially if a http connection is used to obtain the Secure
      Crypto Config, this will be a serious problem.

10.  IANA Considerations

   *  [] TODO Are there IANA Considerations?

   *  [] TODO May add reference to own registry

   The data structure (see Section 5.4) defined in this document uses
   the JSON format as defined in [RFC8259].

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

11.2.  Informative References




Mindermann & Teis         Expires 21 April 2021                [Page 31]


Internet-Draft                     SCC                      October 2020


   [AESNI]    Gueron, S., "Intel Advanced Encryption Standard (AES)
              Instruction Set White Paper", 2010,
              <https://www.intel.com/content/dam/doc/white-paper/
              advanced-encryption-standard-new-instructions-set-
              paper.pdf>.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743,
              DOI 10.17487/RFC2743, January 2000,
              <https://www.rfc-editor.org/info/rfc2743>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

   [RFC5698]  Kunz, T., Okunick, S., and U. Pordesch, "Data Structure
              for the Security Suitability of Cryptographic Algorithms
              (DSSC)", RFC 5698, DOI 10.17487/RFC5698, November 2009,
              <https://www.rfc-editor.org/info/rfc5698>.

   [RFC6916]  Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
              Procedure for the Resource Public Key Infrastructure
              (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
              2013, <https://www.rfc-editor.org/info/rfc6916>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
              Agility and Selecting Mandatory-to-Implement Algorithms",
              BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
              <https://www.rfc-editor.org/info/rfc7696>.

Appendix A.  Examples

A.1.  JSON Secure Crypto Config









Mindermann & Teis         Expires 21 April 2021                [Page 32]


Internet-Draft                     SCC                      October 2020


   {
       "PolicyName" : "SCC_SecurityLevel_5",
       "Publisher" : [
           {
               "name" : "Crypto Forum Research Group",
               "URL" : "https://irtf.org/cfrg"
           },
           {
               "name" : "BSI",
               "URL" : "https://BSI"
           }
       ],
       "SecurityLevel" : "5",
       "Version" : "2020-0",
       "PolicyIssueDate" : "2020-04-20",
       "Expiry" : "2023-04-21",
       "Usage" : {
           "SymmetricEncryption" : [
               "AES_GCM_256_96",
               "AES_GCM_192_96"
           ],
           "AsymmetricEncryption" : [
               "RSA_SHA_512",
               "RSA_SHA_256"
           ],
           "Hashing" : [
               "SHA3_512",
               "SHA_512"
           ],
           "Signing" : [
               "ECDSA_512",
               "ECDSA_384"
           ],
           "PasswordHashing" : [
               "PBKDF_SHA_512",
               "SHA_512_64"
           ]
       }
   }

                     Figure 4: Example for JSON format

Appendix B.  Example Java Interface using Secure Crypto Config








Mindermann & Teis         Expires 21 April 2021                [Page 33]


Internet-Draft                     SCC                      October 2020


package org.securecryptoconfig;

import java.nio.charset.Charset;
import java.security.InvalidKeyException;
import org.securecryptoconfig.SCCKey.KeyType;
import org.securecryptoconfig.SCCKey.KeyUseCase;

import COSE.CoseException;

public abstract interface SecureCryptoConfigInterface {

        //Symmetric

        public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, byte[] plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext)
                        throws CoseException, InvalidKeyException, SCCException;


        public PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext sccciphertext)
                        throws CoseException, InvalidKeyException;

        // Asymmetric

        public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, byte[] plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext)
                        throws CoseException, InvalidKeyException, SCCException;


        public PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext)
                        throws CoseException, InvalidKeyException, SCCException;

        // Hashing

        public AbstractSCCHash hash(PlaintextContainerInterface plaintext) throws CoseException, SCCException;



Mindermann & Teis         Expires 21 April 2021                [Page 34]


Internet-Draft                     SCC                      October 2020


        public AbstractSCCHash hash(byte[] plaintext) throws CoseException, SCCException;


        public AbstractSCCHash updateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash)
                        throws CoseException, SCCException;


        public AbstractSCCHash updateHash(byte[] plaintext, AbstractSCCHash hash) throws CoseException, SCCException;


        public boolean validateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash)
                        throws CoseException, SCCException;


        public boolean validateHash(byte[] plaintext, AbstractSCCHash hash) throws CoseException, SCCException;

        // Digital Signature

        public AbstractSCCSignature sign(AbstractSCCKey key, PlaintextContainerInterface plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public AbstractSCCSignature sign(AbstractSCCKey key, byte[] plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public AbstractSCCSignature updateSignature(AbstractSCCKey key, PlaintextContainerInterface plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public AbstractSCCSignature updateSignature(AbstractSCCKey key, byte[] plaintext)
                        throws CoseException, InvalidKeyException, SCCException;


        public boolean validateSignature(AbstractSCCKey key, AbstractSCCSignature signature)
                        throws InvalidKeyException, SCCException;


        public boolean validateSignature(AbstractSCCKey key, byte[] signature) throws InvalidKeyException, SCCException;

        // Password Hashing


        public AbstractSCCPasswordHash passwordHash(PlaintextContainerInterface password)
                        throws CoseException, SCCException;


        public AbstractSCCPasswordHash passwordHash(byte[] password) throws CoseException, SCCException;



Mindermann & Teis         Expires 21 April 2021                [Page 35]


Internet-Draft                     SCC                      October 2020


        public boolean validatePasswordHash(PlaintextContainerInterface password, AbstractSCCPasswordHash passwordhash)
                        throws CoseException, SCCException;


        public boolean validatePasswordHash(byte[] password, AbstractSCCPasswordHash passwordhash)
                        throws CoseException, SCCException;
}


  abstract interface PlaintextContainerInterface {


        public abstract byte[] toBytes();


        public abstract String toString(Charset c);


        @Override
        public abstract String toString();


        public abstract boolean validateHash(AbstractSCCHash hash) throws SCCException;


        public abstract boolean validatePasswordHash(AbstractSCCPasswordHash passwordHash) throws SCCException;


        public abstract AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key) throws SCCException;


        public abstract AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key) throws SCCException;


        public abstract AbstractSCCSignature sign(AbstractSCCKey key) throws SCCException;


        public abstract AbstractSCCHash hash() throws SCCException;


        public abstract AbstractSCCPasswordHash passwordHash() throws SCCException;

}


 abstract class AbstractSCCCiphertext {

        byte[] msg;



Mindermann & Teis         Expires 21 April 2021                [Page 36]


Internet-Draft                     SCC                      October 2020


        protected AbstractSCCCiphertext(byte[] msg) {
                this.msg = msg;
        }


        public abstract byte[] toBytes();


        @Override
        public abstract String toString();


        public abstract PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key) throws SCCException;


        public abstract PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key) throws SCCException;


        public abstract AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key) throws SCCException;


        public abstract AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key) throws SCCException;

}


 abstract class AbstractSCCKey {

        KeyType type;
        byte[] privateKey, publicKey;
        String algorithm;

        protected AbstractSCCKey(KeyType type, byte[] publicKey, byte[] privateKey, String algorithm) {
                this.type = type;
                this.publicKey = publicKey;
                this.privateKey = privateKey;
                this.algorithm = algorithm;

        }


        public abstract byte[] toBytes() throws InvalidKeyException;


        public abstract byte[] getPublicKeyBytes() throws InvalidKeyException;


        public abstract byte[] getPrivateKeyBytes() throws InvalidKeyException;



Mindermann & Teis         Expires 21 April 2021                [Page 37]


Internet-Draft                     SCC                      October 2020


        public abstract KeyType getKeyType();


        public abstract String getAlgorithm();

}


abstract class AbstractSCCHash {

        byte[] hashMsg;


        protected AbstractSCCHash(byte[] hashMsg) {
                this.hashMsg = hashMsg;
        }


        public abstract byte[] toBytes();


        @Override
        public abstract String toString();


        public abstract boolean validateHash(PlaintextContainerInterface plaintext) throws SCCException;


        public abstract boolean validateHash(byte[] plaintext) throws SCCException;


        public abstract AbstractSCCHash updateHash(PlaintextContainerInterface plaintext) throws SCCException;


        public abstract AbstractSCCHash updateHash(byte[] plaintext) throws SCCException;

}


abstract class AbstractSCCPasswordHash {

        byte[] hashMsg;


        protected AbstractSCCPasswordHash(byte[] hashMsg) {
                this.hashMsg = hashMsg;
        }




Mindermann & Teis         Expires 21 April 2021                [Page 38]


Internet-Draft                     SCC                      October 2020


        public abstract byte[] toBytes();


        @Override
        public abstract String toString();


        public abstract boolean validatePasswordHash(PlaintextContainerInterface password) throws SCCException;


        public abstract boolean validatePasswordHash(byte[] password) throws SCCException;

}


abstract class AbstractSCCSignature {
        byte[] signatureMsg;

        protected AbstractSCCSignature(byte[] signatureMasg) {
                this.signatureMsg = signatureMasg;
        }


        public abstract byte[] toBytes();


        @Override
        public abstract String toString();


        public abstract boolean validateSignature(AbstractSCCKey key) throws SCCException;


        public abstract AbstractSCCSignature updateSignature(PlaintextContainerInterface plaintext, AbstractSCCKey key)
                        throws SCCException;

}

                 Figure 5: Example for a JAVA SCC API

Acknowledgments

   *  [ ] TODO acknowledge.

Authors' Addresses






Mindermann & Teis         Expires 21 April 2021                [Page 39]


Internet-Draft                     SCC                      October 2020


   Kai Mindermann
   iC Consult GmbH

   Email: kai.mindermann@ic-consult.com


   Lisa Teis

   Email: lisateis102@gmail.com










































Mindermann & Teis         Expires 21 April 2021                [Page 40]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/