Subject: [saag] Possible rechartering of OpenPGP Working Group

From: Derek Atkins <[email-masked]>
Date: Fri, 13 Mar 2015 10:46:27 -0400

Hi,

Over the past couple days there's been some discussion on the
possibility of rechartering the OpenPGP working group.  Some of the
discussions have been about updating RFCs 4880, 3156, and 6637.  Other
discussions have been about new features and/or algorithms.

If you're interested in this topic I suggest you subscribe to the
OpenPGP mailing list <[email-masked]>

We are planning a Bar BOF in Dallas to discuss possible rechartering.
The exact date, time, and location will be sent to the openpgp mailing
list.  Assuming this BOF happens before Thursday I'll give a report in
SAAG.

Happy Encrypting!

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Mar 2015 09:05:36 -0400

> list.  Assuming this BOF happens before Thursday I'll give a report in

To what end?

Right now we have two email standards and a stalemate. PGP has won the
mindshare battle and S/MIME has won the deployment battle. Neither side has
delivered a product that the typical Internet user is willing to use and
neither side is willing to give an inch to the other.

And the prospects for end-to-end secure email are currently getting worse
with webmail replacing end-to-end mail.

Rather than reform to work on "OpenPGP", I think it would be better to
develop a successor standard to S/MIME and OpenPGP that allows a single
message format to be used with either trust model, or with new trust models.

Quite a few things have changed since 1992 and many of the design
constraints in S/MIME and OpenPGP no longer apply:

* Public Key crypto is now cheap
* Can rely on network connectivity to solve some problems
* Internet users are not experts and don't want to be
* Mail is merely one form of stored document
* Crypto libraries typically bundle ASN.1 handling code for PKIX

All of the tricks that I use to make S/MIME encryption totally transparent
to the end user can be applied to PGP as well.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 16 Mar 2015 10:05:31 -0400

>     list.  Assuming this BOF happens before Thursday I'll give a report in

To clean up a bunch of issues that implementation have hit.
To update some of the key format issues that have been lying around.

> neither side is willing to give an inch to the other.

I wouldn't say S/MIME has won a deployment battle; I would say it won
the "Implemented in MUA" battle.  There is PGP/MIME, too.  So why not
use your might and get behind that?  What makes S/MIME so much "better"
than PGP/MIME that the major MUA manufacturers aren't willing to
implement it?

> And the prospects for end-to-end secure email are currently getting worse with
> webmail replacing end-to-end mail.
>
> Rather than reform to work on "OpenPGP", I think it would be better to develop
> a successor standard to S/MIME and OpenPGP that allows a single message format
> to be used with either trust model, or with new trust models.

That's a good idea, but separate from this one.

> Quite a few things have changed since 1992 and many of the design constraints
> in S/MIME and OpenPGP no longer apply:
>

Yes, this is something that we all have to accept.  :)

> * Mail is merely one form of stored document

While I agree with you on this, I don't think everyone does.

> * Crypto libraries typically bundle ASN.1 handling code for PKIX

I don't see this last item as a feature.  PKIX is not the right solution
for Internet Email.  If it were then S/MIME would be in widespread use
already.  The fact that it's not, even though pretty much every email
client supports it, implies that S/MIME+PKIX is absolutely the *WRONG*
solution, so let's look for something else.

> All of the tricks that I use to make S/MIME encryption totally transparent to
> the end user can be applied to PGP as well.

Who cares about S/MIME?  As you point out, pretty much every email
client has supported it for a very long time, so why isn't it in use?
Let's solve that problem.

Updating OpenPGP is still necessary, and might even be a partial
solution to the problem!

-derek

---

From: Paul Lambert <[email-masked]>
Date: Mon, 16 Mar 2015 09:05:15 -0700

Rather than reform to work on "OpenPGP", I think it would be better to develop a successor standard to S/MIME and OpenPGP that allows a single message format to be used with either trust model, or with new trust models.

+1

Quite a few things have changed since 1992 and many of the design constraints in S/MIME and OpenPGP no longer apply:

-1 on the PKIX …

All of the tricks that I use to make S/MIME encryption totally transparent to the end user can be applied to PGP as well.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Mar 2015 16:17:38 +0000

On 16/03/15 16:05, Paul Lambert and/or PHB wrote:
> 
> Rather than reform to work on "OpenPGP", I think it would be better
> to develop a successor standard to S/MIME and OpenPGP that allows a
> single message format to be used with either trust model, or with new
> trust models.

It's probably obvious, but if one wanted the above, then organising
a bunch of similarly-minded folks would be the thing to do. Asking
a different bunch of folks to not do something non-crazy that they
seem to want to do isn't really so likely to be a winning strategy.

Cheers,
S.

