pdf-association
Permissible public-key encryption schemes
Clause 7.6.5.3 mandates the following:
A key shall be used to encrypt (and decrypt) the enveloped data. This key (the plaintext key in "Figure 4 — Public-key encryption algorithm") shall be encrypted for each recipient, using that recipient’s public key, and shall be stored in the CMS object (as the encrypted key for each recipient). To decrypt the document, that key shall be decrypted using the recipient’s private key, which yields a decrypted (plaintext) key.
The next paragraph includes provisions on the (symmetric) ciphers that can be used to encrypt the envelope contents (i.e. 20-byte seed + permissions):
The algorithms that shall be used to encrypt the enveloped data in the CMS object are:
- RC4 with key lengths up to 256-bits (deprecated);
- DES, Triple DES, RC2 with key lengths up to 128 bits (deprecated);
- 128-bit AES in Cipher Block Chaining (CBC) mode (deprecated);
- 192-bit AES in CBC mode (deprecated);
- 256-bit AES in CBC mode.
However, there is nothing in the clause restricting which public-key encryption schemes and key lengths are permissible to encrypt the plaintext key.
Even if we take "public-key encryption" to mean "RSA", there's still the issue of padding schemes. Obviously, classic RSA with PCKS#1 v1.5 padding probably works with virtually every implementation, but what about RSA-OAEP? The latter is a more modern parametrised scheme (RSA-OAEP is to encryption what RSA-PSS is to signing, essentially), and is not as widely supported.
I wouldn't necessarily oppose leaving this up to the implementation, but it feels a bit strange to me to constrain the enveloped data encryption to a well-defined list of ciphers, while at the same time not restricting the ways in which the envelope key can be encrypted for each recipient.
RSA-OAEP is not supported which is why it isn't listed.
Adding it would require an extension, such as the new 32001 and 32002.
That's fair enough. But shouldn't the clause then include a line stating that "the envelope key shall be encrypted using RSA with PKCS#1 v1.5 padding for each recipient" or something along those lines? Right now, there's no language in the clause that points towards any specific public-key cryptosystem, at least not as far as I can see.
Given RSA's dominant position in the market, it's a sensible default (I'm not arguing with that). That said, it's not the only asymmetric cryptosystem out there (e.g. GnuPG uses ElGamal for message key encryption). I believe adding a line stating that RSA is the only supported algorithm would be appropriate.
Just to kick things off, here's an initial proposal.
In the second paragraph of clause 7.6.5.3, change
A key shall be used to encrypt (and decrypt) the enveloped data. This key (the plaintext key in "Figure 4 — Public-key encryption algorithm") shall be encrypted for each recipient, using that recipient’s public key, and shall be stored in the CMS object (as the encrypted key for each recipient).
to
A key shall be used to encrypt (and decrypt) the enveloped data. This key (the plaintext key in "Figure 4 — Public-key encryption algorithm") shall be encrypted for each recipient using RSA with PKCS#1 v1.5 padding. The key encryption key shall be that recipient’s public key, and the resulting encrypted data encryption key shall be stored in the CMS object (as the encrypted key for each recipient).
The wording might still require some tweaking, but I believe this accurately reflects the reality of what actual implementations expect. Some remaining potential issues that we might want to look at:
- Do we want to align the set of permissible RSA key sizes with those in Table 260 (for digital signatures)?
- Do we need to provide/cite a definition for PKCS#1 v1.5 padding? If yes, does that imply that we need to cite PKCS#1 as a normative reference? Currently, there's an entry in the bibliography for the RSA Labs version of PKCS#1 v2.2; the IETF RFC corresponding to that would be RFC 8017 (see in particular § 7.2).
@lrosenthol anything else I missed? Thanks!
Note: I believe that we need to modernise this clause in a future version of PDF, but that's obviously out of scope for this errata project.
Adding "proposed solution" label so PDF TWG reviews @MatthiasValvekens proposals above.
As I'm currently dealing with these encryption details, too, I'd like to ask what "parked" means, in particular when the issue may become un-parked.
That being asked, I would formulate the change differently. As it is now, this would make any approach to use a non-RSA certificate for encryption invalid as it requires the key to be encrypted for each recipient using RSA with PKCS#1 v1.5 padding.
Furthermore, profiling ISO 32000 to specific algorithms wouldn't be possible anymore either.
I think a formulation along the lines of a conformant PDF processor must support RSA with PKCS#1 v1.5 padding for key encryption but may also support other algorithms would be more open to extensions.
As an aside...
Obviously, classic RSA with PCKS#1 v1.5 padding probably works with virtually every implementation, but what about RSA-OAEP?
If you are basing encryption on Bouncy Castle FIPS, the only key wrapping algorithm in approved mode is RSA encryption with OAEP; thus, the BC FIPS high level classes support only RSA with OAEP...
I think a formulation along the lines of a conformant PDF processor must support RSA with PKCS#1 v1.5 padding for key encryption but may also support other algorithms would be more open to extensions.
I agree with this direction. Initially I worried that that would complicate interop, but on reflection, in the cases where one uses public-key encryption, the intended recipient is known, so there's a lot more potential leeway when it comes to algorithm choices.
If you are basing encryption on Bouncy Castle FIPS, the only key wrapping algorithm in approved mode is RSA encryption with OAEP; thus, the BC FIPS high level classes support only RSA with OAEP...
Ah, that's very good to know. Thanks!
As mentioned previously, RSA-OAEP isn't defined for PDF today and so any text in 32K would need to specifically call out PKCS#1 v1.5 as suggested above.
I do agree that given the industry movement to RSA-OAEP we should kick off an extension...however, since the algo isn't currently defined in a key anywhere - it will require slightly more work.
since the algo isn't currently defined in a key anywhere - it will require slightly more work.
I don't think this is necessarily an issue. The public-key security handler uses ASN.1 messages with algorithm identifiers, and of course there's a standard OID for RSAES-OAEP :). In that sense, the payloads are self-describing.
It's a little reductive, but maybe the extension could even be as simple as just amending the table with permissible algorithms (and perhaps bumping the security handler version).