- "electronic signatures", which can be any electronic data used to sign, like a drawn signature
- "advanced electronic signature" (AdES), usually a type of digital signature (XML-DSig, PDF signature, etc.)
- "qualified electronic signature (QES), which is a digital signature created by a certified signature device
QES is legally equivalent to a "wet signature", but in my experience rarely used because of cost. AdES is much more common for high-trust scenarios like loan applications. For low-trust like package delivery, a signature (or smiley) drawn on a touch device will usually do.
AdES is mostly an technical standard that specifies how to use existing PKCS and IETF standards to produce eIDAS conforming signature, timestamp or “seal” (ie. timestamped signature) and how that should be mapped onto CMS (CAdES), XML-Signature (XAdES) and PDF (PAdES). How legally binding the result of that process is then depends on things like QSCTs, their LoA used in that and such things. And then there are various carveouts, for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that)
> for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that)
AFAIK that is not true. In CZ national law, there is also recognized electronic signature (RES, "uznávaný elektronický podpis"), which may be either QES (per eIDAS, "kvalifikovaný elektronický podpis"), or just AdES based on certificate from qualified CAs (per national law, "zaručený elektronický podpis, založený na kvalifikovaném certifikátu").
If you use QSCD to generate CSR and get it signed by right CA, you get QES, but if you use just 'openssl req' to generate CSR and get it signed by right CA, you get RES that is not QES.
The point is that the CA has no way to determine that the CSR was generated by Qualified Device and will just sign it. My view of all the talk about Qualified Devices in eIDAS exists mostly to force QCAs to use normal enrollment process with CSRs instead of their random home-grown processes that result in PKCS#12 file containing private key generated who knows where and who knows how.
> In practice, though, PAdES has a lot more support and has the crucial property of being easy to view by end-users.
For now, I'd expect ever increasing compliance with eIDAS in the future. PDFz are also not the only thing that people want to sign, that's where an agnostic container format has its benefits.
> Is there any wide use of ASiC?
I know that at least Estonia, Latvia, Lithuania and Finland have deployed it. Of those Estonia probably has the widest and longest use of it, as they migrated *to* ASiC-E, having used the predecessors BDOC and CDOC previously.
The article does not mention passkeys, but they seem destined to be almost all of WebAuthn usage in the future, now that both Apple and Google support them. External FIDO keys will probably remain a niche solution for those with special security needs. But where does that leave the platform authenticator approach? It’s great that you can store the key on-device, but is it really worth it ti not use passkeys instead?
Passkeys will probably be stored in the ways this article advocates for, except there will be some way to securely sync them between devices without allowing them to be copied to unauthorised devices even if the OS is compromised.
I can't speak with authority, but my reading of PKI issues suggests Google is just as strict, while Microsoft and Apple are less strict. However, that just might be because MS and Apple are less public with their root programs.
Not being able to automatically renew certificates seems like a rather minor point in the bigger picture.
I get QWAC goes against the trend of phasing out EV certs. But isn’t the real issue that the browsers don’t trust TSP audits carried out for EU member states?
It’s actually a huge issue - look at how eliminating a key difficulty in obtaining certificates massively increased HTTPS adoption (via LetsEncrypt and others)
Similarly, automation affects how easy or hard it is to replace a CA, for example, if moving to distrust a CA. If you rely on QWAC attributes, you can only use QWAC CAs, and changing CAs becomes significantly more complex.
The audit issue is definitely an issue: the audits used are fundamentally different than what browsers try to achieve, and so having to adopt the lower standard definitely impacts user security. However, my point was that in addition to those concerns, the technical design itself results in less robust and less agile systems, and that makes things less secure.
Identity verification services usually combine document reading with something like a video selfie, which provides 1) a liveness check (you are a real person) and 2) a match against the digital image data that was read.
Is it possible to fool? Like anything it is a trade-off. Acceptable security for an acceptable cost. Hopefully it fulfills your security requirements and you saved a physical visit.
Since the Javascript NemID client was introduced last year, most users don't need Java anymore.
That's for OTP though, users with tokens or keyfile have to use the OpenSign applet still. Haven't seen any stats, but OpenSign usage is probably pretty small compared to standard NemID/OTP.
- "electronic signatures", which can be any electronic data used to sign, like a drawn signature - "advanced electronic signature" (AdES), usually a type of digital signature (XML-DSig, PDF signature, etc.) - "qualified electronic signature (QES), which is a digital signature created by a certified signature device
QES is legally equivalent to a "wet signature", but in my experience rarely used because of cost. AdES is much more common for high-trust scenarios like loan applications. For low-trust like package delivery, a signature (or smiley) drawn on a touch device will usually do.