Composite Signatures For Use In Internet PKI

1.1. Terminology

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

The following terms are used in this document:¶

ALGORITHM: An information object class for identifying the type of cryptographic operation to be performed. This document is primarily concerned with algorithms for producing digital signatures.¶

BER: Basic Encoding Rules (BER) as defined in [X.690].¶

COMPONENT ALGORITHM: A single basic algorithm which is contained within a composite algorithm.¶

COMPOSITE ALGORITHM: An algorithm which is a sequence of two or more component algorithms, as defined in Section 2.¶

DER: Distinguished Encoding Rules as defined in [X.690].¶

LEGACY: For the purposes of this document, a legacy key or signature is a non-composite key or signature.¶

PUBLIC / PRIVATE KEY: The public and private portion of an asymmetric cryptographic key, making no assumptions about which algorithm.¶

SIGNATURE: A digital cryptographic signature, making no assumptions about which algorithm.¶

2.1. Algorithm Identifier

The following object identifier is used for identifying a composite signature. Additional encoding information is provided below for each of these objects.¶

id-alg-composite OBJECT IDENTIFIER ::= {
    iso(1)  identified-organization(3) dod(6) internet(1) private(4)
    enterprise(1) OpenCA(18227) Algorithms(2) id-alg-composite(1) }

EDNOTE 3: this is a temporary OID for the purposes of prototyping. We are requesting IANA to assign a permanent OID, see Section 5.¶

2.2. Composite Keys

A Composite signature MUST be associated with a Composite public key as defined in ~~ reference draft-ounsworth-pq-composite-pubkey ~~.¶

digitalSignature;
nonRepudiation;
keyCertSign; and
cRLSign.

digitalSignature; and
nonRepudiation;

2.3. Composite Signature

The ASN.1 algorithm object for a composite signature is:¶

sa-CompositeSignature SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-alg-composite
    VALUE CompositeSignatureValue
    PARAMS TYPE CompositeParams ARE required
    PUBLIC-KEYS { pk-Composite }
    SMIME-CAPS { IDENTIFIED BY id-alg-composite } }
}

The following algorithm parameters MUST be included:¶

CompositeParams ::= SEQUENCE SIZE (2..MAX) OF AlgorithmIdentifier

The signature's CompositeParams sequence MUST contain the same component algorithms listed in the same order as in the associated CompositePrivateKey and CompositePublicKey.¶

The output of the composite signature algorithm is the DER encoding of the following structure:¶

CompositeSignatureValue ::= SEQUENCE SIZE (2..MAX) OF BIT STRING

Where each BIT STRING within the SEQUENCE is a signature value produced by one of the component keys. It MUST contain one signature value produced by each component algorithm, and in the same order as in the associated CompositeParams object.¶

The choice of SEQUENCE OF BIT STRING, rather than for example a single BIT STRING containing the concatenated signature values, is to gracefully handle variable-length signature values by taking advantage of ASN.1's built-in length fields.¶

2.4. Encoding Rules

Many protocol specifications will require that composite signature data structures be represented by an octet string or bit string.¶

When an octet string is required, the DER encoding of the composite data structure SHALL be used directly.¶

When a bit string is required, the octets of the DER encoded composite data structure SHALL be used as the bits of the bit string, with the most significant bit of the first octet becoming the first bit, and so on, ending with the least significant bit of the last octet becoming the last bit of the bit string.¶

In the interests of simplicity and avoiding compatibility issues, implementations that parse these structures MAY accept both BER and DER.¶

3.1. Composite Signature Generation Process

Generation of a composite signature involves applying each component algorithm's signature process to the input message according to its specification, and then placing each component signature value into the CompositeSignatureValue structure defined in Section 2.3.¶

The following process is used to generate composite signature values.¶

Input:
     K1, K2, .., Kn     Private keys for the n component signature
                        algorithms, a CompositePrivateKey
     M                  Message to be signed, an octet string

Output:
     S                  The signatures, a CompositeSignatureValue

Signature Generation Process:
   1. Generate the n component signatures independently,
      according to their algorithm specifications.

        for i := 1 to n
            Si := Sign( Ki, M )

   2. Encode each component signature S1, S2, .., Sn into a BIT STRING
      according to its algorithm specification.

        S ::= Sequence { S1, S2, .., Sn }

   3. Output S

Since recursive composite public keys are disallowed in ~~ Reference draft-ounsworth-pq-composite-pubkeys sec-composite-pub-keys ~~, no component signature may itself be a composite; ie the signature generation process MUST fail if one of the private keys K1, K2, .., Kn is a composite with the OID id-alg-composite.¶

