Adding support for KEM to Section 5.2.8

[HBrock]

ToDo in Section 5.2.8: Adding support for KEM keys and fixing some inconsistencies in Section 5.2.8.3 resulting from the update of RFC2510 to RFC4210

[HBrock]

Meeting 2.3.23: Do this after IETF116

[DDvO]

Looks like this is still ToDo.

[HBrock]

Yes, we need to look into it ... :-)

[HBrock]

Please review updates updated Section 5.2.8 (see fa57a14f292affa3a60be051cc7c1eb318320aff)

[HBrock]

@johngray-dev will review this Also with focus on encryptedRand

[HBrock]

From Section 5.2.8.3 of RFC4210 says "Alternatively, the POP can use the POPOSigningKey structure given in [CRMF] (where the alg field is DHBasedMAC and the signature field is the MAC) as a fourth alternative for demonstrating POP if the CA already has a D-H certificate that is known to the EE."

I shifted and rephrased this to Section 5.2.8 of rfc4210bis "In the special case that the CA/RA has a D-H certificate that is known to the EE and the certification request is for a key agreement key pair, the EE can also use the POPOSigningKey structure (where the algorithmIdentifier field is DHBasedMAC and the signature field is the MAC) for demonstrating POP."

@johngray-dev Do you know, why the MAC is not placed in POPOPrivKey agreeMAC? Should we change this?

[johngray-dev]

We discussed this on February 22nd and 26th. The text around using CMPv3 when this field is used will mitigate any backwards compatibility issues. Mike had comments about the size of the integer as well as possibly using it to decode an arbitrary CMS message. The previous challenge was an OCTET_STRING. It is now an Enveloped data format which would contain many other fields as a structure which would be unlikely to be able to be decoded arbitrarily.