Add a new section: explicitely list SPKI AlgIds

[ounsworth]

We should add a section listing explicitly the DER-encoded AlgorithmIdentifiers for the components of each composite public key and signature algorithm. This is important to resolve ambiguity on, for example, whether the RSA should have a NULL param, and the ECC curve params.

Example, for id-MLDSA44-ECDSA-P256-SHA256 the ML-DSA SPKI would have an AlgorithmIdentifier of:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        id-ml-dsa
    }

which is:

AlgorithmIdentifier  ::=  SEQUENCE  {
        {
     1.3.6.1.4.1.2.267.12.4.4
      }
  }

And the ECDSA-P256-SHA256 would have a SPKI would have an AlgorithmIdentifier of:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        id-ecPublicKey,
       secp256r1  
  }

which is:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 },
       iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7}

And the signature algorithm for id-MLDSA44-ECDSA-P256-SHA256, the first component signature algorithm would have an AlgorithmIdentifier of

   AlgorithmIdentifier  ::=  SEQUENCE  {
        id-ml-dsa
    }

which is:

AlgorithmIdentifier  ::=  SEQUENCE  {
        {
     1.3.6.1.4.1.2.267.12.4.4
      }
  }

and the second component signature algorithm would have an AlgorithmIdentifier of

   AlgorithmIdentifier  ::=  SEQUENCE  {
          ecdsa-with-SHA256
  }

which is:

AlgorithmIdentifier  ::=  SEQUENCE  {
           {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2
       }
  }

With that done, we should replace the message prefix values in Sectien 2.4 with the SHA256 hash of the signature AlgorithmIdentifiers. This has two nice properties that are better than using the ASCII encoding of the OID name: 1) they are all the same length (ie the length of SHA256), and 2) if the inner OIDs change, for example with a new Kyber version, then the message prefix changes, which prevents cryptographic compatibility issues; or otherwise stated: provides signature domain-separation based on the component OIDs.

--- SHA256 of the DER encoding of the following ASN.1 value
--- Security Consideration note: the choice of SHA256 here is not security-relevant since it is only to generate fixed string values.

SEQUENCE {
AlgorithmIdentifier  ::=  SEQUENCE  {
        {
     1.3.6.1.4.1.2.267.12.4.4
      }
  },
AlgorithmIdentifier  ::=  SEQUENCE  {
           {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2
       }
  }
}

Furthermore, once we have this,

[johngray-dev]

We agreeded we need to be more specific so there is no ambiguity. For example P256 needs to define exactly what curve is used..

[johngray-dev]

We agreed to fix this after IETF 119.

[johngray-dev]

Update after the draft is published on lamps-wg github.