Subject: [openpgp] How to re-launch the OpenPGP WG

From: Werner Koch <[email-masked]>
Date: Thu, 12 Mar 2015 13:31:37 +0100

Hi,

Since some time the OpenPGP protocol is again en vogue and the tendency
to prefer S/MIME over OpenPGP is not as strong as it seems to have been
once.  Case in point, the DANE WG has a last call for an OpenPGP DNS
record type.  This is obviously related to OpenPGP and should have been
discussed here as well (actually we did briefly in Summer 2013).

There are several tasks the WG should do:

 - New signature subpackets.  For example one to specify a fingerprint
   and not just the keyid.

 - Take care of individual I-Ds.

 - The use of SHA-1 needs to be replaced.

 - A v5 key format.  Prepare for forthcoming public key algorithms.

 - A new encryption mode to replace our aging CFB+SHA1 method with a
   fast and standard mode.

 - Maybe extend it to key distribution.

Is there any interest in this?
How can we get the WG out of the concluded state? 
Would the Dallas meeting be a starting point for this?
Who would volunteer as Chair?

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Thu, 12 Mar 2015 13:38:00 +0100

Hi,

I'd be very much interested. I even have some ideas/suggestions that I
am going to write to the list, if there is some interest.

Cheers,

Daniel

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Thu, 12 Mar 2015 13:42:09 +0100

> Hi,

...

> Is there any interest in this?

I certainly think it is a good idea

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Nomina stultorum scribuntur ubique locorum
Fools have the habit of writing their names everywhere

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 12 Mar 2015 09:37:04 -0400

Hi,

> Is there any interest in this?

There certainly seems to be.

> How can we get the WG out of the concluded state?

We would need to effectively create a new WG.

> Would the Dallas meeting be a starting point for this?

We couldn't necessarily charter it in Dallas, but we could certainly have
a bar bof in Dallas to work out a charter.  We would need to talk to the
SecADs about chartering the group.

> Who would volunteer as Chair?

The Chair(s) is(are) appointed by the ADs. Volunteers are good, but not
necessarily used.  ;)

>    Werner

-derek, former chair :)

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

---

From: Stephen Paul Weber <[email-masked]>
Date: Thu, 12 Mar 2015 08:38:46 -0500

> - New signature subpackets.  For example one to specify a fingerprint

This needs to happen.

> - A v5 key format.  Prepare for forthcoming public key algorithms.

What sorts of changes do you see being needed here?

> - A new encryption mode to replace our aging CFB+SHA1 method with a

Right.

>Is there any interest in this?

Yes.

>How can we get the WG out of the concluded state?

So, some of these things have been proposed as, like, extension RFCs or 
whatever instead of a supercession to main OpenPGP.  But I guess that work 
is usually done under this WG as well.  Do you see moving more in that 
direction, or a full-on new RFC coming out of proposed work?

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Mar 2015 09:50:19 -0400 (EDT)

> Is there any interest in this?

I think there is interest.

> How can we get the WG out of the concluded state?

Write up a list of things to do, draft a new charter. You started some
of that already with your list above.

> Would the Dallas meeting be a starting point for this?

Deadlines for organising things "officially" are passed:
http://www.ietf.org/meeting/important-dates-2015.html#ietf92

But I'm happy to organise an unofficial meetup and take notes.

> Who would volunteer as Chair?

I'd be happy to be a co-chair.

Paul

---

From: Johan van Selst <[email-masked]>
Date: Thu, 12 Mar 2015 15:06:56 +0100

> There are several tasks the WG should do:
[..]
> Is there any interest in this?

Yes, I think it is a good idea to re-launch an OpenPGP WG for this.

Regards,
Johan

---

From: Tom Ritter <[email-masked]>
Date: Thu, 12 Mar 2015 09:39:22 -0500

I'm not sure what the numbers needed to show interest are, but +1.

-tom

---

From: Werner Koch <[email-masked]>
Date: Thu, 12 Mar 2015 19:01:40 +0100

> What sorts of changes do you see being needed here?

In the past we collected several ideas for a v5 key format.  We need to
revisit the list archives.  IIRC, the plan was to first wait for the
outcome of the SHA-3 competition.

> that work is usually done under this WG as well.  Do you see moving
> more in that direction, or a full-on new RFC coming out of proposed
> work?

Eventually a single new RFC should be done - for a v5 format this will
be needed anyway.

Salam-Shalom,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Thu, 12 Mar 2015 11:58:09 -0700

> On Mar 12, 2015, at 11:01 AM, Werner Koch <[email-masked]> wrote:
> 

There were other things we talked about as well in V5. I think that connected and separate, a hash-independent way to do a fingerprint is called for. There was a nice proposal for that in the archives -- algorithm-id:hash-value -- the abbreviated one.

> Eventually a single new RFC should be done - for a v5 format this will

Or not -- it's a decision of the new working group.

