Is there a reason why CF value in EncryptionPublicKey has two possible types: [CryptFilterMap,CryptFilterPublicKeyMap]?

[bdoubrov]

As EncryptionPublicKey corresponds to the Encryption dictionary in case of public-key security, I would expect that CF entry has only CryptFilterPublicKeyMap type. Why CryptFilterMap is also specified here as an alternative value type?

[petervwyatt]

CryptFilterMap is covering the cases where StmF, StrF and EFF have to have all their values in the CF dictionary. The spec also does not prohibit additional crypt filters in CF even if they are not actively referenced - but if there are such entries then they need to valid crypt filter dictionaries. Furthermore, nowhere in the spec is this constrained to being a constant/the same like many implementations decide to implement.

I know the * row is duplicated across both CryptFilterPublicKeyMap and CryptFilterMap so resolving this is somewhat ambiguous - is this an issue?

[bdoubrov]

The only difference between CryptFilterPublicKeyMap and CryptFilterMap is the the first has CryptFilterPublicKey as the values of its keys, and the second allows only CryptFilter value type. And the main difference between CryptFilterPublicKey and CryptFilter is that the first requires Recipients entry, while the second doesn't even allow this entry.

So, maybe it was meant to allow CryptFilterPublicKeyMap referencing both CryptFilterPublicKey and CryptFilter? This would mean that in case of Public key security the CF dictionary may define both public key handlers (with Recipients) and the standard ones (no Recipients).

However, the current model requires the value of CF entry in the Encryption dictionary to be either CryptFilterPublicKeyMap (implying no standard security filters are allowed here) or CryptFilterMap, meaning no public key security filters are allowed. This doesn't seem to be right.