Signatures, encryption and attachments / Encryption and conformance
Password protection and PDF/A conformance
Why a password-protected file can never be PDF/A or PDF/UA, and what the password option here actually gives you.
Where this API stands
This API does part of what the standard asks for, and the paragraph below is the whole of it rather than a summary of it. The `password` option applies 40-bit RC4 encryption as specified in the Adobe PDF Reference 1.4, using the standard security handler at /V 1 and /R 2. It is applied after rendering as an incremental update that carries the original trailer's /Root forward. What it is for is stopping a document being opened casually by someone it was not sent to, and it should not be presented as more than that: 40-bit RC4 is broken and a determined attacker will open the file. It also cannot be combined with the `pdf_a` option to any useful end, because the resulting file claims PDF/A-1b in its metadata and is encrypted, which is a combination no validator will pass.
What the standard requires
The requirements as a checker enforces them, rather than as a procurement document paraphrases them. A file satisfies all of these or it satisfies none of them.
- Every part of PDF/A forbids encryption outright: PDF/A-1 through PDF/A-4 all require that the file is not encrypted, with no exception for a weak cipher or an empty user password.
- PDF/UA has the same practical effect, because assistive technology has to be able to read the content and the standard requires that access is not obstructed.
- PDF 2.0 removes the 40-bit and 128-bit RC4 handlers entirely and specifies AES-256 as the standard security handler.
- Encryption applied as an incremental update invalidates any signature already on the file, because the signed byte range no longer matches.
- An owner password without a user password restricts operations rather than opening, and every PDF library on the internet ignores those restrictions, so it is a statement of intent rather than a control.
Who asks for this
Two groups who want opposite things, which is why this page exists. Security reviews ask for encryption on documents containing personal data. Archiving and accessibility requirements forbid it. When both land on the same document set, somebody has to decide, and the decision is usually to encrypt at rest in the storage layer rather than inside the file.
What it looks like in a file
The concrete form of the thing being described, so you can recognise it in a document you have been handed rather than only in a specification.
# What did I actually apply?
qpdf --show-encryption invoice.pdf
# If the requirement is a modern cipher, do it downstream instead of
# using the password option, which is 40-bit RC4 per PDF Reference 1.4.
qpdf --encrypt --user-password=secret --owner-password=admin \
--bits=256 -- invoice.pdf invoice-aes.pdfWhat to do about it
Decide which requirement actually governs. If the document has to be archived or accessible, do not encrypt the file: encrypt the storage, control access at the API, and use this API's short-lived document retrieval rather than emailing the file around. If the document genuinely needs to travel encrypted and the recipient's security policy specifies a modern cipher, apply AES-256 downstream with qpdf or a PDF library instead of using the password option here.
How to check a file rather than assume
`qpdf --show-encryption file.pdf` names the handler, the key length and the permissions, which settles the question of what you actually applied. veraPDF will fail an encrypted file against any PDF/A profile immediately and say so, which is the fastest confirmation that the two requirements really are incompatible.
The mistake people make here
Setting a password and telling a stakeholder the document is encrypted, without saying which encryption. 40-bit RC4 and AES-256 are the same word in a status report and nothing alike in a security review. Say the cipher, and if the answer to "is this good enough" is no, move the encryption downstream rather than arguing about it.
Frequently asked
Does this API produce Encryption and conformance?
Partly, and the page says how far. The `password` option applies 40-bit RC4 encryption as specified in the Adobe PDF Reference 1.4, using the standard security handler at /V 1 and /R 2. It is applied after rendering as an incremental update that carries the original trailer's /Root forward. What it is for is stopping a document being opened casually by someone it was not sent to, and it should not be presented as more than that: 40-bit RC4 is broken and a determined attacker will open the file. It also cannot be combined with the `pdf_a` option to any useful end, because the resulting file claims PDF/A-1b in its metadata and is encrypted, which is a combination no validator will pass.
Can I turn on the pdf_a option and be done?
No. The option writes an XMP packet declaring PDF/A-1b into the document catalogue, and the render response comes back carrying a warning that says in as many words that this is best-effort and that full conformance requires tagged structure and an embedded ICC profile. It is a claim written into the file, not a certificate earned by it, and a validator checks the claim against the bytes. Read the warning array in the response rather than taking the absence of an error as a pass.
Should I convert before rendering or after?
After, always. A conformance converter rewrites colour, embeds profiles, sets boxes and stamps metadata on a finished PDF. Trying to satisfy a conformance target from the source side means guessing at what the converter would have done, and the guesses that go wrong are expensive: flattening transparency you did not need to flatten changes what the page looks like.
Standards this one is confused with
The neighbours that matter are the ones people mistake for this, not the ones that sort next to it.
What PDF/A-1b requires, and how far this API gets you
The oldest and strictest archiving profile: a PDF 1.4 file with everything it needs to render sealed inside it, and nothing in it that a future reader might not understand.
PDF version numbers and what sets them
The version in the file header and optionally in the catalogue, which says which features a reader must understand to open the file correctly.
Adding a digital signature field to a PDF
A form field holding a cryptographic signature over the file, which proves who signed it and that nothing has changed since.
Certification signatures and DocMDP permissions
The first signature on a document, which certifies the whole thing and declares what, if anything, anyone is allowed to change afterwards.
PAdES signature levels B-B, B-T, B-LT and B-LTA
The four European profiles for PDF signatures, each adding what the one below it needs to still be verifiable years later.
Every standard, with what this API does about it
The full list, grouped by what the requirement is for, each marked with how far this API gets.
What this API actually does
One page per option and endpoint that exists, with nothing that does not.
Conformance is decided after a file exists. Render the document, then check it, then convert only what the checker actually flags.