We traditionally put everything into one document. That has a lot of advantages. There's essentially one place to check. Other WGs -- for example, S/MIME -- have a lot of separate documents. That means they can work on things in parallel, but makes it harder to wind through the mass of documents.

I think more than one but less than fifty (which is only a slight exaggeration -- the last time I checked there were over 35 S/MIME documents) is a good compromise.

But yeah, I think you'd want to revise 4880 for new stuff. There are, however, a number of ways to organize that.

	Jon

---

From: NIIBE Yutaka <[email-masked]>
Date: Fri, 13 Mar 2015 09:38:36 +0900

> There are several tasks the WG should do:
[...]

Yes.

I think that some improvements would be expected for ECC.  My specific
interests are the point format(s) and Curve25519 support.

There are two drafts for new point formats:

    Compact representation of an elliptic curve point (expired):
    https://tools.ietf.org/html/draft-jivsov-ecc-compact-05

    EdDSA for OpenPGP:
    http://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-02

And, IIUC, we will introduce another point format for Curve25519.
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 12 Mar 2015 21:11:22 -0400

> But I'm happy to organise an unofficial meetup and take notes.

I'm also happy to help with something unofficial in Dallas even though
the "official" dates are past.  I think this is a good idea.

fwiw, i'd consider a re-chartered wg to cover possible revisions or
extensions to several RFCs, not just 4880:

  https://tools.ietf.org/html/rfc4880   -- OpenPGPv4
  https://tools.ietf.org/html/rfc3156   -- PGP/MIME
  https://tools.ietf.org/html/rfc6637   -- ECC in OpenPGP

To add an item to Werner's earlier list:

 * i'd like to spec out an adjustment to PGP/MIME that provides
   signature and encryption protection for RFC 822 headers.

We've had some discussion and interest about this on the Enigmail
mailing list already, and there was an in-person discussion at the CTF
in Valencia last week (using the placeholder name "memory hole").
Nailing down exactly how we expect that to work should be in-scope to a
new WG.

    --dkg

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 12 Mar 2015 21:24:02 -0400

Okay, there is clearly an interest in forming something, so...

Who will be in Dallas?
When would be a good time to have a BAR BOF?
I propose we meet Monday after the plenary?

-derek

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Mar 2015 21:25:14 -0400 (EDT)

> the "official" dates are past.  I think this is a good idea.

Ok, let's go throug the schedule and find a time slot that might work?

> Nailing down exactly how we expect that to work should be in-scope to a

openpgpkey-milter currently only masks the Subject: line and places it
as the first line in the body of the (encrypted) email, followd by a
blanc line, kinda like mbox. It would be very useful to do this for
more headers!

Paul

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Fri, 13 Mar 2015 04:52:48 +0100

>Is there any interest in this?
There definitely is ... contrary to what some loud campaigners (recently
heise in Germany, or the advocates rubbish X.509 of crappy key pinning
technologies) try to make people believe, OpenPGP is still alive and
actually the only really securely usable PKI standard (anything strict
hierarchical like X.509 is IMHO inherently insecure, at least in
practical usage) for the masses. 
> There are several tasks the WG should do:
Since people start to come up with their wishlists... here'd be mine:

1) More general things
- The WG should consider whether to just bring OpenPGP up to date... or
  whether to completely overhaul or even re-design it.

