Subject: Re: [openpgp] OpenPGPv5 wish list

From: Philippe Cerfon <[email-masked]>
Date: Mon, 29 Apr 2013 19:53:40 +0200

Moving over to [email-masked] from gnupg-devel.

On Mon, Apr 29, 2013 at 1:52 PM, Werner Koch <[email-masked]> wrote:
> I don't want the whole X.509 mess introduced in a protocol we tried to
> keep clean for real use.
Well actually the contrary seems to be the case... OpenPGP is rather
only used for mail and plain file encryption/signing, which covers of
course already many fields, but nothing advanced.
It would never have any chance to be used for government ID cards, or
similar projects.

> Please read 5.11:
...
> There is nothing which enforces how you represet the name, you may put
> arbitrary data into the UID.  However, it is common to use a mail
> address and thus GnuPG (by default) checks for that.
Yeah I knew... but right now it's also used for the name of the user,
which is the primary identification property... and it shouldn't be
used for that (from a design POV).

> Why should we change somthing which has not shown problems in the
> past.  If you want X.509, use X.509 for example with gpgsm.
Obviously I don't want X.509 or I'd use it.
And I don't see how this is touched by X.509 anyway.
Of course there showed never problems up with the critical flag,
simply as no-one uses it... yeah I know, gpg understands it... but one
cannot even set it, can one?

On Mon, Apr 29, 2013 at 4:37 AM, Hauke Laging
<[email-masked]> wrote:
>> 1) much more property fields that describe the key holder
> That's easy as it can be done with notations; no need to change the protocol.
Well technically,... but there need such common notification to be
defined, for all these properties, which is the important part here.

> 1) How secure is the key?
> 2) What is the key used for?
> 3) How was the identity checked when certifying, how the email address and how
> the comment?
Absolutely agreed... especially in a machine understandable way.

> 4) What statement does this signature make?
That could be done via policy sig subpackets... even though this is
not exactly defined right now.

> You should not be forced to sign a UID as a whole.
In principle yes... it’s handy though to have a unique identifier
(which is not the fingerprint) on keys... whether this needs to be
signed by other users or just by the key itself is another question.

> 1) For compatibility with the signature laws: We really need the option to
> extend certifications from UIDs to subkeys. That way you could have a "normal"
> key and a CA could be sure that a certain subkey is on a smartcard only.
>
> 2) Officially supported offline main keys. Currently just a GnuPG extension.
> IMHO the most important feature with respect to security (for everyday usage
> keys).
+1

> 3) Double-digest signatures and double-cipher encryption in case one gets
> broken.
Absolutely agreed, though it would be even better to allow arbitrary
number of such.
Maybe one could even think of doing the same with differen crypto
systems (i.e. one that was not vulnerable to Shore ;) )

> 4) Signature weight: Limit the signing power of a key (to 1/n) so that
> signatures of n different keys are enforced for paranoid applications.
+1

> 5) Seperate header files for encryption. We have detached signatures. Today
> you have to rewrite a huge encrypted file if you want to add (or remove)
> recipients.
Not so sure about this... to me the rationale behind the detached sigs
is rather that you can keep the signed-only file in clean text.
The encrpyted file is unreadable anyway, so you can also include the
session key in it... and that you can re-encrypt quite fast at a later
point for different users.

On Mon, Apr 29, 2013 at 7:17 AM, Robert J. Hansen <[email-masked]> wrote:
> I'll make my own wish list simple:
>
> I don't want *anything* new included in the standard unless there exists
> at least one user who says, "the absence of this feature is a
> showstopper for me and is blocking my adoption of GnuPG."  This user
> needs to be able to show a real-world use case and be willing to
> volunteer to run trials in a real-world environment.
>
> No real-world user?  No feature.
Well that's kinda stupid as it boils down to the hen egg problem, ain't it?
Especially that OpenPGP looses ground in most areas (unless perhaps
OpenSource) against X.509 should already show, that there are many
showstoppers.

Cheers,
Phil.

---

From: Werner Koch <[email-masked]>
Date: Mon, 29 Apr 2013 20:40:17 +0200

> course already many fields, but nothing advanced.

Depends on what you call advanced.  OpenPGP is a low-level protocol and
never really tried to address the application layer. 

> It would never have any chance to be used for government ID cards, or

Why should a government do that?  eID cards started in Europe (iirc, the
German electronic signature law was the first at all).  Europe has a
history of waiting for X, aehmm the OSI network stack, and thus it is
quite obvious that they started with X.400 et al.  Further, you can make
more (consulting) money with weakly defined/complex protocols than with
a clean solution.  The latter almost never wins (cf. IPSec lessons).

> used for that (from a design POV).

Maybe not for your application, so go and use your own thing for it.
There is nothing which will stop you.  What about putting a DN into it?

> And I don't see how this is touched by X.509 anyway.

Because X.509 has all the useless bells and whistles which have been
suggested in the past as the solution to every problem.  Well alright,
OpenPGP provides very similar ways to implement such features but
fortunately it has not yet been abused

> cannot even set it, can one?

  gpg -N [email-masked]=42' ....

makes foo a critical notation.

Shalom-Salam,

   Werner

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

---

From: Philippe Cerfon <[email-masked]>
Date: Tue, 30 Apr 2013 01:08:44 +0200

> never really tried to address the application layer.
Well I think what has been proposed here now all belongs to the lowest
layer, it’s just cleaning up that one and making it more general.
Especially the proposals by Hauke seem to be just what the key
management system should be responsible for and which OpenPGP
currently cannot really fulful. Like that I have several subkeys where
one is explicitly marked as "not so safe" because I use it e.g. on my
Android phone... and where clients have a machine readable way to warn
me about data signed by such keys.

Also my proposals for having more (standardised) descriptive fileds
(name, address, IM, colour of eyes, employee) seems to be quite
crucial to me.
Right now people put such distinguising information often as comment
into their UID, but that kinda sucks (and it kinda violates the email
RFCs, which tell that any client interpreting mail addresses must
ignore the comments).

Or I'd like to be able to also include IM addresses in the keys, so
that such clients could use this information to select the right key,
which is expected on received messages.

> quite obvious that they started with X.400 et al.
Well I know,.. but now we give them even reason.

> Further, you can make

> There is nothing which will stop you.  What about putting a DN into it?
Well of course I can always do whatever I want... but isn't the whole
idea of a standard that everyone should follow it as far as possible?
Clearly I can put a semicolon separated list of address, jabber
account, date of birth, name and email address into the UID,... but
everyone will think I'm crazy.

> fortunately it has not yet been abused
Well but X.509 simply sucks for it's trust model ;-)

> makes foo a critical notation.
And there's a similar syntax for the other signature subpacktes? The
dates? The policy sig subpacket? Key usage? etc.?

Cheers!