
GnuPG can now be used to perform notarial acts in the State of Washington - Boulth
https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060987.html
======
jwr
Incidentally, I've been working with digital signatures which are legally
equivalent to traditional ones in my country (Poland) and comparing them to a
GnuPG setup with private keys stored on a YubiKey.

It seems to me that my YubiKey setup (done following
[https://github.com/drduh/YubiKey-Guide](https://github.com/drduh/YubiKey-
Guide)) is substantially better in almost every respect than the state-
provided smartcard.

I intend to publish a signed PDF document (signed with the state-certified RSA
key) that says that my GnuPG keys are really mine.

~~~
Boulth
> It seems to me that my YubiKey setup (done following
> [https://github.com/drduh/YubiKey-Guide](https://github.com/drduh/YubiKey-
> Guide)) is substantially better in almost every respect than the state-
> provided smartcard.

Would you care to explain the differences in detail?

As far as I know the EU qualified certs are also required to be stored on
smartcards so the only difference vs Yubikey would be Yubikey's portable
format (it is a smartcard reader and a smartcard in one device).

~~~
jwr
Perhaps not in detail, but in general outline:

* I was able to generate my GnuPG keys myself and I know (to the extent that I trust my computing environment) that I am the only one to have access to the secret key(s),

* the state-approved qualified cert is only a single RSA key, for signatures,

* you don't get to make a backup of that key,

* as a result, it can't really be used for anything else than signing documents, so forget about encrypting data or using it for authentication for example (cases where you really do need to have backups),

* the key is stored on a physically inconvenient device (smartcard) and you need to have one and only one of those,

Plus, of course you get the whole beauty of crappy PKI infrastructure (why
does every company dealing with certs have to be shady, have a crappy website
and in general be a mess?). But that is beside the point, I guess.

~~~
dcbadacd
Just for comparison the Estonian system:

* As far as I know upon cert renewal the new cert is generated on your computer, uploaded to the card and then deleted - you could theoretically intercept that but I don't see why you would - the key is more secure on the card

* The state-approved cert _s_ one is for e-identification (when PIN is entered also authentication), other for signing (AFAIK not RSA but EC)

* See point one

* Encrypting data can be done but as the software warns, it's to protect the data during transit _not_ when idle and nothing is stopping me from using the card daily to log into my bank and other services I need to use

* The key is stored on the smart card but you can get multiple (AFAIK at least for e-identification).

Don't know much about the Estonian PKI infrastructure though and it seems
stable enough for daily use without any noticeable hiccups.

~~~
pisipisipisi
The key is generated inside the card, but the key generation is initiated via
your computer (but in fact, initiated by the card management system). So no,
you can not intercept any keys in that process.

~~~
jwr
What I did not like about the process in Poland was that the key generation
was done using a computer that wasn't mine. How do I know if the key was
really generated on the card, rather than on the PC (and then a copy uploaded
to the card)?

I have to trust the companies that provide the issuing services, which I do
not like.

~~~
Boulth
I don't know about your particular device but Yubikeys have remote attestation
feature so that you (or anyone else) can validate that a given key was
generated on the card, not imported (assuming you trust Yubico). This works
only in PIV applet. Source: [https://developers.yubico.com/yubico-piv-
tool/Attestation.ht...](https://developers.yubico.com/yubico-piv-
tool/Attestation.html)

------
badrabbit
PGP is an alright protocol but I cannot recommend gpg for daily use by non-
technical users. They make it extremely difficult to use long-term and simple
issues like gpg-agent running as a background process become controversies
where they could have just made it optional.

Honestly,I think it's an alright piece of software but the project became the
way it is as a result of the massive gnupg adoption in the *nix world and lack
of competition.

If it isn't cross-platform and user friendly,it shouldn't be used by the
average citizen. As much as the cryptonerd in me likes this news,Gnupg as it
is shouldn't be used for official matters. Most lawyers and judges would
struggle to use it.

~~~
x220
>If it isn't cross-platform and user friendly,it shouldn't be used by the
average citizen