In the later case:
- The basic meshed web of trust must obviously be retained, but apart
  from that there should IMHO be no taboos, like dropping the old
  formats or perhaps even completely changing the format (if some people
  would think an XML representation would be better, discussions should
  be open for that - not that I'd be an advocate of this).

- OpenPGP should be made fit or at least extensible enough for any mid-
  or long-term developments in engineering and crypto, this might
  include things like:
  - Since the X.509 PKI infrastructure in the internet is inherently
    broken and since DANE would only partially improve things (one still
    has several CA's above which could be evil), the time may come in
    which at least some security conscious people would want to use TLS
    or similar with a fully meshable PKI as OpenPGP.
    For that we might need similar things as X.509 got eventually,...
    things like SubjectAlternativeNames for IP, DNS, email, etc.
  - Any preparations for PQ Crypto? Or for hybrids of PQ and "normal"
    crypto?
  - For the ultra-paranoid: Semantics that allow usage of multiple
    ciphers and hash algos (i.e. encrypt a message with AES first, then
    Serpent, then Cesar chiffre ;) ... or make signatures with SHA2 and
    SHA3 and require all to be valid.

2) More specific things:
- get rid of any SHA1
- fingerprints should allow to use different hash algos, in order to
  keep it easily up to crypto developments
- ideally not using fingerprints in the signature subpacktes if that can
  be avoided (thinking of the Revocation Key subpacket

- the whole standard should be much more definite and strict, currently
  we have many places which are quite vague or which allow to do the
  same thing in different ways, examples:
  - the critical flag should become a non-critical flag (i.e. per
    default everything is considered critical unless something else is
    explicitly said.
  - other properties are simply not well enough defined or could at
    least be made better, e.g. what if a policy URI is used on a
    selfsig/direct key sig... is that then still the "the policy
    under which the signature was issued", which would be kinda
    useless... or should it be better they policy under which this
    key/user makes signatures?
  - there need to be a definite algorithm which decides which
    selfsig/direct key sig/user sig is to be used, if there are still
    multiple valid (IIRC, that wasn't defined, but it's some time ago
    since I last read through the RFC)
  - We have the direct key sig, which would make sense to be used for
    some things, but actually no one seems to really use it. So either
    drop it, or if it is kept, then it should be more clearly specified
    how the semantics change when some subpackets are used on a selfsig
    vs. a direct key sig?
    E.g. what happens if one has a key which a direct key sig (0x1F)
    that says "certification only key" while a 0x13 selfsig says
    "certification + encryption"). Similar for the other properties like
    Policy URL, where this could actually make sense, e.g. a PolicyURL
    on a 0x1F self-sig tells the "global Policy for all UIDs", while one
    on a 0x13 tells further policy rules when the signature is made with
    this specific UID[0].
  - It should be possible to select more key properties to be fixed
    (i.e. unchangable), like key expiration time, key usage.

3) UIDs respectively the data that others actually verify/sign should be
   completely overhauled.
  Right now we have User ID Packet (13) and User Attribute Packet (17),
  with the later having only one actual attribute (the image) defined.

  The UID is by convention a mail address, but even the standard already
  says that this is just "by convention", it doesn't even use SHOULD or
  RECOMMEND.

  I'd change this the following way:
  The UID is really just an ID for they key, which should be unique
  within the realm of they keys usage.
  That means, for globally public keys, we should make this a MUST to
  either a mail address (and I'd even say just the addr-spec) or a
  domain name.
  But for any non globally public usage, this could be something like as
  students ID number.
  It follows from that, that the UID would no longer be something what
  other really certify (in the sense that they've checked whether this
  is really my mail address or my students ID number). Of course they'd
  still sign it, but it wouldn't give the key any real trust.
  As said it would be more a technical ID, which can be used by
  applications in a given realm to easily distinguish/select keys.

- Everything that really identifies the person behind the key (i.e. puts
  trust into the key) should be go into something like the attribute
  packet... but there things should be greatly extended.
  It shouldn't just be the name, picture or email address. Think of
  things like natural colour of hair/eyes, skin colour, body size,
  birthdate/place. All different forms of names, from the western first
  name(s), second names, middle names, family names, perhaps academic
  grades over e.g. Arabic style names maybe even to Tolkien's elven
  names where they have Epessë, Essi and Amilessë ;) .
  Ideally we'd have a separate and easily extensible registry for these
  fields, so that one can also easily add things like I don't know:
  "org.debian.developer=DDname" or "com.github.user=foo".
  People should be able to sign the personal information which they
  actually have from their peers (and github, for example, will probably
  never know my name for sure, but they know me by my account name).
  One could even think of different image types, starten from a face
  shot of the person (as we have now), over fringerprint or signature
  scans, perhaps even to heraldic devices of that person, or what they
  have in non-western cultures like the Japanese "inkan" respectively
  "hanko".
  Perhaps an example:
  family-name="Mitterer"
  first-name="Christoph"
  secondary-name="Anton"
  secondary-name="Foo"
  nicknames="Chris"
  nicknames="whatever"
  As you can see, for some fields it should be possible to give them
  multiple times.
  Since the rendering/usage of these separate naming fields is not
  universally defined, I'd probably suggest to add a mutliple usable
  field like:
  common-name="Christoph Anton Mitterer"
  common-name="Christoph Mitterer"
  The key owner could create whichever he things to be appropriate (e.g.
  someone might also add "Christoph A. Mitterer").
  And people signing that key could in principle also choose which of
  the keys they want to sign.
  Perhaps one would also need qualifiers for some fields like people
  from Russia have also given and family names, but obviously in
  Cyrillic, but there might be an official transliteration to the Latin
  Alphabet, so the key could contain both.

- It should be possible to connect these fields with a "valid from" date
  and it should be possible to revoke them later in a way that just
  means like "data superseded".
  E.g. people might merry and their family name changes, they may
  divorce and it changes again. Or one grows older and the image
  changes.

4) one of the IMHO most important things:
It should be possible to connect a UID or something similar with
specific subkeys.

Right now, we have a key with multiple UIDs bound to the key via
selfsigs. If I sign someone else's key or sign some text, regardless of
which subkey I use,... I do this with all my identities, right?
That's quite limiting.

- As said before, one might one to do such act (e.g. the signing or
certifying) with one specific role, e.g. I may want to sign someone
else's key as [email-masked], but not as
[email-masked].

- Another typical use case: I have a primary key, which people sign and
trust, plus several subkeys for encryption/signing.
Now I may want to use some of the subkeys for certain "locations" only,
e.g. my smartphone (which is pretty insecure),... or at work (which is
perhaps more secure as my Google-friends-of-NSA™ Android, but still less
secure as my home systems). So I give only the respective private
subkeys to these locations nothing else.
But since right now people only look at the UID, they typically won't
notice whether my I've signed a message from my Android device (and
therefore the information can only be trusted to some extent).

