Shall EnvelopedDate be offered for encrypting Rand in POPODecKeyChallContent?

[HBrock]

The challenge field in popdecc messages is supposed to contain Rand in encrypted form. See RFC 9480 Appendix A and RFC 4210 Section 5.2.8.3.

POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages)

Challenge ::= SEQUENCE {
    owf                 AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}
                            OPTIONAL,
    -- MUST be present in the first Challenge; MAY be omitted in
    -- any subsequent Challenge in POPODecKeyChallContent (if
    -- omitted, then the owf used in the immediately preceding
    -- Challenge is to be used)
    witness             OCTET STRING,
    -- the result of applying the One-Way Function (owf) to a
    -- randomly generated INTEGER, A (Note that a different
    -- INTEGER MUST be used for each Challenge.)
    challenge           OCTET STRING
    -- the encryption (under the public key for which the cert.
    -- request is being made) of Rand
}

-- Rand was added in CMP Updates [RFC9480]

Rand ::= SEQUENCE {
-- Rand is encrypted under the public key to form the challenge
-- in POPODecKeyChallContent
   int                  INTEGER,
   -- the randomly generated INTEGER A (above)
   sender               GeneralName
   -- the sender's name (as included in PKIHeader)
}

POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).  The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.

Currently it is poorly specified which encryption key and encryption algorithm is used. To support also KEM-keys and to improve the clarity of the specification, Challenge could be extended to also be capable using EnvelopedData for transferring the encrypted Rand.

POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per certification request (in the same order
-- as these requests appear in CertReqMessages)

Challenge ::= SEQUENCE {
    owf                 AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}
                            OPTIONAL,
    -- MUST be present in the first Challenge; MAY be omitted in
    -- any subsequent Challenge in POPODecKeyChallContent (if
    -- omitted, then the owf used in the immediately preceding
    -- Challenge is to be used)
    witness             OCTET STRING,
    -- the result of applying the One-Way Function (owf) to a
    -- randomly generated INTEGER, A (Note that a different
    -- INTEGER MUST be used for each Challenge.)
    challenge           OCTET STRING
    -- MUST be used for CMP V1 and V2 popdecc messages
    -- MUST be an empty OCTET STRING for CMP V3 popdecc
    -- messages
    -- The encryption (under the public key for which the certification
    -- request is being made) of Rand
     encRand             EnvelopedData    OPTIONAL
    -- MUST be omitted for CMP V 1 and V2 popdecc messages
    -- MUST be used for CMP V3 messages and contain the encrypted
    -- value of Rand
    -- Using Challenge omitting the optional encRand is bit-compatible
    -- to the syntax without this change.
}

-- Rand was added in CMP Updates [RFC9480]

Rand ::= SEQUENCE {
-- Rand is encrypted under the public key to form the challenge
-- in POPODecKeyChallContent
   int                  INTEGER,
   -- the randomly generated INTEGER A (above)
   sender               GeneralName
   -- the sender's name (as included in PKIHeader)
}

POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per certification request (in the same order
-- as these requests appear in CertReqMessages).  The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.

But I am uncertain if it is worth doing this, because I am not aware of any implementation using popdecc messages.

[HBrock]

Updated Section 5.2.8 with fa57a14f292affa3a60be051cc7c1eb318320aff