A composite signature MUST produce and include in the output a signature value for every component key in the corresponding CompositePrivateKey. For this mode, please see Composite-OR in section Section 3.2.¶

3.2. Composite-OR Signature Generation Process

EDNOTE: This section was written with the intention of keeping the primary Composite OID reserved for the simple and strict mode; if you want to do either a simple OR, or a custom policy then we have given a different OID. We are still debating whether this is useful to specify at issuing time, or whether this is adding needless complexity to the draft.¶

If the algorithm ID of the public key associated with this signature is id-composite-or-key then the signer MAY use only a subset of the component keys and therefore produce fewer signatures than the number of component keys.¶

Composite-OR signature generation uses the same structures and algorithms as Composite, with the difference that the signature generation process may emit a null instead of a signature value in step 1 for one or more component algorithms. A Composite-OR signature MUST NOT be entirely null; it must contain at least one valid signature.¶

The design intent of this mode is to support migration scenarios where an end entity has been issued keys on algorithms that either itself or the peer with which it is communicating do not (yet) support. This design allows for both the mode where the signer omits signatures that it knows its peer cannot process in order to save bandwidth and performance, and the mode where it includes all component signatures and allows the verifier to choose how many to verify. The latter is RECOMMENDED for signatures that need both sort-term backwards compatibility as well as long-term security.¶

EDNOTE: Do we want to allow a Composite-OR with only a single signature to produce non-composite signatureAlgorithm and signatureValua as per [RFC5280]? Advantages: bandwidth savings of an extra OID and some sequences with one element. Disadvantages: ambiguous whether a signature is traditional or composite until you look at the corresponding public key.¶

3.3. Composite Signature Verification Process

Verification of a composite signature involves applying each component algorithm's verification process according to its specification.¶

In the absence of an application profile specifying otherwise, compliant applications MUST output "Valid signature" (true) if and only if all component signatures were successfully validated, and "Invalid signature" (false) otherwise.¶

The following process is used to perform this verification.¶

Input:
     P    Signer's composite public key
     M    Message whose signature is to be verified, an octet string
     S    Composite Signature to be verified
     A    Composite Algorithm identifier

Output:
    Validity      "Valid signature" (true) if the composite signature
                  is valid, "Invalid signature" (false) otherwise.

Signature Verification Procedure::
   1. Parse P, S, A into the component public keys, signatures,
      and algorithm identifiers

      P1, P2, .., Pn := Desequence( P )
      S1, S2, .., Sn := Desequence( S )
      A1, A2, .., An := Desequence( A )

    If Error during Desequencing, or the three sequences have
    different numbers of elements, or any of the public keys P1, P2, .., Pn or
    algorithm identifiers A1, A2, .., An are composite with the OID
    id-alg-composite then output "Invalid signature" and stop.

   2. Check each component signature individually, according to its
       algorithm specification.
       If any fail, then the entire signature validation fails.

     for i := 1 to n
          if not verify( Pi, M, Si ), then
            output "Invalid signature"

      if all succeeded, then
        output "Valid signature"

Since recursive composite public keys are disallowed in ~~ Reference draft-ounsworth-pq-composite-keys sec-composite-pub-keys ~~, no component signature may be composite; ie the signature verification procedure MUST fail if any of the public keys P1, P2, .., Pn or algorithm identifiers A1, A2, .., An are composite with the OID id-alg-composite.¶

3.4. Composite-OR Signature Verification

EDNOTE: This section was written with the intention of keeping the primary Composite OID reserved for the simple and strict mode; if you want to do either a simple OR, or a custom policy then we have given a different OID. We are still debating whether this is useful to specify at issuing time, or whether this is adding needless complexity to the draft.¶

When the public key associated with the signature being verified has algorithm id-composite-or-key, then an alternate verification processes MAY be used, at the discretion of the implementor. In this section we provide some examples of alternate verification processes.¶

If the signature is a traditional (non-composite) algorithm and value or a composite signature with a single component, then it MAY be considered valid if it verifies under one of the component keys.¶

If the signature is composite, then the implementor MAY implement policy for which combinations are acceptable.¶

EDNOTE: Does this mean Composite-OR end entity certificates need to be issued by a PKI that is marked as Composite-OR all the way to the top so that verifiers that do not support all the algorithms don't fail? Need to think more about the security implications of allowing a Composite-or in an end entity cert implicitely turning all Composite algIDs into Composite-or algIDs in its cert chain.¶