I'm not really sure whether it should be a UID which can be connected to
subkeys,... probably not.
It should rather be something that is structurally similar to UIDs (i.e.
extensible) and which contains other properties like "usage" or a trust
indicator.

Cheers,
Chris.

[0] Obviously this only makes sense, if a future OpenPGP version would
allow to sign other keys specifically connected with one or more of the
UIDs - e.g. I want to verify someone else in my role as worker of
uni-muenchen.de, but not in my role as private person.

---

From: Werner Koch <[email-masked]>
Date: Fri, 13 Mar 2015 08:06:30 +0100

> Who will be in Dallas?

Sorry, I won't be there.  If there is a need I can attend IETF-93 in
July.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Fri, 13 Mar 2015 08:16:20 +0100

>   whether to completely overhaul or even re-design it.

The please give the thing another name.  Recall the outcry whn I removed
PGP-2 support from 2.1.

> - The basic meshed web of trust must obviously be retained, but apart

OpenPGP does not define the Web of Trust.  There is no standard for it.

>     things like SubjectAlternativeNames for IP, DNS, email, etc.

We already have this.  You may either use a plain user ID with signed
attributes to implement this or, better, extend the attribute packet,
which is currently only used for photo ids, but designed for what you
want.  You may already start with this using the 100--110 subpacket
types.

Regarding the rest of your mail, I think it is better to postpone a
detailed discussion for now.

Shalom-Salam,

   Werner

---

From: Franklin Wang <[email-masked]>
Date: Fri, 13 Mar 2015 20:45:37 +0800

It's very interesting for pure technical users. But do you want to help
ISIS or other terrorists? Pls think over about that.

Franklin

---

From: Derek Atkins <[email-masked]>
Date: Fri, 13 Mar 2015 09:38:04 -0400

> ISIS or other terrorists? Pls think over about that.

I'm not sure if this was a joke of if you're serious.  There's no smiley
face, so I'll go under the assumption you were being serious.  (If I'm
mistaken, feel free to ignore the rest of this message)..

I'm afraid the cat is well out of the bag on that one.  The tools are
out there, and have been out there for well over 20 years already.
Tools, like anything, can be used for good or evil.  The same tools that
you are concerned about are actually being used by Human Rights
Activists in countries with Apartheid-like oppressive goverments.  Take
away the tools and you remove the safety net those worker have!

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Derek Atkins <[email-masked]>
Date: Fri, 13 Mar 2015 09:42:14 -0400

> OpenPGP does not define the Web of Trust.  There is no standard for it.

This was explicitly out of scope from the former OpenPGP WG.  I think
that was a GOOD THING, and I believe it should remain out of scope.
IMHO we shouldn't define how OpenPGP is used, only what it inputs and
outputs.

> want.  You may already start with this using the 100--110 subpacket

For the record, draft-atkins-openpgp-device-certificates already extends
the Attribute Subpacket with a String ID (similar to the UserID).

-derek

---

From: Werner Koch <[email-masked]>
Date: Fri, 13 Mar 2015 14:42:05 +0100

> ISIS or other terrorists? Pls think over about that.

To quote PRZ

  "If privacy is outlawed, only outlaws will have privacy."

Please use other media for such debates.  Thanks.

Shalom-Salam,

   Werner

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Mar 2015 12:29:34 -0400 (EDT)

> I propose we meet Monday after the plenary?

I will be there and the time slot works for me.

Paul

---

From: DataPacRat <[email-masked]>
Date: Fri, 13 Mar 2015 15:51:20 -0400

> IMHO we shouldn't define how OpenPGP is used, only what it inputs and

I'm interested in certain aspects of Webs of Trust, such as their
potential to overcome certain problematic aspects of centralized
Certificate Authorities. If this new OpenPGP WG won't be a suitable
place to discuss such possibilities, then what will be?

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Tom Ritter <[email-masked]>
Date: Fri, 13 Mar 2015 14:59:41 -0500

> place to discuss such possibilities, then what will be?

https://www.ietf.org/mailman/listinfo/therightkey

-tom

---

From: Werner Koch <[email-masked]>
Date: Sat, 14 Mar 2015 12:57:21 +0100

> potential to overcome certain problematic aspects of centralized

Using this ML for discussin is IMHO okay but trust modells are not a
goal of the OpenPGP standard.  It might turn out that a certain feature
would be useful and that would be something which can be put into the
standard.

Salam-Shalom,

   Werner

---

From: DataPacRat <[email-masked]>
Date: Sat, 14 Mar 2015 10:30:06 -0400

> would be useful and that would be something which can be put into the

