[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openpgp] OpenPGP private certification [was: Re: Manifesto - who is the new OpenPGP for?]



On Thu, Apr 2, 2015 at 10:29 AM, Derek Atkins <derek@xxxxxxxxx> wrote:
> Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> writes:
>
>> By that I mean fixed in time. I agree that it does not need to be
>> public. Only the hash needs to be enrolled.
>
> Unfortunately it doesn't matter.  As soon as you require any kind of
> "enrollment" the system fails.  Period.  This was (and still is, IMHO)
> the major issue with X509/SMIME -- My mother would need to jump through
> hoops that she doesn't understand how to jump through in order to get
> set up in the system.  I.e., the system doesn't work until the user gets
> blessed by some CA.
>
> This is IMHO the power of the OpenPGP model -- generate and go.  From a
> UI/UX perspective the system asks for some information (which
> technically it already has when you create your email account) and it
> generates a key pair for you.  Maybe it uploads it to a keyserver (which
> I suppose some could consider "enrollment", but it's a far cry from X509
> enrollment requirement).

Since the key servers won't allow me to revoke the cert for the
private key I have no control over, I think that it would be more
accurate to say that rather than having no enrollment mechanism, there
is a broken one.

I am not proposing use of X.509 here. In fact I think it is quite
clear that CA issue and peer-peer endorsement have very different
requirements and expectations.

My point is that both can be greatly strengthened by enrolling the
assertions in an append-only log.

I would not suggest PKIX or even ACME to do this. But any Web service
to support this approach should certainly follow the ACME style etc.


> From this point on the OpenPGP user can encrypt messages to other people
> and get encrypted messages to them.  The can choose to get their key
> signed by others (or not).  They could get it signed from their
> enterprise (if they are in a corporate environment -- my mother
> certainly is not).  But the key (pun intended) is that the system works
> without any certifications.

Which is exactly what I do in PrismProof for S/MIME. Enrollment is not
only optional, it is not implemented yet (I got halfway before ACME
hit and now I am redoing some stuff in the guts).

All I need to send an encrypted mail is

* The SMTP address to send it to
* Either
  * The public key and encryption options
  * A fingerprint to resolve authenticate the above

> From a usability perspective this is the model I would want to see.  I
> honestly don't care if the actual messages are CMS or 4880 (although I
> have a large disdain for all things ASN1).

I hate ASN1 just as much as the next guy.

I do not care what format the messages are in. All I care about is who
we can reach with them.

There are a billion+ clients in existence with S/MIME built in. Every
email client has to implement TLS these days to secure POP/IMAP/SUBMIT
communications and CMS comes with practically every TLS library.

If there is a message formatting option that lets us reach those
billion+ clients with an OpenPGP message without compromising the
trust model or anything else then lets take it.

I would not try to change the 4880 format but we could probably
document it more rigorously and remove options that are not needed.


The focus for OpenPGPvnext should be to eliminate the cruft while
enabling use of as much legacy infrastructure as possible. AFTER that
is done we can consider how to design a secure messaging protocol that
meets every communication need. Such a protocol will almost certainly
be based on JSON with a minimal extension to support binary blobs and
text blobs.

> So please, for all things sacred, let's not require any kind of
> "enrollment" for the system to operate.

I certainly don't want an enrollment requirement for making the system operate.

> Now, if we want to talk about enrollment for "key lookup" properties, of
> (non-required) certifications, or anything like that ... I'm all ears.
> But it should not be a pre-requisite for a user to get up and running.

Absolutely.

I am not actually a fan of using the cloud as a crutch to solve every
UI issue. But there are a few problems that it is a really big help
on.

The analogy I would point to is the Web. One of the main reasons the
Web caught on was that all you needed to do to get up and running was
to download the server and run it. It didn't even need administrator
privileges to run on port 8000.

Today, anyone who wants to can set up their own Web server and have
complete control. But the simplest approach for most folk is to have
that done for them by a hosting provider.

There are three functions where I see an advantage to the cloud:

1) Notarization (e.g. CT like things)
2) Discovery (How does Bob find Alice's key)
3) Escrow (Storing encrypted private key in the cloud)

All three of these functions are optional. The only reason to do
enrollment is to support these functions. So if you don't want any of
them or you are planning to do some yourself then you don't need
enrollment. The casual first time user is probably best advised to
make use of all three at the start (yes even the third).

_______________________________________________
openpgp mailing list
openpgp@xxxxxxxx
https://www.ietf.org/mailman/listinfo/openpgp