PS: Of course we don't yet know if those interested in some new work
on openpgp will get their act together either, but there are some good
folks who seem to be trying.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 16 Mar 2015 13:53:17 -0400

+1

Donald

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Mar 2015 14:16:38 -0400

On Mon, Mar 16, 2015 at 10:05 AM, Derek Atkins <[email-masked]> wrote:

> use your might and get behind that?
>

I did not say get behind S/MIME. This idea that we have to choose is the
real problem.

What I think we need to do is to move to an email message standard that:

* Can be used in OpenPGP clients
* Can be used in S/MIME clients
* Is supported in Web browsers as an encrypted format

I don't think it is at all necessary that SecureMail TNG need be 'either'
S/MIME or OpenPGP. But they should both be able to leverage the existing
infrastructures (PGP key servers, PKIX certs, deployed MUA) as legacy
wherever they exist.

As a practical consequence of the fact that the OpenPGP brand has won, any
successor spec is not going to be called S/MIME.

> What makes S/MIME so much "better" than PGP/MIME that the major MUA
> manufacturers aren't willing to implement it?

Well that is an important question that I would like to get them to answer.

But one reason is that as far as the vendors are concerned 'security' is an
enterprise feature and they are selling gear that lets Alice in Accounts
send mail to Bob in Legal, not Alice sending Bob intimate photographs.

The vendors have invested in managing keys with PKIX and they want to be
able to leverage that investment. I think that should certainly be one
option for using secure mail. Because when I am sending an email to Carol
at the bank, I really do care that it is going to the bank security
infrastructure, not Carol's personal one.

Another issue with OpenPGP is that it actually has two different trust
models, the one we all use and the one we all talk about.

The one we use is key fingerprints. The one that gets talked about is key
signing.

> While I agree with you on this, I don't think everyone does.

Considering document level encryption as an email message you are sending
to yourself solves a lot of problems and enables use of a lot of existing
infrastructure.

> solution, so let's look for something else.

The same argument can be made against PGP and with greater force. The
number of registered PGP keys and active S/MIME certs are very similar. The
number of folk required to use S/MIME for government work is non negligible.

Thinking of it as an either/or thing is not helpful. What we should be
doing is to look for ways we can reach common ground.

I find it rather odd that we have a 'TLS everywhere' lobby and a 'no PKIX
in email' lobby and there is a huge overlap.

We can solve a lot of interop issues and jettison a lot of code by working
out ways to share code between the systems. DANE has managed to do that, we
should at least try the same approach in email.

> Let's solve that problem.

The reason it is not more widely used is that the usability still sucks.

Having tried to use OpenPGP and failed the one time I tried to use it
since, I don't think that is the answer either. Any system that INSISTS
that I choose some passphrase to store the private key rather than let me
make my own choice is going to fail when I only use it once every 6 months.

Then I discovered that there is no way to unregister the key having lost
the passphrase.

If I can't use it then heaven help the typical user.

> Updating OpenPGP is still necessary, and might even be a partial

Nobody is arguing against that. But how we go about things makes a big
difference.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Mar 2015 14:50:05 -0400

> * Crypto libraries typically bundle ASN.1 handling code for PKIX

I didn't say people had to use it. Only that it exists.

One way to start a harmonization program would be to define one mechanism
for taking a fingerprint of a public key that can be recognized by OpenPGP
based infrastructure and other infrastructure.

The OpenPGP fingerprint desperately needs an update. It is best if the IETF
has one fingerprint algorithm that can be used in any application.
Including TLS and IPSEC.

For a while folk have been running a .onion domain with the idea that the
dns domain name is <fingerprint>.onion. Which is a fine solution for TOR
but still undersells the concept.

For example, consider the following where <fingerprint> is a root of trust
under which the DNSSEC and PKIX key signing keys are signed. We can use
this sort of approach to define universal constants in a key centric PKI.

example.com.<fingerprint>

Fingerprints of keys are very useful and powerful.

The current OpenPGP fingerprint needs updating. If we move to a mechanism
that makes use of the existing PKIX keyInfo structure we have a mechanism
that will automatically add support for all new public key algorithms,
suites, etc as they are defined.

So as far as the specification goes it would be:

Base32 ( <version> + Truncate ( SHA-2-512 ( <keyinfo> ), n))

Now before folk start complaining about 'ASN.1 encoding'. This is already
used to define crypto formats at the lower layers (PKCS#1 for example). The
reason it doesn't get in the way is that it is easily faked for fixed
length keys by simply splicing in constant strings.

We can do that for public key algorithms as well. OIDs are a particularly
obnoxious encoding to implement. But I don't do that in any of my runtime
code, I convert every OID to a sequence of bytes.