Will the new OpenPGP standard explicitly include some form of
text-file (or XML, or JSON) format for keys, along the lines of the
venerable 'BEGIN PGP PUBLIC KEY BLOCK'? If so, then as long as it
includes at least one free-form-text comments field which can be used
for arbitrary additional data, such as a score indicating exactly how
much Bayesian trust the key-signer has that the listed key belongs to
its indicated owner, then that would likely be sufficient to cover the
cases I'm thinking of. (There is room for some further elaboration,
such as cryptographically signing said comments, if the general idea
meets approval.)

Thank you for your time,

---

From: "James P. Howard" <[email-masked]>
Date: Sat, 14 Mar 2015 10:34:27 -0400

Is there an upvote button for this?  I even tweeted about this yesterday!

  https://twitter.com/howardjp/status/576473455949967360

The current signed-XML standard is an awful awful thing and having a usable
standard for signed text formats (XML, JSON, whatever) would would make the
implementation a de facto default.

James Howard

On Sat, Mar 14, 2015 at 10:30 AM, DataPacRat <[email-masked]> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Derek Atkins <[email-masked]>
Date: Mon, 16 Mar 2015 09:28:22 -0400

> implementation a de facto default.

Have you looked a JOSE?

I think this would be out of scope for OpenPGP.

-derek

---

From: David Leon Gil <[email-masked]>
Date: Mon, 16 Mar 2015 14:18:59 -0700

On Monday, March 16, 2015, Derek Atkins <[email-masked]> wrote:

> "James P. Howard" <[email-masked] <javascript:;>> writes:
>

One, quite viable, option might be to use a subset of JOSE for OpenPGPv5.

---

From: David Leon Gil <[email-masked]>
Date: Mon, 16 Mar 2015 15:14:15 -0700

>    signature and encryption protection for RFC 822 headers.

 As a note: I consider figuring out something for RFC 822 headers a very
high priority. It is particularly difficult, because many '822' headers are
mainly intended for servers. (And are important for spam control.)

So it may be necessary, in some cases, to encrypt some of the 822 headers
only to the ultimate recipient, and some of them to the server as well.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 17 Mar 2015 04:46:36 +0100

> The please give the thing another name.  Recall the outcry whn I removed
Well I guess it happens very often that one has a very loud minority and
a silent majority.
Removing the support was definitely the right thing, especially since
it's still in the other branches.
All these very old keys are likely lather small (and thus weak) and
shouldn't be used therefore anymore.

IMO, security business can't really afford to always comfort those
living in the past and/or not doing their homework.
This model (leaving legacy stuff in for compatibility reasons) blew up
so often recently (RC4, SSL3, the export cipher suites, problematic CBC
mode usage in e.g. SSH)... these things should have been phased out long
ago, instead, people waited for questionable compatibility reasons way
too long until 5 past 12.

Someone who really wants security should have to suffer because of those
who want to keep old systems/alogs/etc., since the later anyway do not
really want security. 

> attributes to implement this or, better
Well, as I've written before, using the plain UID packets in such ways
should IMHO be given up.

> extend the attribute packet,
Sure, just no one ever specified it, and thus no one every used it that way

> detailed discussion for now.
Fine,... it's now in the archives for the records =)

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 17 Mar 2015 04:59:12 +0100

Also to answer Werner's comment ("OpenPGP does not define the Web of
Trust.  There is no standard for it.")

> that was a GOOD THING, and I believe it should remain out of scope.
I was probably a bit unclear in what I wrote. I've mainly meant:
The functionality of OpenPGP shouldn't be limited in such a way that
what we can do now with it (e.g. the web of trust, or trust hierarchies
via the trust signatures) would no longer be possible.

Apart from that I basically agree that OpenPGP itself (i.e. the RFC for
the message format) shouldn't define a trust system (e.g. the web of
trust), BUT:
a) it might(!) make sense for another RFC to do this on an informal
basis
b) currently we have several things (well at least the different levels
of user signatures 0x10-0x13) which are pretty much undefined, useless,
ambiguous and therefore even dangerous.
0x10 and 0x11 have at least some "proper" definition, but they don't
tell how implementations should react on them (=> dangerous).
0x12 and 0x13 are quite vague and ambiguous.

> IMHO we shouldn't define how OpenPGP is used, only what it inputs and
Phew... well... perhaps not how it's used, but it should be always clear
how a message is to be interpreted - I think I've mentioned some
examples where this is not really the case, and these obviously also
affect the trust and usage model.

> the Attribute Subpacket with a String ID (similar to the UserID).
*If* attributes are to be extended (e.g. in ways as I've proposed in my
previous mail) than I think this is really something that needs
considerable effort to be spent upon.
Properties should be well defined, there shouldn't be too many
properties for actually same things but OTOH one shouldn't be to
reluctant to add new ones when it makes sense. Stuffing everything in a
few generic attributes would be quite bad.

Cheers,
Chris.

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Tue, 17 Mar 2015 09:43:02 +0100