You will never have cross-platform and user friendly signing software that
also has bulletproof security. Let the people who are skilled enough to know
what they are doing continue using GnuPG.

~~~
laumars
Keybase managed it.

The "cross platform" bit is completely irrelevant. The user friendly and
strong security (there's no such thing as bullet proof security) points are
certainly achievable with a little effort.

~~~
badrabbit
Cross platform is important for official matters because allowing a platform
specific tool means the government,legal community and fellow citizens are
also expected to use that platform to interact with content made or consumed
by that platform specific tool.

~~~
laumars
I'm a strong advocate for writing platform agnostic code. My point was being
cross platform is irrelevant to making something user friendly or secure.

~~~
badrabbit
In that case I agree with you,except to say "your platform isn't supported" is
user-unfriendly.

~~~
laumars
Sorry but you're still missing my point (though I didn't really make it all
too clear).

User friendly design is about understanding user behaviours, UI/UX, etc. It's
about designing sane workflows and user interfaces. Whereas writing cross
platform code is a technical complication regarding the internals of a
particular application. The crossover is between cross platform development
and user friendly design is just which UI toolkit you choose to use (ie
Electron, Qt, native platform-specific widgets, etc?) and even that is really
just an implementation detail rather than a fundamental roadblock in designing
user friendly applications.

Thus the requirement for something being user friendly shouldn't affected by
the requirement for something being cross platform.

This is why I say the cross platform point is irrelevant. Not because cross
platform solutions aren't important but rather because they're not the reason
many solutions aren't user friendly (the reason is much more simple than that:
they were designed by technical people to be used by technical people).

------
AceJohnny2
So I get the impression GnuPG is considered obsolete by the security
community. I'm unclear for which of the many possible scenarios it can be used
for.

Is there, right now, a better (security-wise and usability-wise) way to
digitally authenticate a message (document/binary/payload)?

~~~
tptacek
For simple operations like encrypting individual files or applying a signature
to a document --- where the alternatives is already insecure --- PGP is fine,
if clunky.

For modern message encryption, PGP is inferior to alternatives and generally
should be avoided:

1\. It lacks any native notion of forward secrecy or meaningful compromise
recovery, which is table stakes for modern protocols.

2\. Partly as a result of (1), it leaks meta-information; in particular, it's
difficult to send deniable messages with it.

3\. The most compatible subset of its protocols are built on 1990s
cryptography, including non-AE bulk ciphers and RSA.

4\. Its tooling is difficult to use, even more difficult to use with what we'd
now consider adequate opsec, and far more difficult still for an ordinary
person to use that way.

