Daniel Gillmor said:

i think massimiliano is saying that the logic for acceptance of a generic composite is just "do i support each of the included OIDs independently" is that right?

Right. So here's Generic (stylized ASN.1):

algorithm: AlgorithmIdentifier{id-composite-key}

subjectPublicKey: CompositePublicKey {
  SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: ecPublicKey
      parameters: prime256v1
      }
    subjectPublicKey: <ec key octet string>
    },
    SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: rsaEncryption
      parameters: NULL
      }
    subjectPublicKey: <rsa key octet string>
    }
  }

And the equiv explicit:

algorithm: AlgorithmIdentifier{id-pk-example-ECandRSA}

subjectPublicKey: CompositePublicKey {
  SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: ecPublicKey
      parameters: prime256v1
      }
    subjectPublicKey: <ec key octet string>
    },
    SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: rsaEncryption
      parameters: NULL
      }
    subjectPublicKey: <rsa key octet string>
    }
  }

The literal only difference is outer OID.

In both cases you have to iterate through the inner SPKIs and decide if you support them. In the Explicit case you have to also check some mapping table to make sure those line up with that you expected from the explicit outer OID.

Meeting Chat Log		Limited Additional Mechanisms for PKIX and SMIME (lamps) WG
Title		Chat Log IETF115: lamps: Wed 09:30
Session		Materials
Last updated		2022-11-09

Chat Log IETF115: lamps: Wed 09:30 chatlog-115-lamps-202211090930-00

Chat Log IETF115: lamps: Wed 09:30
chatlog-115-lamps-202211090930-00