On 03/17/2015 04:59 AM, Christoph Anton Mitterer wrote:
> Also to answer Werner's comment ("OpenPGP does not define the Web
> of Trust.  There is no standard for it.")
> 
>> This was explicitly out of scope from the former OpenPGP WG.  I
>> think that was a GOOD THING, and I believe it should remain out
>> of scope.
> The functionality of OpenPGP shouldn't be limited in such a way
> that what we can do now with it (e.g. the web of trust, or trust
> hierarchies via the trust signatures) would no longer be possible.
> 
> Apart from that I basically agree that OpenPGP itself (i.e. the RFC
> for the message format) shouldn't define a trust system (e.g. the
> web of trust), BUT: a) it might(!) make sense for another RFC to do
> this on an informal basis b) currently we have several things (well
> at least the different levels of user signatures 0x10-0x13) which
> are pretty much undefined, useless, ambiguous and therefore even
> dangerous. 0x10 and 0x11 have at least some "proper" definition,
> but they don't tell how implementations should react on them (=>
> dangerous). 0x12 and 0x13 are quite vague and ambiguous.

I fail to see how this behaviour is either dangerous, nor how it can
be automated in a system with delegated certificate authorities. The
signatures (except for 0x11) are treated the same by the
implementations, which is fine. The information is still useful as
metadata when performing manual analysis of a certification network
and depends on a published certification policy by the issuer. The
uses not being explicit in the RFC does not mean they are vague and
ambiguous, just that they are defined on a per-context / per-CA basis,
and the RFC allows provides a mechanism to distinguish , although most
users should normally always use 0x10.

- -- 
"History repeats itself; historians repeat each other"
(Philip Guedalla)

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 19 Mar 2015 00:05:00 +0100

On Tue, 2015-03-17 at 09:43 +0100, Kristian Fiskerstrand wrote: 
> I fail to see how this behaviour is either dangerous,
Take 0x10 as example:
>       The issuer of this certification does not make any particular 
>       assertion as to how well the certifier has checked that the owner
>       of the key is in fact the person described by the User ID.

Implementation A: may interpret this as "can also include signatures,
                  where NO check has been made at all" and thus it might
                  use it to sign other keys (for whatever reason, e.g. a
                  key-pinning-like method), since it expects that no
                  other implementation would use such sigs anyway
Implementation B: may interpret this as "the certifier has checked the
                  identity, but simply doesn't want to tell, how well he
                  has done so"
                  Such implementation might then use the untrustworthy
                  sigs from A.

Well a bit made up,... but I guess you can see what I mean.

> The
> implementations, which is fine.
Which also shows that they're basically useless.

> The information is still useful as
> and depends on a published certification policy by the issuer.
I disagree, if a user wants to tell under which circumstances he
certified another user/key, hey can do so via the policy URL and in fact
this is the only way for analysis to find out what the certification
means to the certifier.

Using the different signature levels as metadata for certification
network analysis would only produce meaningful results, if all would
have agreed upon the same meaning for these different levels - which is
not the case.

>  The
> ambiguous, just that they are defined on a per-context / per-CA basis
Which again is the Policy URL, but then you don't need different levels
of user sigs (at least not all of them), just do something like:
http://me.com/pgp-policy?keyfp=<the key's fingerprint> and you can give
back per signature policy information.

Cheers,
Chris.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Mar 2015 14:00:24 -0400 (EDT)

> this is the only way for analysis to find out what the certification

What happens when the policy listed at the policy URL changes?  It seems
that a local resource would be needed.

-Ben Kaduk

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 19 Mar 2015 19:10:50 +0100

> that a local resource would be needed.
Well first, the different signature levels (if they rely on a policy
document, which they effectively do due to their vague definition)
wouldn't help you in such case either.

Second, it's IMHO in the responsibility of the signer to keep the old
policies available, of course it wouldn't be enough for the URL to just
contain the key ID... (it would need at least the valid from / through
dates and probably more values like signing key finger print and more...
or even better a hash on the signature packet).

Cheers,
Chris

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Mar 2015 18:43:59 -0400 (EDT)

> wouldn't help you in such case either.

I wasn't trying to say that the existing technology is better than your
proposal, just that your proposal needs to take this concern into account.

> or even better a hash on the signature packet).

Sure, it's their responsibility.  But some signers are going to fail to
adhere to it, and the client trying to use such a signature needs to know
how to behave in that case.

-Ben

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Mar 2015 19:14:01 -0400

As a branding issue, I would pick the name PGP/MIME for the working group
and make the focus decrufting legacy bits of PGP and making a MIME based
scheme the new common denominator for framing.

If there was also a clearly defined strategy for interop with S/MIME
credentials then such a specification could be positioned as the future
upgrade path for OpenPGP and S/MIME.

Since an S/MIME credential can be turned into a fingerprint pretty easily
and the fingerprints are what people actually use in practice to exchange
OpenPGP mail. This is not exactly a major problem.

(Yes I know that there is a PGP/MIME mode at the moment. but that isn't the
point).

Think of it as embrace and extend...

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 20 Mar 2015 13:46:47 +0000