5\. That tooling is of wildly variable quality; PGP sees somewhat routine
vulnerabilities in its tools, which invariably get downplayed ("that's not a
bug in PGP!").

6\. Its most mainstream use is to attempt to layer modern message security on
top of email, which is its own can of worms.

Generally, you should use Signal or maybe Wire (if you're a Signalphobe) in
preference to PGP.

For an application where it really mattered, you'd want to see a signature
system derived from SHA2 and Ed25519, with no backwards-compatibility towards
archaic cryptography. There's nothing mainstream that really gives you this
right now, but really there isn't much (outside of blockchainia, which is
already hipster-deep in modern crypto esoterica) that really demands secure
digital signatures.

~~~
tanderson92
Can you elaborate on what you mean by (1-2) leaking meta-information and
making deniability difficult? Do you mean that even when choosing to encrypt
but not sign I am leaking definite proof (like a signature) of my private key
information in the encrypted message?

That seems hard to believe unless I am misunderstanding you, because my
experience is that any private key use requires auth from my Yubikey and yet I
can do encryption without my yubikey plugged in at all.

edit: If by deniability you're talking about PFS, then, well, don't sign
something you want to be able to deny having signed. I feel your comment might
be misinterpreted to be a critique of PGP encryption when really it's a
critique of PFS of PGP signatures+encryption.

~~~
valarauca1
Your public key is always clear text, or at a minimum your public key finger
print (which can be used via a key-server to find your personal information
and public key).

So GnuPG to a degree makes it difficult to hide metadata about yourself as
many tools will send your public key + data to a key server as soon as they
create your key-pair. This is so when people verify you, your easier to find.

This creates a chicken-in-the-box metadata problem where for people to very
your public GnuPG public-key is really you that info has to be public, but for
anonymity it can't be .

~~~
tanderson92
This is all true, but is a different question from _deniability_ when sending
messages, and leaking metadata when sending information, which is what tptacek
claimed:

> ...in particular, it's difficult to send deniable messages with it.

It's easy (unless tptacek is mentioning an attack I am unaware of) to ensure
deniability -- encrypt but don't sign.

~~~
jancsika
Not sure what OP was getting at (maybe the difficulty of deniability using
GPG/GPG-encrypted mail defaults), but you'd still be sending to a recipient's
long-lived public key.

That's practically different than a system like OTR that has forward secrecy
by default.

~~~
tanderson92
Since anyone in the world can encrypt _to_ a PGP public key, deniability is
trivial. It is true that some systems (like enigmail) also encrypt to your own
public key when sending messages, but this is also easily deniable.

------
scrollaway
This sounds huge. There's entire businesses centered around very specific
state laws like this (cf. notarize.com).

I hope this spreads. As long as notarization remains important, digital
notarization is important.

------
dcbadacd
I've used both GNPG and Estonian eID. I have to say Estonian eID is way more
usable when one needs to sign anything. The (digidoc4) software is just way
more usable, nicer and designed for the task. I wish GNUPG were as good

------
djsumdog
Docusign has been allowed to be used a notary in Washington; or at least
Seattle for notary requirements around housing documents.

(Seattle law requires notarization on leases over 12 months).

There's a PGP short ID listed on the e-signed document, but it's not yours.
There is no point where Docusign checks your ID.

------
sam0x17
This is extremely cool, but I wonder in practice whether people in Washington
who accept notarized documents/etc would know this is a valid way of doing
things? Education seems important here.

------
ZainRiz
Notarizing documents sounds like it could actually benefit from blockchain
technology.

Have a set of Established Authorities who can grant notary status. They give
notary status to people according to their own set of requirements.

The notaries can then add a record on the block chain saying roughly "I do
notarization act X on document Y" (It'll be the equivalent of what they enter
in their log books today and there will be some corresponding stamp that
they'll stamp the physical document with, like they do today). They could now
even notarize digital documents by including a hash of the digitized document
in their record.

Finally, the agency receiving the notarized document (digital or electronic)
can easily go onto the blockchain and verify that the document was indeed
notarized as claimed and that the notarization is not a forgery.

Each agency that receives the notarized document could have their own subset
of Established Authorities who's notaries they will accept. This means anyone
could become an Established Authority, but individual agencies like the US
Federal Government could publicly say "hey, our Authority Id is 'USRoxs'" but
it'll be up to the receiving agencies like England's government to decide "We
trust the system the US uses to validate it's notiaries, so we'll add 'USRoxs'
to our list of accepted Established Authorities (along with 'TheEnglish' of
course)"

~~~
onli
Notarizing documents is a great example where some people think blockchain is
a good use case, and it's never true.

Where would be the advantage of the scheme you describe to the current system?
There is none. The system already works: people are given power to validate
documents by the authority. The authority stores that centrally. The
validation is mostly collected centrally. All stuff you can do perfectly fine
without needing to run replicated servers storing an evergrowing immutable
blockchain sipping authority from the real authority.

The current scheme allows things like secret notarization and revocation,
stuff a blockchain is very bad at.

> _it 'll be up to the receiving agencies like England's government to decide
> "We trust the system the US uses to validate it's notiaries, so we'll add
> 'USRoxs' to our list of accepted Established Authorities (along with
> 'TheEnglish' of course)"_

Countries already have systems in place to accept documents made in other
countries. Works with official translators and stamps/seals of authenticity.

In better and funny: Blockchains Are a Bad Idea (James Mickens),
[https://www.youtube.com/watch?v=15RTC22Z2xI](https://www.youtube.com/watch?v=15RTC22Z2xI)

~~~
cbolton
Notary services are expensive, and some notaries are corrupt. I'm no fan of
bitcoin, etc. OTOH this does seem like a good blockchain application, and the
fact that it doesn't burn a stupid amount of electricity is nice too.

I'm curious about secret notarization and revocation. Why is that particularly
desirable? I guess it would be a poor fit for a blockchain indeed...

~~~
onli
Not my area, but think of things like a will. You being a billionaire maybe do
not want to let your murderous family know that you made a new one writing
them out of your will.

> _Notary services are expensive, and some notaries are corrupt_

A blockchain being the place where the act of bureaucracy ends up being stored
changes nothing about that.

> _OTOH this does seem like a good blockchain application_

Exactly. It does at first, because it's about authoritatively storing
information, and isn't this what a blockchain is good at? But then you think
about how the system actually works and what the requirements are. A
blockchain brings you immutable and decentralized storage of peer-validated
information. None of these properties are of any value here. We just need a
centralized storage that does not forget values by accident, which is
basically every other solid information storing system. And most of those are
a lot easier to run than a blockchain.

~~~
topmonk
> think of things like a will. You being a billionaire maybe do not want to
> let your murderous family know that you made a new one writing them out of
> your will

Hash the will. Store the signed hash on the blockchain. Then, no one knows
what the hash represents until your lawyer reveals the will after you've died.

~~~
stordoff
What do you gain if the lawyer has to reveal it anyway? If you don't trust the
lawyer[1], just give a hash of the document to the people who would be
affected.

I don't see what role the blockchain plays here.

[1] and who's to say there aren't multiple signed hashes on the blockchain
anyway?

~~~
topmonk
> I don't see what role the blockchain plays here.

> [1] and who's to say there aren't multiple signed hashes on the blockchain
> anyway?

The timestamping of the blockchain is the use case. If multiple signed hashes
exist, the latest one supersedes all the previous.

> What do you gain if the lawyer has to reveal it anyway? If you don't trust
> the lawyer[1], just give a hash of the document to the people who would be
> affected.

I'm afraid I don't understand. Who would hold the original text of the
document in your plan?

Edit: Nevermind, I see what you mean, here. I see the issue as one of public
record. If there was a revision to the will which no one in the family liked,
and benefited some estranged cousin of yours who lived in another country, the
family and the lawyer could conceivably hide the new will and the fact that
you were dead from this cousin. Having it all on the blockchain prevents this.

------
otohp
Matthew Green had a good post on what is wrong with PGP:

[https://blog.cryptographyengineering.com/2014/08/13/whats-
ma...](https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-
pgp/)

~~~
confounded
GnuPGP can be used for a lot more than encrypted emails (the subject of that
post).

Is there anything wrong with notaries being able to use GnuPGP?

~~~
otohp
No idea.

------
aj7
In theory, FedEx overnight envelopes, their most lucrative business, just died
in Washington state. Am I right?

------
nwroot
This is great progress for other locations as well!

------
cjcollier
That's pretty cool, bro.

------
sabujp
tldr; do i still need to pay a notary or can i self attest using a gpg key
tied to my email address?

------
unixhero
All it needs now is a solid blockchain. Vechain could be one perhaps.

~~~
DINKDINK
What do you need a blockchain for? Blockchains are necessary when you need:

Proof of publication Trustless time stamping Trustless transaction execution.

~~~
toomanybeersies
Trustless time stamping seems to be a good thing to have for notarising.

~~~
confounded
Isn’t trusting the notary the whole point?

~~~
toomanybeersies
Quis custodiet ipsos custodes?

Who will watch the watchmen?

------
lrvick
Dupe of:
[https://news.ycombinator.com/item?id=18013182](https://news.ycombinator.com/item?id=18013182)

