[noodlesUK]

One thing I think is really lacking from the PDF ecosystem is good open-source tools around signing. PDF signatures are something that is legally important in a lot of the world with regulations like eIDAS. Unfortunately it's extremely difficult to cryptographically sign PDF documents with tools other than Adobe's and some other (often more sketchy) proprietary tools. Even if you figure out how to use stuff like LibreOffice or poppler to sign, you'll struggle to obtain certs that will validate without spending an arm and a leg.

I really hope that someone will decide to step in and become the Let's Encrypt of PDF and S/MIME certs, because that will improve public trust significantly.

[JumpCrisscross]

> you'll struggle to obtain certs that will validate

You’ll be surprised how far you can go pasting a picture of your signature in Preview.

[noodlesUK]

Absolutely, and that's what I tend to do with my documents IRL, but I think it would be really nice if we could move to a world where signing documents digitally actually meant something more than `signature.png`.

In the EU, in order to have a legal guarantee of being treated as the same as a handwritten signature in all member states, you have to meet "Qualified Electronic Signature" level, which means cryptographic signatures and the involvement of some kind of trust services provider who validates the certificate used to sign. In practice this is rare, and ordinary electronic signatures a la Preview work for most things.

[yencabulator]

> involvement of some kind of trust services provider

Marketplace at least in the US has shown that once you have this, the actual cryptography really doesn't matter. All anyone seems to care about seems to be "We are company X and have been doing this business for Y years and here's our standard operating policy. We emailed address A at time T1 and the person reading that email address used our online services to electronically 'sign' the pdf P at time T2."

Everyone trusts Adobe/Dropbox/et al to make that claim, nobody cares about certificates and what not.

[SCM-Enthusiast]

There does exist a marketplace for documentation to be cryptographically encoded. E.G. Spec sheets. You must have a verified PGP key to open this document, that is generated for a company after they sign a NDA.

[wfn]

Completely agree. Source: I build things for a company[1][2] which is a TRA and a QTSP (eIDAS parlance).

Two references which I promise will be interesting (re: qcerts and QES tooling):

- excellent open source library for working with PDFs and digital signatures (incl. PDF ones): https://github.com/MatthiasValvekens/pyHanko

- European Commission's DSS Tool (you can submit one PDF only, don't need both original and signed one): https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo...

[1]: https://www.zealid.com/en/ - you can onboard remotely for free, download your qualified certs at https://my.zealid.com/en - upload, QES sign, download PDFs (all of these free) - or use our APIs to integrate into us (get in touch with us if you'd like the latter).

[2]: opinions are my own.

[noodlesUK]

I know this comment comes a bit late, but thanks so much! That library is exactly the kind of thing I have been looking for. I've just signed up using your app. I'm curious, my UK passport didn't scan correctly with NFC. Do you only support EU docs for NFC validation? I expected the NFC scanning to work with any ICAO 9303 document.

[wfn]

> That library is exactly the kind of thing I have been looking for.

Ah, that's great to hear! You can message its author if you have any specific questions regarding it, he's a friendly and very competent fella.

> I'm curious, my UK passport didn't scan correctly with NFC. Do you only support EU docs for NFC validation? I expected the NFC scanning to work with any ICAO 9303 document.

Ah, one day I'll write a post / video / book / series of morbid novels on NFC in eMRTDs...

Long story short: we support NFC worldwide (NFC prompt is disabled for certain documents, e.g. Germany has a peculiar interpretation of ICAO 9303 where they require a type of Active Auth (vs Passive Auth which is what happens when you scan it with our app or with many other apps))).

However.

1. Sometimes the chip simply does not scan correctly. It takes a bit of time, there's a handshake involved, we send in a sort of hash of the MRZ so that the chip can give some (not all) of the NFC Data Groups (if you're familiar with the 9303 - e.g. we don't get (as part of Passive Auth) biometrics info such as your iris info). You have to hold it tight for a while. You have to hold it against the right spot on your mobile device (varies per model as you're likely aware). Chip has to be in good shape (confirmed from personal experience).

2. Countries interpret PKI (incl. the underlying x509 spec)... differently. One good recent example: the DSC (Document Signing Certificate embedded in your chip) has to have the same trust root as the corresponding CRL (cert revocation list where we check if the cert which signed the DSC - the so-called CSCA - has not been revoked). In practice... sometimes they differ. We handle exceptions and keep working on them, but it's a slow process.

So TL;DR sometimes it's just the physical process which gets in the way (and you then get the video pattern upload screen); sometimes we fetch the NFC data but cannot ensure its authenticity (cannot verify chain of signed certs up to a trusted root - UK like other countries has issued a few CSCAs; these are included in ICAO's PKD which we download, verify and then use). And sometimes all of this is well, but we conclude that the revocation status of the parent cert (the CSCA) is unknown.

If revocation information is included in the cert (e.g. through a so-called distribution point - which usually points to a URL (sometimes broken...), sometimes to a file (...), etc.), we have to make revocation checks and conclude that the cert inside the chip (DSC) and the parent cert(s) have not been revoked. Sometimes the latter process fails.

Sometimes the same document model (same country, doc type, same issue year, same physical security features etc.) embeds a different DSC which leads us to discover that some country has again introduced some non-conforming (against x509 spec, to be precise; e.g. in terms of validation path building) cert chain. We learn to handle them, but it's an ongoing process. Some docs for some countries still prove troublesome.

I don't know the particular onboarding attempt at hand, so it could be something from #1 or #2 above, or perhaps something else.

What can I say, it's fun... (I especially love how ICAO 9303 requires explicit unnamed elliptic curves (as the key algorithm for the keypair underneath the NFC's DSC).

If you want to chat more, shoot me an email :)

[TheJoeMan]

You’re really right, I asked my IT guy who’s a windows server wizard about what it would take to implement basic PKI for internal document signing and he looked at me like I had 2 heads.

[FredrikSE]

The PKI is not hard(Windows one works well), but to keep it secure and safe could be more challenging.

[perfmode]

does Preview in macOS not fit the bill?

[noodlesUK]

As far as I know preview doesn’t support creating or even viewing cryptographic signatures at all.