MIME is fine for PGP over email, but do keep in mind that PGP is not
strictly used in email and using MIME is not necessarily helpful and is
possibly needlessly complicated in some of the other use cases (just
encrypting personal files and data at rest, for example).

And if we are going to start talking about "PGP/MIME", then I think
revising RFC-3156 should be part of the discussion at some point. As it is
stands today, it is impossible to craft a proper "PGP/MIME" message unless
your mail client directly supports 3156.  It requires special SMTP headers
that are usually set by the mail client and over which the user has no
control (and don't get me started on that extra "version 1" MIME
section...).

-Wyllys

On Thu, Mar 19, 2015 at 7:14 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> (Yes I know that there is a PGP/MIME mode at the moment. but that isn't
> the point).
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Mar 2015 10:24:11 -0400

> encrypting personal files and data at rest, for example).

Absolutely. Which is why PGP should be properly layered and abstracted
so that all the mail specific parts are in 'MIME' and all the
encryption parts are in the 'PGP' bit.

> And if we are going to start talking about "PGP/MIME", then I think revising
> RFC-3156 should be part of the discussion at some point. As it is stands
> today, it is impossible to craft a proper "PGP/MIME" message unless your
> mail client directly supports 3156.  It requires special SMTP headers that
> are usually set by the mail client and over which the user has no control
> (and don't get me started on that extra "version 1" MIME section...).

Absolutely.

The stalemate has to end at some point. PGP does its own thing in too
many places. What we have is a description of a product rather than a
multi-vendor standard.

Winning means that everyone gets access to email encryption with full
control of their trust environment.

Tonight there are two crypto parties in my neighborhood where people
will be taught how to use PGP. This is really good and really sad. The
good part is that it shows that people are really interested in
getting crypto. The sad part is that the tools we have today require
user education. Teaching people how to use vim/PGP to send and receive
secure mail is actually a sign that we are doing something wrong.

Every browser comes with TLS built in and everyone uses it at least
some of the time. Every email client comes with an email encryption
solution but almost nobody uses it.

---

From: ianG <[email-masked]>
Date: Tue, 24 Mar 2015 01:31:29 +0000

>    whether to completely overhaul or even re-design it.

Re-design.  It's still the late 1980s model, it's way behind current 
knowledge. No point in overhaul.

> In the later case:
> - The basic meshed web of trust must obviously be retained,

:) I would agree that it should remain firmly oriented towards the p2p 
channel.

> but apart

The ultra paranoid can go off and do their own thing anyway.  Let them 
compose their fantasies in their own code, no need to clutter up our own 
code with "made up algorithms".

>    keep it easily up to crypto developments

Nah - just use Keccak and tie it to the current new version 5.  Frankly 
we've had 2 decades of peace with the SHA 1 -> 2 -> 3 family.  Worring 
about the hashes failing is sooooo overdone.

...
>    says that this is just "by convention", it doesn't even use SHOULD or

That's how I like it.  And in CAcert we came to the same conclusion - 
the NAME that is authenticated by the user is a single string, it is up 
to the humans to add any semantics on what that name is / means.
...

>    packet...

In CAcert we concluded that there should just be multiple UIDs.  No 
particular semantics like Attribute implied.

>    divorce and it changes again. Or one grows older and the image

Hmmm... this might be overthinking things.

> which subkey I use,... I do this with all my identities, right?

Now you're talking about a heirarchy.  Typically what people do is 
create a key "Iang Signing Key" and another "Iang Contract key" signed 
by the first, and then use the latter only for contract signing.

What's useful is to deliver tools that can be composed by the user, less 
so to get all the composition possibilities into one single structure.

just some comments!

iang

---

From: ianG <[email-masked]>
Date: Tue, 24 Mar 2015 01:48:30 +0000

Late comments!

>   - The use of SHA-1 needs to be replaced.

SHA3.

>   - A v5 key format.  Prepare for forthcoming public key algorithms.

Completely.

>   - A new encryption mode to replace our aging CFB+SHA1 method with a

Wait for CAESAR, 2017.  It'll take that long anyway.

> Is there any interest in this?

I'm theoretically interested.  But I think it is time to try another 
paradigm.

4880 took a decade.  Too long, the OODA loop was bigger than the 
evolving knowledge, the work-by-committee approach was broken.  Many of 
us died, emotionally.

I'd say:

   * designate key persons to design the elements.  Stick with what they 
choose.  Argue it a bit, but if we can't shift them, then go with it.

   * Less.  Algs, hashes, formats, protocols, bit saving, etc.

   * More.  We need to look up into the stack of apps and see what is 
needed.  Those apps didn't exist when PGP was designed.  We are in a new 
world now.  No point in designing for command line.

   * Trust <cof> model.  It's got to be completely overhauled.  Not so 
much as to change the internals, but to make sure that future uses can 
be composed with the new design.

   * Vendors.  Ain't nothing gonna happen unless you get them on side. 
By them, I mean the big ones.

   * project planning.  Let's not treat this as a committee, let's set 
