CryptFilterPublicKeyMap doesn't allow StdCF entry if DefaultCryptFilter/DefEmbeddedFile are present

[bdoubrov]

I think this special case reflects the following text in 7.6.4.1 (2nd par above NOTE 2):

For revision 6, the filter CFM value shall be AESV3 (AES-256). Public-Key security handlers in this case shall use a crypt filter named DefaultCryptFilter when all document content is encrypted, and shall use a crypt filter named DefEmbeddedFile when file attachments only are encrypted in place of StdCF name.

As I understand this, it is a processing requirement rather than the file format requirement.

[petervwyatt]

I agree that the wording uses "handler" which makes it sound like a processor requirement, but in reality, these are key values. I suspect this is a hangover from the Adobe spec days. See examples in the iText test suite: https://github.com/itext/itext7/tree/develop/kernel/src/test/resources/com/itextpdf/kernel/crypto/PdfEncryptionTest. It also makes no sense no mandate a PDF name object for a processor requirement unless you are describing a specific implementation...

Maybe this should be re-worded in 32K? BTW I did have this exact conversation with @MatthiasValvekens

[bdoubrov]

So, the document that defines both DefaultCryptFilter and StdCF would be invalid? Not clear at all from the current wording of 32K indeed.