EDNOTE: Do we need to specify the semantics of verifying an "n of m" subset signature? I suspect that specifying this in general will be a rat's nest of edge cases, so I propose to "leave this to the implementor".¶

CompositeParams {legacyAlgorithmIdentifier, null, .., null}

CompositeSignatureValue  {legacySignatureValue, null, .., null}

4.1. Cryptographic protocols

This section talks about how protocols like (D)TLS and IKEv2 are affected by this specifications. It will not attempt to solve all these problems, but it will explain the rationale, how things will work and what open problems need to be solved. Obvious issues that need to be discussed.¶

• How does the protocol declare support for composite signatures? TLS has hooks for declaring support for specific signature algorithms, however it would need to be extended, because the client would need to declare support for both the composite infrastructure, as well as for the various component signature algorithms.¶
• How does the protocol use the multiple keys. The obvious way would be to have the server sign using its composite public key; is this sufficient.¶
• Overhead; including certificate size, signature processing time, and size of the signature.¶
• How to deal with crypto protocols that use public key encryption algorithms; this document only lists how to work with signature algorithms. Encoding composite public keys is straightforward; encoding composite ciphertexts is less so - we decided to put that off to another draft.¶

6.1. Policy for Deprecated and Acceptable Algorithms

Traditionally, a public key, certificate, or signature contains a single cryptographic algorithm. If and when an algorithm becomes deprecated (for example, RSA-512, or SHA1), it is obvious that structures using that algorithm are implicitly revoked.¶

In the composite model this is less obvious since a single public key, certificate, or signature may contain a mixture of deprecated and non-deprecated algorithms. Moreover, implementers may decide that certain cryptographic algorithms have complementary security properties and are acceptable in combination even though neither algorithm is acceptable by itself.¶

Specifying a modified verification algorithm to handle these situations is beyond the scope of this draft, but could be desirable as the subject of an application profile document, or to be up to the discretion of implementers.¶

2. Check policy to see whether A1, A2, ..., An constitutes a valid
   combination of algorithms.

   if not checkPolicy(A1, A2, ..., An), then
     output "Invalid signature"

While intentionally not specified in this document, implementors should put careful thought into implementing a meaningfull policy mechinism within the context of their signature verification engines, for example only algorithms that provide similar security levels should be combined together.¶

7.1. ASN.1 Module

<CODE STARTS>

Composite-Signatures-2019
  { TBD }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

EXPORTS ALL;

IMPORTS
  PUBLIC-KEY, SIGNATURE-ALGORITHM
    FROM AlgorithmInformation-2009  -- RFC 5912 [X509ASN1]
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-algorithmInformation-02(58) }

  SubjectPublicKeyInfo
    FROM PKIX1Explicit-2009
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkix1-explicit-02(51) }

  OneAsymmetricKey
    FROM AsymmetricKeyPackageModuleV1
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) modules(0)
        id-mod-asymmetricKeyPkgV1(50) } ;

--
-- Object Identifiers
--

id-alg-composite OBJECT IDENTIFIER ::= { TBD }

--
-- Public Key
--

pk-Composite PUBLIC-KEY ::= {
    IDENTIFIER id-alg-composite
    KEY CompositePublicKey
    PARAMS ARE absent
    PRIVATE-KEY CompositePrivateKey
}

CompositePublicKey ::= SEQUENCE SIZE (2..MAX) OF SubjectPublicKeyInfo

CompositePrivateKey ::= SEQUENCE SIZE (2..MAX) OF OneAsymmetricKey

--
-- Signature Algorithm
--

sa-CompositeSignature SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-alg-composite
    VALUE CompositeSignatureValue
    PARAMS TYPE CompositeParams ARE required
    PUBLIC-KEYS { pk-Composite }
    SMIME-CAPS { IDENTIFIED BY id-alg-composite } }

CompositeParams ::= SEQUENCE SIZE (2..MAX) OF AlgorithmIdentifier

CompositeSignatureValue ::= SEQUENCE SIZE (2..MAX) OF BIT STRING

END

<CODE ENDS>

7.2. Intellectual Property Considerations

The following IPR Disclosure relates to this draft:¶

https://datatracker.ietf.org/ipr/3588/¶

8.1. Making contributions

Additional contributions to this draft are weclome. Please see the working copy of this draft at, as well as open issues at:¶

https://github.com/EntrustCorporation/draft-ounsworth-composite-sigs¶