up some coding projects to actually move the game forward.  Like, a C 
team, a Java team, PHP, what else?  Mandate:  to track the draft, 
compat, and push for more speed from the designers.

> How can we get the WG out of the concluded state?

As long as they don't turn off the list, do we care? ;-)

> Who would volunteer as Chair?

Hell's bells, no, can't afford it.

iang

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 24 Mar 2015 04:46:19 +0100

> >   - The use of SHA-1 needs to be replaced.
+1

> choose.  Argue it a bit, but if we can't shift them, then go with it.
Isn't that the NIST model which kinda blew up?
Any process should be open, fully transparent and even though it's
likely that there will be a number of key people doing a big deal of
work, those shouldn't be designated and any others be more or less
locked out.

>    * Less.  Algs, hashes, formats, protocols, bit saving, etc.
Well I guess my opinion on that is clear :)

> world now.  No point in designing for command line.
+1, at least as long as we don't prioritise one use case over the other
and we still have many people/fields where the perfectly mutually
authenticated integrity/encryption is desired.

> By them, I mean the big ones.
I'd rather consider that problematic.
Typically the main interest of any company is not necessarily the
general good but rather making money.
And we know of far to many cases in the past were companies or other big
players (e.g. standardisation bodies) intentionally weakened crypto
systems.
Just take the whole GSM development and weak keys... even though this
was motivated by the government agencies, the vendors all knew what they
were agreeing to.

> compat, and push for more speed from the designers.
Sounds compelling, especially when looking at the back and forth that
the CFRG saw recently ;)
But not at the expense of flexibility, and the things should be finished
when it's finished - not when the date is due. 

Cheers,
Chris.

---

From: Werner Koch <[email-masked]>
Date: Tue, 24 Mar 2015 08:47:35 +0100

>>   - The use of SHA-1 needs to be replaced.

That was the original plan.  However it turned out that the still not
finalized SHA-3 is meanwhile considered a fallback option in case of new
developments.  SHA-2 has wide support and is already in wide use.  We
only need a new fingerprint style and use that for some designated
revokers etc.

> Wait for CAESAR, 2017.  It'll take that long anyway.

I am more thinking of OCB; there is a free patent grant for all relevant
parties and the patent will anyway expire by the time a new encryption
format will get in widespread use.

> 4880 took a decade.  Too long, the OODA loop was bigger than the

Nope.  4880 is a minor update of 2440 which barely took a year to be
released with code ready 6 months earlier.  The major new features in
4880 have been enabled since fall 2000 (MDC packets)

> As long as they don't turn off the list, do we care? ;-)

May I read this and your other remarks that you see no more value in the
IETF process?

Salam-Shalom,

   Werner

---

From: ianG <[email-masked]>
Date: Wed, 25 Mar 2015 23:27:17 +0000

> only need a new fingerprint style and use that for some designated

SHA3 because it has sponge, it can do MACs, it can do stream ciphers, it 
can do authenticated stream ciphers, it can brew the morning tea if you 
plug it in the right way.

(Yeah, I know NIST said it's in fallback mode, but when the thing 
actually comes out, I think it will be a game changer.  Sponge changes 
everything.)

> format will get in widespread use.

See, this is where the cryptographers and the cryptoplumbers have sort 
of moved on.  Instead of us arguing about what mode to use, we've thrown 
it back over the wall, and shouted out to them lot on the other side 
(cryptographers) stop with the silly modes!  Give us one stream cipher 
that does *the lot* and let us get back to real coding...

That's CAESAR.  It will replace all the modes, all the algs, all the 
everything in the entire symmetric space.  And make your tea ;)  Hence I 
think waiting until it comes out and picking up its good work is worthwhile.

(and, ps; Keccak has been submitted, it'll make your tea and your coffee 
too!)

> May I read this and your other remarks that you see no more value in the

I'm an acknowledged skeptic of the IETF process... maybe need to send 
that memo out again?

Here's my big criticism of the IETF process:  like all processes it 
eventually ends up becoming a place for people to create silos of 
knowledge and careers, and eventually divorces itself from what's 
happening out there in the real world.  But it holds the keys to some 
powerful Internet protocol components, and while it's not bringing in 
the new, outside knowledge, the IETF WG becomes the blockage, the inner 
sanctum, the guilds that the IETF swore to bring down.

So what do we do?  Leave?  Stay?  Fight?

iang

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Fri, 27 Mar 2015 01:13:56 +0100

+1

> So what do we do?  Leave?  Stay?  Fight?
So do you have any better proposal idea?

Anything more governmental (ISO, national standardisation bodies) or
more commercial (ECMA) would IMHO be quite bad (since they're all known
to be rather on the dark side of the force, and while they may have
cookies, it's probably not what we should want).

Not much is left the in the free/community world.... W3? Far too much in
committee mode either, far to easily influenced by big players (see the
whole HTML5 DRM stuff).

Doing it independently... doesn't seem appealing either.

I'd say IETF is quite the right place.

Cheers,
Chris.