Summary

  • RFC 9690 says an ordinary rsaEncryption certificate does not signal that its owner will accept RSA-KEM; willingness may be announced separately and only for a bounded set of components.
  • A defensible sender must bind the certificate, capability provenance and age, two KDF positions, KEK length, wrap algorithm and CMS content type before treating a message as deliverable.

The easiest mistake begins with a certificate that looks entirely healthy. Its path validates. Its RSA modulus has the expected size. Its SubjectPublicKeyInfo uses the familiar rsaEncryption identifier. A mail or archival system then concludes that RSA-KEM is available because the public key can perform the necessary mathematics.

RFC 9690 closes that shortcut in one sentence: use of rsaEncryption does not indicate that the recipient will accept RSA-KEM with the key. A public key identifies cryptographic material. It does not publish the current policy, software path, enabled content type or component combination of the party expected to decapsulate.

That distinction is the operational centre of the specification. RSA-KEM is not one switch. It combines an RSA encapsulation, a KDF inside RSA-KEM, a second KDF at the CMS KEMRecipientInfo layer, a KEK length, a wrapping algorithm and a CMS content type. RFC 9690 defines a mandatory floor—KDF3 with SHA-256 and AES-Wrap-128—but also permits other components. The phrase “supports RSA-KEM” therefore discards the fields that decide whether two endpoints can actually meet.

Three ways a certificate can speak

RFC 9690 gives the recipient several ways to represent intent, and their meanings are not interchangeable.

First, a certificate may use rsaEncryption. That preserves broad RSA compatibility, but it is silent about RSA-KEM acceptance. The same key shape can sit behind a signer, an old key-transport implementation or a system whose KEM path is disabled.

Second, willingness may appear in an SMIMECapabilities attribute carried in CMS signed data under RFC 8551, or in the certificate extension defined by RFC 4262. That is positive evidence, but RFC 8551 describes a partial list. A signed message from last quarter records what one implementation announced then. It is not a live health check and does not by itself bind the announcement to today's endpoint configuration or organizational permission.

Third, a certificate intended only for RSA-KEM uses id-rsa-kem-spki. If its parameters are absent, KDF3 with SHA-256 is the default for deriving the RSA-KEM shared secret. If parameters are present, they must use GenericHybridParameters and constrain the KDF, KEK length and wrap algorithm permitted in the message. If keyUsage is present, it contains only keyEncipherment. This is stronger intent evidence, but still not an execution receipt.

The sender should preserve which of these three states it saw. Converting all of them into a database boolean called rsaKem=true destroys the very distinction RFC 9690 supplies.

One name hides two KDF decisions

The processing chain contains two derivations. RSA-KEM encrypts a fresh random integer z with the recipient's RSA public key and derives a shared secret from z. CMS then feeds that shared secret, a requested length and otherInfo into the KEMRecipientInfo KDF to derive the key-encryption key. RFC 9690 explicitly says the two KDFs may differ.

That means a capability receipt must not store one field named “KDF”. It needs at least the inner RSA-KEM KDF and hash, the CMS-layer KDF, the KEK length and the wrap algorithm. When GenericHybridParameters are present in a capability announcement or certificate, they constrain the values that the originator must place into KEMRecipientInfo. The wrap value in the data-encapsulation component must appear in the wrap field; the KDF and key length must match their designated fields.

This is where syntactic interoperability and operational authority part company. A parser can recognize id-kem-rsa, accept a well-formed kemct and read encryptedKey. None of those facts proves that the tuple was advertised by the intended recipient, remains enabled, conforms to local policy or reaches the private key that corresponds to the certificate.

Migration preserved compatibility, not one meaning

RFC 5990 placed RSA-KEM into KeyTransRecipientInfo and concatenated ciphertext and wrapped key as EK = C || WK. RFC 9690 uses the generic KEM structure from RFC 9629, putting the ciphertext in kemct and the wrapped key in encryptedKey. Backward-compatible processing remains possible, and the ASN.1 module can produce the same bits-on-wire for the old definitions.

Those facts do not create one processing contract. A system must retain whether it selected RFC 5990 key transport or RFC 9690 KEMRecipientInfo, which certificate identifier and parameters governed the key, and which capability evidence authorized that selection. “Same RSA operations” is not “same container, same negotiation or same failure surface.”

The split fields are valuable because failure can be located more precisely. An originator can show the recipient identifier, RSA ciphertext, CMS KDF tuple and wrapped content key. A recipient can separately report ciphertext length/range checks, private-key operation, shared-secret derivation, KEK derivation and unwrap result. One generic “decrypt failed” event is easier to collect but much less useful for deciding whether the error was stale capability, wrong key, unsupported tuple or damaged content.

A capability receipt that can expire

A practical sender can keep the claim narrow:

  1. identify the exact certificate and validated path used for recipient selection;
  2. preserve the SubjectPublicKeyInfo identifier, parameter presence and exact bytes;
  3. record keyUsage and distinguish broad rsaEncryption from restricted id-rsa-kem-spki;
  4. retain the capability statement, signer, source message or extension, time and certificate binding;
  5. expand support into the inner KDF/hash, CMS KDF, KEK length, wrap algorithm and content type;
  6. choose RFC 5990 or RFC 9690 processing explicitly rather than by parser accident;
  7. record construction of kemct and encryptedKey without calling that recipient success;
  8. seek a recipient-side result for decapsulation, unwrap and content processing where the workflow can provide one;
  9. refresh the capability after certificate rotation, software change, policy change or a bounded age.

The receipt does not need to promise delivery. It needs to say exactly why the sender believed this combination was eligible, and when that belief expires.

What the cryptography cannot authorize

RSA-KEM has a strong reason for existing. RFC 9690 presents it as a replacement for the PKCS #1 v1.5 key-transport portion in new CMS applications, with a tighter security argument and separation between public-key and symmetric operations. RFC 8017 supplies the RSA representation, RFC 3394 supplies the mandatory AES wrapping floor, and RFC 4086 frames the need for strong randomness.

None of that converts a certificate into consent. A fresh z, valid RSA ciphertext and correctly derived keys establish bounded mathematical events. They do not prove that the recipient still operates the key, accepts this sender, authorizes this content, successfully processes the plaintext or treats the result as a business decision. RFC 5280 can help validate certificate statements; it cannot observe a recipient application's current state.

Lu Heng's minimum-specification lens is useful here. A mandatory component floor makes interoperation possible without turning every optional combination into universal policy. His reality-layer lens keeps the certificate, capability statement, message structure, private computation and application decision in their proper places. Running-code primacy requires the last word to come from actual recipient processing, not from an identifier that merely made processing imaginable.

Sources