Only define a single OID for composite algorithms

[danvangeest]

I think the id-CompositeSignature and id-CompositePrivateKey OIDs aren't necessary.

Signature OIDs only need to be defined when combined with a pre-hash algorithm (e.g. ecdsa-with-sha384), but a composite signature isn't combined with a pre-hash algorithm but rather each component signature may use a different (or no) pre-hash algorithm (e.g. ecdsa-with-sha384 + HSS). EdDSA and HSS don't define different OIDs for the signature algorithm for the same reason that they don't have a pre-hash applied before the signature.

I'm not aware of any algorithms where a separate OID is defined for a private key version of the algorithm, it just uses the same public key OID (in fact I just added a definition of CompositePrivateKey used in pk-CompositePublicKey defined above which I think covers defining a composite private key using a single composite public key OID).

If we look at two of the more recent RFCs or drafts to define new algorithms for use in PKIX-related standards we have: https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-08

   --
   -- Object Identifiers
   --
   id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       smime(16) alg(3) 17 }

   --
   -- Signature Algorithm and Public Key
   --

   sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-hss-lms-hashsig
       PARAMS ARE absent
       PUBLIC-KEYS { pk-HSS-LMS-HashSig }
       SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig } }

   pk-HSS-LMS-HashSig PUBLIC-KEY ::= {
       IDENTIFIER id-alg-hss-lms-hashsig
       KEY HSS-LMS-HashSig-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
           { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }

and

https://tools.ietf.org/html/rfc8410

   id-X25519        OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 }
   id-Ed25519       OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 }

    sa-Ed25519 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-Ed25519
        PARAMS ARE absent
        PUBLIC-KEYS {pk-Ed25519}
        SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
    }

    pk-Ed25519 PUBLIC-KEY ::= {
        IDENTIFIER id-Ed25519
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                        keyCertSign, cRLSign}
        PRIVATE-KEY CurvePrivateKey
    }

So for the OIDs I'd pick id-CompositePublicKey (or id-alg-compositePublicKey if you want to be more like HSS).

And I think our draft's definition of composite Signature Algorithm and Public Key corresponding to RFC 5911 would be:

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

CompositeSignatureAlgorithmParams ::= SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier

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

   pk-CompositePublicKey PUBLIC-KEY ::= {
       IDENTIFIER id-CompositePublicKey
       KEY CompositePublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
           { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY CompositePrivateKey
   }

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

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

Originally posted by @danvangeest in https://github.com/EntrustDatacard/draft-ounsworth-composite-sigs/issues/45#issuecomment-497198319

[csosto-pk]

I think that is a good idea. It works the same way in https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake when the old rsaEncryption OID is not uses for the RSA public key. Instead id-RSASSA-PSS-SHAKE128 / id-RSASSA-PSS-SHAKE256 can be used in both the public key and Sig Algorithm Identifiers.

[ounsworth]

Note that in splitting the draft into two drafts (one for composite keys, and one for composite signatures), I have reversed this and defined separate OIDs for composite keys and for composite signatures.

See:

• draft-ounsworth-pq-composite-keys: f56baecd5373b0d