Subject: [openpgp] details of 4880bis work

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Apr 2015 12:38:09 +0100

Hiya, here's the 2nd thread, starting from DKG's list. Please
discuss... (We don't need +1's for this, just tweaks, corrections,
additions etc.) If someone wanted to put this on github or
somewhere else the group can edit it, that'd also be fine.

Ta,
S.

a) update the fingerprint format (avoid inclusion of creation date, use
   stronger digest algorithm; i'm dubious about embedding algorithm
   agility in the fingerprint itself, but explicit version info in the
   fingerprint might be reasonable so we don't have to keep guessing by
   fpr structure for future versions)

b) get rid of keyids entirely -- when referring to a key, use the
   fingerprint where a compact hint is needed (e.g. in a replacement of
   the issuer subpacket) or the full primary key where it is more
   sensitive (e.g. in designated revoker).  With EC keys, we could
   consider using the full key (not the full cert) even in the issuer
   subpacket case, which could make things cleaner.

c) deprecate MD5, SHA1, and RIPEMD160

d) clarify that cleartext signatures should all use charset/encoding
   UTF-8.

e) update S2K with something more modern (PBKDF2, HKDF, scrypt?),
   deprecate all the other mechnanisms explicitly

f) standardize the two new curves coming out of the CFRG: 25519 and
   curve448 ("goldilocks") for both signatures and encryption (Werner
   has already started this process for 25519 signatures)

g) remove compression entirely

h) clean up the language: clearly distinguish between "public key" and
   "certificate", and ensure that the use of the terms "trust" and
   "validity", if still present, are used unambiguously.

i) declare a literal data packet type "m" that means "MIME content" so
   that we can punt on the rest of the message
   structure/format/encoding/type craziness to MIME.

j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can
   get away with.

k) provide a modern streamable/chunkable AEAD replacement for
   Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets

l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD
   mechanism should be the baseline.

---

From: Werner Koch <[email-masked]>
Date: Fri, 10 Apr 2015 14:19:46 +0200

> somewhere else the group can edit it, that'd also be fine.

I you don't mind you may use the GnuPG wiki

  https://wiki.gnupg.org/rfc4880bis

However, you need an account from bugs.gnupg.org as an anti-spam
measure.

Salam-Shalom,

   Werner

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

---

From: Werner Koch <[email-masked]>
Date: Fri, 10 Apr 2015 14:39:59 +0200

Hi,

>    deprecate all the other mechnanisms explicitly

I agree that all options except for iterated+salted should be removed
and if we settle for a new MUST hash algorithm that one should als be a
MUST for S2K.

We may also dicuss whether the float encoded COUNT could be updated with
something simpler.  This is related to a other packet length header
fields.

Why do you think that the S2K thing is worse than PBKDF2?  Is there any
paper comparing these two KDFs?

We have two use cases for KDFs: 

 a) Protection of the secret key.  This is important most mostly a local
    issue.  Sending secret keys over the the wire requires a lot of
    precautions anyway and thus I think there is no need to put strin
    extra protection into it.  It is better to convey secret keys using
    another secure method.

 b) Symmetric-Key Encrypted Session Key Packets.  I don't know how often
    this is used.  I assume that in most use cases the passphrase is
    taken from external key management system and thus we can expect
    that it has full entropy and the KDF does not add to the security.

Shalom-Salam,

   Werner

---

From: ianG <[email-masked]>
Date: Fri, 10 Apr 2015 16:19:21 +0100

Some thoughts, none really need answering.

>     fpr structure for future versions)

In the past, where I've had a very occasional need to indicate 
version/alg in fingerprint like material, and full tagging wasn't 
justified, I've used the length to do that.  E.g., 16 bytes was MD5, 18 
was NAH, 20 was SHA1.  Clunky, but it served.  Just a thought.

> d) clarify that cleartext signatures should all use charset/encoding

Are calculated over cleartext UTF-8 plaintext document as the default?  OK.

(Not, the cleartext sigs are now to be delivered in UTF-8, or, the 
cleartext sigs will be parsable unchanged and therefore compatible with 
both US-ASCII and UTF-8.)

>     has already started this process for 25519 signatures)

Why two curves?  Is this just the algorithm agility discussion or is 
there an actual difference between them?  Why not just use the stronger 
one and be done with it?

(Not wishing to start the algorithm agility debate, I'm sure everyone's 
familiar with the basics there, just wondering if there is any other 
motivation.)

>     "validity", if still present, are used unambiguously.

It would be nice if we could eliminate the term "trust" altogether.

Humans trust, software agents cannot.  Calling some bit a "trust bit" is 
therefore almost guaranteed to become ambiguous, and the resultant 
self-deception is one of the root causes of PKI failure in both x.509 
and pgp circles.

In "theory" we might be better off replacing it with "policy" which is a 
word that clearly indicates there should be some wider document that 
describes what the bit is trying to record.

In the alternate, if we don't like the word "policy" perhaps "claim" or 
"statement" or even "relationship graph link" or "edge" or...

>     mechanism should be the baseline.

No RSA?  Is there consensus amongst devs that enough of us aren't going 
to implement RSA anyway?  We're ready to make a clean break, and 
actually mitigate against it?

(I'm happy to join the witch-burning party, but it's had such long legs, 
it saw off the DSA challenger even tho many tried to kill it.)

iang

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Apr 2015 15:57:19 -0400 (EDT)

>     that it has full entropy and the KDF does not add to the security.

I have used gpg -c to password-encrypt data with a human-generated (i.e.,
not-great) password fairly recently, as a single anecdote.

-Ben

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Fri, 10 Apr 2015 23:51:49 +0200

On Fri, 2015-04-10 at 12:38 +0100, Stephen Farrell wrote: 
> a) update the fingerprint format (avoid inclusion of creation date
I wouldn't do that,... actually I think creating/expiration times (and
some other base properties) of a key should be immutable.

>    has already started this process for 25519 signatures)
I haven't followed CFRG the last weeks,... are the plans for anything
at/beyond the 512 level dead?

>    structure/format/encoding/type craziness to MIME.
For what exactly do we need this? Maybe I just don't understand what you
plan, but we should try to be as independent from other layers as
possible.

>    mechanism should be the baseline.
Keccack?

Everything else seems good to me.

Cheers,
Chris.

---

From: Nils Durner <[email-masked]>
Date: Sat, 11 Apr 2015 21:17:21 +0200

Hi,

> e) update S2K with something more modern (PBKDF2, HKDF, scrypt?),

My understanding is that the HKDF authors recommend against using HKDF
as a PBKDF. From RFC 5869[0]:
> In the case of password-based KDFs, a main goal is
> to slow down dictionary attacks using two ingredients: a salt value,
> and the intentional slowing of the key derivation computation.  HKDF
> naturally accommodates the use of salt; however, a slowing down
> mechanism is not part of this specification.  Applications interested
> in a password-based KDF should consider whether, for example, [PKCS5]
> meets their needs better than HKDF.

scrypt, on the other hand, exhibits collisions with long input values -
something that yescrypt addresses[1].

I think it is worthwhile to wait for the Password Hashing Competition[2]
to conclude in Q2 this year before considering more modern S2K alternatives.

Regards,

Nils

[0] https://tools.ietf.org/html/rfc5869, section 4, paragraph 2

[1]
http://www.openwall.com/presentations/PHDays2014-Yescrypt/mgp00009.html,
last point

[2] https://password-hashing.net/

---

From: Tom Ritter <[email-masked]>
Date: Sun, 12 Apr 2015 08:27:43 -0500

> somewhere else the group can edit it, that'd also be fine.

I would suggest adding the following:

m) Update the allowable OpenPGP Message types in 11.3.  "Encrypted
Data" should not be considered a valid OpenPGP message and has been
deprecated, I think, since 1991.

n) Deprecate (remove?) older packet types and versions that should not
be used anymore. I think I would want to completely remove most of the
language here, but OpenPGP is a different beast from TLS, so some of
it should stay because while we may specify someone SHOULD NOT or MUST
NOT use it, it will be important for actually inter-operating with
vastly deployed install bases. But it seems like we could at least
enumerate all of the SHOULD NOT/MUST NOTs and evaluate them on a
case-by-case for removal.

-tom

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Apr 2015 15:17:44 +0100

Hiya,

Just on one point, and apologies in advance to those for whom
this is repetitive, but I guess not everyone here is on the
CFRG list...

> at/beyond the 512 level dead?

CFRG have reached consensus on the "goldilocks" curve which has
a 448-bit prime as it's higher work-factor curve (448 presumably
meaning a work factor of about 2^224). That's in addition to
curve25519 which has work factor ~2^128.

I don't believe there is likely to be an even higher work-factor
curve documented by CFRG as part of its current phase of work as
they are focused on meeting the immediate needs of TLS and other
IETF WGs (and W3C) at present, and they have a bunch of work to
do to specify, and get consensus on, a signatures scheme for the
two curves they've so far selected.

A number of people also made the argument that if a curve with
work factor ~2^224 is ever busted then it'd not be at all a
surprise if whatever approach worked for that also worked just
fine for a work-factor 2^256 curve. In other words, that there's
no really good reason to want a curve based on a 512 bit prime
if one has goldilocks.

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 12 Apr 2015 23:38:47 -0400 (EDT)

> case-by-case for removal.

What we're considering (if we go ahead with the deprecation) over in
kitten is to move the deprecated content to an appendix with a note that
it should only be provided for compatibility with older versions, if at
all.

-Ben

---

From: Stephen Paul Weber <[email-masked]>
Date: Wed, 15 Apr 2015 08:38:18 -0500

>g) remove compression entirely

Is the idea that compression can be handled by another format (xz, probably) 
and from the OpenPGP perspective it's just "binary"?  I guess there's not 
much downside here when the content was going to be binary anyway, but for 
text content it means you need something beyond just an OpenPGP 
implementation to extract the text (if it is going to be compressed).

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

---

From: Werner Koch <[email-masked]>
Date: Wed, 15 Apr 2015 19:48:50 +0200

On Wed, 15 Apr 2015 15:38, [email-masked] said:
> Is the idea that compression can be handled by another format (xz,
> probably) and from the OpenPGP perspective it's just "binary"?  I

I guess so.

However I see a problem with the removal of compression: Almost all keys
have preferences for compression and most messages are using
compression.  Thus all implementations will need to keep on supporting
de-compression which is actually the more complicated part.

Shalom-Salam,

   Werner

---

From: Wyllys Ingersoll <[email-masked]>
Date: Wed, 15 Apr 2015 18:28:13 +0000

Can someone explain the reasoning behind deprecating compression ?  Im
neutral on the idea, just trying to understand the benefits of getting rid
of it beyond simplifying the processing of the packets.

On Wed, Apr 15, 2015 at 1:51 PM Werner Koch <[email-masked]> wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Apr 2015 14:42:52 -0400

Compression provides an oracle for the plaintext

Sent from my difference engine

> On Apr 15, 2015, at 14:28, Wyllys Ingersoll <[email-masked]> wrote:
> 
> 
> Can someone explain the reasoning behind deprecating compression ?  Im neutral on the idea, just trying to understand the benefits of getting rid of it beyond simplifying the processing of the packets.
> 
> 
> 
>

---

From: Jon Callas <[email-masked]>
Date: Wed, 15 Apr 2015 14:01:18 -0700

>   fpr structure for future versions)

There's a separate thread on the structure -- I replied to it myself.

There was also a mention somewhere of removing the timestamp from the fingerprint, and that's what I really want to comment on.

When 2440 started, removing the timestamp was one of the things I wanted to do. However, it's not such a bad thing. If you make a fingerprint merely be a function of the key (it has no variable data), then you lose the ability to alias the key, which is actually useful.

Presently, Alice can use the same key material for "[email-masked]" and "[email-masked]" and it's not obvious that it's the same key from the fingerprint. If the fingerprint algorithm forces them to be the same fingerprint, there's an unnecessary information leak. An attacker learns they can attack Alice by attacking Info.

The fingerprint is an analogue of the serial number in X.509. It's desirable to be able to reuse keys in whatever PKI you use. It gives some people heartburn, but it's done all the time for practical reasons.

If we get rid of the timestamp, there ought to be something like salt put in in its place. "Randomized Hashing" is not a bad thing.

>   subpacket case, which could make things cleaner.

There's no *need* to do that.

An implementation must (not MUST, but an actual must) consider that there will be a collision and handle it appropriately. Remarkably few of them do, but this is a bug.

> c) deprecate MD5, SHA1, and RIPEMD160

No argument there. I will observe along with Shamir's observation that there are no first or second-preimage collisions in SHA1. Some SHA1 uses (like fingerprint calculation) are still secure.

MD5 was deprecated in 2440; it is *only* there for backwards-compatibility with RFC 1991, and that grudgingly. 4880 actively spits on MD5.

Deprecating SHA1 is something that can be an actual deprecation -- saying "please don't do that" rather than banning it.

Nonetheless, as I said in the fingerprint discussion, there are places where you can design the expression of it that mean it never has to be redesigned again. Why should we go through this all over again for SHA-4, instead of just letting people put in a new algorithm ID?

> d) clarify that cleartext signatures should all use charset/encoding

That's basically there now. There's some weasel-wording because of people who still wanted to use Shift JIS and other character sets, but that's there now. Section 3.4.

(By the way, in PGP, we started off with a dictatorial view that everything was UTF-8, and ended up having to deal with the edge condition of Shift JIS etc.) 

The WG can sweep this under the rug, but implementers will still have a problem. I suggest in the name of practicality, keep it mostly the way it is. You really need to have a shallow bow to Japan and the rest of us will all use Unicode, just like another shallow bow is needed in the form of Camellia.

>   deprecate all the other mechnanisms explicitly

Agree completely on just using PBKDF2.

You could put other more modern password grinders in, or even leave it open for new technologies to be introduced easily.

>   has already started this process for 25519 signatures)

I have no problem putting in parameters for those, but similarly to the hash issue, the EC Curve issue is not settled. There's a NIST conference in June, and personally I expect my favorite curve, 41417, to get widely used because it's both really fast and secure as well as not overly large (I think 521 is overly large).

> g) remove compression entirely

That would be a huge relief. Or at the very least just say SHOULD NOT on it. 

>   "validity", if still present, are used unambiguously.

This would be good, but it touches upon a political third rail here. That problem really needs to be cleaned up.

When 2440 started, there was an agreement with the Security Area that OpenPGP would not be a "PKI" (whatever the heck that means), because there was already a PKI, namely PKIX.

That means that OpenPGP has these language issues. It has to be a public key infrastructure without being a PKI. That's the reason why there's no trust model, while having the atomic components needed to have infrastructure, should one want to do that.

There are a number of things that really need to have documents, either on their own or sections in some document. They include:

* Trust model(s)
* Key/certificate servers
* Key/certificate transport (yes, they're different)

But that deserves its own topic.

The bottom line is that you can't talk about trust/validity issue without admitting that it's a public key instrstructure. I believe that you can personally solve this problem merely by saying, "yeah, whatever" but that's the underlying unspoken issue that the previous working group was *forbidden* from solving that problem.

On the key/certificate language issue, the term "Key" as we use it comes from Whit Diffie. It's a brilliant bit of wordsmithing because everyone knows what a key is, but no one knows what a certificate is, let alone the difference between a certificate and a certification. The problem with an "OpenPGP Key" is that it contains at least one key, and almost always at least two keys. So one is stuck having to know the difference between a Key and a key -- or an OpenPGP Key and a public key. Capitalization is not the answer. 

There were a few places where it really, really made sense to use the word "certificate." That word occurs only in eight places in 4880. The important one is section 5.5.1.1 that says (in toto):

   A Public-Key packet starts a series of packets that forms an OpenPGP
   key (sometimes called an OpenPGP certificate).

That sentence contains in it much of the No PKI issue. We couldn't go the other way around -- we couldn't say that an OpenPGP certificate was sometimes called an OpenPGP key because if we had certificates, that meant we were a PKI. Also, the OpenPGP community really likes the term "Key" because it's a great word, and no one actually wanted to retire "key" for certificate anyway.

Nonetheless, we couldn't say up front early in the document that there's going to be a couple of places where your head will hurt less if we just say "certificate" so we're going to do that. We had to bury it in 5.5.1.1. if you take that line as a definition -- "OpenPGP key" and "certificate" are synonyms, then there's no problem.

If the new WG wants to get rid of "certificate" there's only eight places. 

>   structure/format/encoding/type craziness to MIME.

Better yet -- just say it's binary only. Get rid of all that FTP and other pre-ASCII baggage for good.

Making an "m" data type is really only a bandaid, and long-term makes the underlying problem (that we're making semantic choices in the wrong layer) worse.

I think it's far more important to toss out all that crap with canonicalization and what it means and all than to make it worse with a new data type. Bits. It's all just bits, collected into bytes. Excuse me, octets.

> j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can

No problem.

>   mechanism should be the baseline.

Well, obviously some of has to be done, since the MTI is 3DES, SHA1.

However, making ECC be MTI is something that ought to have discussion. (I'm in favor of it, but I know otherwise-sane people who have reasonable objections.)

	Jon

---

From: Jon Callas <[email-masked]>
Date: Wed, 15 Apr 2015 14:07:25 -0700

> de-compression which is actually the more complicated part.

Here's what I would do (and have done):

Whenever someone makes a key, you throw in the preference that says no compression. You then either get hissy when someone ignores the preference (and thus breaks protocol) or implement the decompress side.

From an engineering aspect, you then don't do compression and declare it to be an error if someone breaks protocol, knowing that six months later, you'll have time to throw in the decompress bits.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Wed, 15 Apr 2015 14:08:45 -0700

> On Apr 15, 2015, at 11:28 AM, Wyllys Ingersoll <[email-masked]> wrote:
> 
> 

Yes. That is the reason.

Someone could wave their hand at you and give a security reason, but it's just a handwave. The reality is that it is *better* to have a simpler processing path than smaller messages.

	Jon

---

From: ianG <[email-masked]>
Date: Wed, 15 Apr 2015 22:41:17 +0100

> When 2440 started, there was an agreement with the Security Area that OpenPGP would not be a "PKI" (whatever the heck that means), because there was already a PKI, namely PKIX.

:-o

I don't suppose it would have made much difference to us in OpenPGP, but 
it's nice to know how deep the rot ran at IETF.

iang

---

From: Bill Frantz <[email-masked]>
Date: Wed, 15 Apr 2015 15:09:39 -0700

On 4/15/15 at 2:08 PM, [email-masked] (Jon Callas) wrote:

>Someone could wave their hand at you and give a security 
>reason, but it's just a handwave. The reality is that it is 
>*better* to have a simpler processing path than smaller messages.

Phil said, "Compression provides an oracle for the plaintext". 
This attack works on TLS when used by web pages. AFAIK, it 
requires that the attacker be able to control some data being 
compressed which is compressed before the data he is trying to 
steal. I think it also requires multiple attacks.

While I don't know any PGP use cases that match these 
requirements, I don't think any of us know all the use cases, 
present and future. If the application/user wants to compress, 
it is straight forward to implement outside PGP, and not having 
compression simplifies the code (in the long term), and avoids 
what is at least a theoretical attack.

CHeers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, 
CA 95032

---

From: Jon Callas <[email-masked]>
Date: Wed, 15 Apr 2015 15:46:51 -0700

> I don't suppose it would have made much difference to us in OpenPGP, but it's nice to know how deep the rot ran at IETF.

To be fair to the other side, it's just another axis of the choices are good vs. choices are bad debate.

It wasn't the only one -- the IPsec people thought that SSL should not exist. SSL thought SSH should not exist (telnet over ssl as an alternative).  IPsec hated the port forwarding in SSL. POP hated IMAP. I can go on. And those are the ones that survived. And everyone hated SPKI. :-)

But, for example, the "there can only be one" effect made it so that SSH was limited in what they do, and so on and so forth.

Schiller did us *huge* favors in letting us do what we did. He just had to walk a tightrope.

	Jon

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 16 Apr 2015 00:49:07 +0200

> Compression provides an oracle for the plaintext
Only when the attacker can do chosen plain text... and basically we
can't really prevent the user from manually doing compression (thereby
introducing the same oracle).

Nevertheless, unless there are real crypto advantages of using
compression (which I guess there are not), I agree that it's really time
to remove it from OpenPGP,... we're a crypto message standard - not a
compression standard.

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 16 Apr 2015 02:39:36 +0200

On Wed, 2015-04-15 at 14:01 -0700, Jon Callas wrote:
> There was also a mention somewhere of removing the timestamp from the
> fingerprint, and that's what I really want to comment on.
> When 2440 started, removing the timestamp was one of the things I
> wanted to do. However, it's not such a bad thing. If you make a
> fingerprint merely be a function of the key (it has no variable data),
> then you lose the ability to alias the key, which is actually useful.

I think the main problem with the valid from/through dates not being a
part of the fingerprint is the following:

A user may intentionally want to limit his key for security reasons,
e.g. he makes a 1024 bit and wants to make sure that no one is
using/trusting it after two years anymore.

AFAIU, if the dates are not part of the fingerprint this would also mean
that they could be changed any time with a new self sig (including at a
time when the key owner may deem the 1024 bit RSA already no longer
secure enough to be trusted).
Of course one can make a revocation cert, but an attacker could always
try a blocking attack at the keyserver level.

That's why I think, that creation and expiration times should be
immutable once the key has been created; at least not without
invalidating all signatures (i.e. those from other users).

And analogous example to the above can easily be made for the starting
time. If an attacker could re-sign a broken key to an earlier date
(without invalidating other signatures) he could also forge signatures
for the time before.

Does that sound reasonable?

Cheers,
Chris.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Apr 2015 02:36:53 +0000

ianG <[email-masked]> writes:
>>When 2440 started, there was an agreement with the Security Area that 
>>OpenPGP would not be a "PKI" (whatever the heck that means), because 
>>there was already a PKI, namely PKIX.
>

It went the other way as well.  When I proposed in PKIX allowing users to
manage their own certificates rather than having to go to a CA to get them
issued and replaced:

https://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt

the response from the PKIX chair was "we're not going to turn X.509 into 
PGP", and that was the end of it.

The response to a proposal to replace the totally nonfunctional CRL blacklist
approach used by X.509 with a whitelist mechanism was even worse, amounting
to near-hysteria in some cases when I tried to push the issue (I've got some
of the emails saved somewhere, some of them came just short of saying "burn 
the heretic!").

Peter.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 16 Apr 2015 00:25:53 -0400

On Wed 2015-04-15 17:08:45 -0400, Jon Callas wrote:
>> Can someone explain the reasoning behind deprecating compression ?
>> Im neutral on the idea, just trying to understand the benefits of
>> getting rid of it beyond simplifying the processing of the packets.
>
> Yes. That is the reason.
>
> Someone could wave their hand at you and give a security reason, but
> it's just a handwave. The reality is that it is *better* to have a
> simpler processing path than smaller messages.

Simplicity is key, for sure, because bugs can hide more easily in
complexity.  And some of those bugs are security issues.

The additional expressivity itself (complexity aside) can also present a
security concern, because the data structures can take on new and
surprising forms:

  http://mumble.net/~campbell/misc/pgp-quine/

  --dkg

---

From: Werner Koch <[email-masked]>
Date: Thu, 16 Apr 2015 10:02:32 +0200

> security concern, because the data structures can take on new and

But that is not different from

  cat plaintext | gzip | rfc4880bis-encrypt 

because the resulting data structures are similar.

Salam-Shalom,

   Werner

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 16 Apr 2015 10:32:18 +0200

I'd like to address two points:

Can someone explain why key usage and preference flags for the primary
were made part of user id signatures instead of a direct key signature
or something of the sort?  I felt like this added a lot of complexity
and non-determinism to those parts of the implementation which dealt
with that.

Secondly, (this came up somewhere else), I'm not convinced at all that
designated revokers (5.2.3.15) are a good idea. Is there a significant
advantage over just handing the person a revocation certificate of your
key? I remember deciding against implementing this feature at some point
in OpenKeychain because the complexity/benefit tradeoff just wasn't
there.

 - V

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Apr 2015 10:53:20 +0100

Peter,

> of the emails saved somewhere, some of them came just short of saying "burn 

I don't see how that's really relevant or constructive for the
discussion here. Re-visiting [x509|pgp|whatever]-bashing that may
have been done in the past isn't interesting for me anyway unless
there's some lesson to be learned and I don't see anything like
that above. There are other lists where we can all vent and that
are better venues for such.

S.

---

From: Werner Koch <[email-masked]>
Date: Thu, 16 Apr 2015 12:13:09 +0200

> were made part of user id signatures instead of a direct key signature

Note that you may put them into a direct key signature.

Assume you use the same key for home and work.  You have two user ids
but at home you use an implementation and preferences you like while at
work you have to comply with company policies and thus different
preferences.

Right, that is a bit artifical and for example gpg uses a direct key
signature or the latest user id to get the key flags and preferences.

> and non-determinism to those parts of the implementation which dealt

Remember that you anyway need to implement a policy on how to work with
multipe self-signatures on the same user id, or with multiple direct key
signatures.

> key? I remember deciding against implementing this feature at some point

That requires that you still have access to a pre-generated revocation
certificate and that that you are able to use it.  A dedicated revoker
certificate also allows to create a revocation certificate with a valid
reason code and not just a catch-all reason code.

Salam-Shalom,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Apr 2015 08:02:56 -0400

> using/trusting it after two years anymore.

That is an important requirement but putting the time info into the
fingerprint is not the only way to address it.

Operating PKIX, the lifetime of root keys and root certs is very
different. Rolling over a root with the same key is common. The
principal application of fingerprints is analogous to a root.

That said, if we hash <content-type> + <data> rather than just <data>,
there is no need to commit to a single approach now.

> invalidating all signatures (i.e. those from other users).

At that point we are authenticating a self signed cert, not just the
key and the dynamics are different.

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 16 Apr 2015 13:19:09 +0200

On 16 Apr 2015, Werner Koch wrote:
> Assume you use the same key for home and work.  You have two user
> ids but at home you use an implementation and preferences you like
> while at work you have to comply with company policies and thus
> different preferences.

The solution to this problem should be two keyrings.  Different
encryption settings per user id like this are completely out of scope
for everyone who isn't familiar with the inner workings of RFC4880.
Even assuming this was a useful feature, it is underspecified to a point
where trying to figure out what an other implementation meant by some
constellation of preferences in user ids or direct key signatures is
little more than guesswork.

> Remember that you anyway need to implement a policy on how to work
> with multipe self-signatures on the same user id, or with multiple
> direct key signatures.

Just like gpg, we use the latest signature.  Is there a reason this
isn't specified?  While I agree that the trust model should not be
specified, leaving this kind of thing open just leads to confusion,
unintended behavior which isn't even really a bug but just different
interpretations by different developers, and complexity in an attempt to
be compatible with de facto standards.

I remember several discussions about this kind of thing between me and
Dominik which went like "how's it specified?" - "it isn't." - "well,
just look at gpg's source and do what they do".

> A dedicated revoker certificate also allows to create a revocation
> certificate with a valid reason code and not just a catch-all reason
> code.

That's a valid reason.  It still means my import routine can't decide by
the data of a keyring whether it's revoked or not, but may need another
key lookup (and verification, ...) for it, reducing reliability of this
kind of recovation.

 - V

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 16 Apr 2015 14:58:17 +0200

> work you have to comply with company policies and thus different
This has however some problems, which I've mentioned already in my
initial wishlist.

- Nothing of this is really specified. One *may* interpret the standard
that it is as you say above.
- There is nothing specified that would resolve ambiguities (what if
there's both, direct-key signature and user id sig, setting the same
subpackets but with different properties)?

> signature or the latest user id to get the key flags and preferences.
From the standards PoV, the same problem as above... nothing really
specified what it means if e.g. flags are on a user sig or on a direct
key sig.
IMHO flags should anyway be immutable.

> multipe self-signatures on the same user id, or with multiple direct key
The standard didn't even specify that newer sigs would replaces older
ones, right?

IMO all quite fuzzy and vague... :(

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 16 Apr 2015 15:04:06 +0200

On Thu, 2015-04-16 at 13:19 +0200, Vincent Breitmoser wrote: 
> The solution to this problem should be two keyrings.
You probably mean two keys?

>   Different
I don't agree at all.
Actually we should make it finally usable that a person has only one
primary (and certifying/certified) key,... and many subkeys which are
usable for different use cases, which is right now practically
impossible.
And I think once it would be reasonably possible, it makes absolutely
sense to have e.g. different key prefs depending on the UID and/or
(role) subkey.

> it is underspecified to a point
Yes.

> specified, leaving this kind of thing open just leads to confusion
Yes.
IMO this vagueness may be even a security issue.

Cheers.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 16 Apr 2015 15:08:08 +0200

> fingerprint is not the only way to address it.
How else would you want to do it? If you don't also put it in the
fingerprint, than we could e.g. meet at a signing party, exchange our
FPs,... I forget to sign yours, but remember a year later. I still have
the fingerprint, but if that would stay the same, even though other
dates have been set, I wouldn't notice this.

> different. Rolling over a root with the same key is common.
Which I think is a questionable practise...

> key and the dynamics are different.
?

Cheers.

---

From: ianG <[email-masked]>
Date: Thu, 16 Apr 2015 14:31:37 +0100

So, the OpenPGP world has always separated policy from tech.  It has in 
effect kicked policy upstairs to the people.  Hence the key signing 
parties and the discordance between signing meaning "I saw a passport" 
versus "I saw a person".  This we all agreed was the smart thing to do.

However, Jon's revelation of yesterday really changed everything for me 
at least:

   > When 2440 started, there was an agreement with the Security
   > Area that OpenPGP would not be a "PKI" (whatever the heck
   > that means), because there was already a PKI, namely PKIX.

This thread (below) is about PGP as "a PKI" in a world where we are used 
to (up against) "the PKI" or incumbent x.509/CA.  Now that we're 
watching the slow burning sunset of "the PKI," and, now that we're 
looking at a whole new generation of usage for PGP (*), it may become 
more clear that we might have to revisit this.

Context:  I'm not saying I want to open up the debate.  My context is 
that I'm already doing it.  In effect <advert> I abandoned OpenPGP 2 
years back so that I could build my own PKI to suit my today's 
requirements </advert>.  To add further flesh to that, PHB is doing the 
same.  Jon will also have something to say on this, and others...

In short, the reality is that PKIs are evolving around us, so the 
question is not whether to do it, it's already happening.

The question is whether to bring it back in house?

iang

(*) to explain "new generation" a bit.  OpenPGP is a legacy product that 
deals with some niche use cases.  In order to make it move forward, and 
in order to justify putting the rather huge shared resources into a new 
update, it would be nice to kick it forward to the current level of 
understanding ... so that if finds a whole new user base in the 2020s 
world (aiming ahead).  I'm not saying what that is, just making a 
comment about market development.

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 16 Apr 2015 15:26:24 +0200

> You probably mean two keys?

I meant keyrings, as in primary keys + subkeys.

> sense to have e.g. different key prefs depending on the UID and/or

I agree. The phrase "out of scope" was probably misleading, I meant that
it is right now completely intransparent to users that key settings may
differ per user id, and that something might be differently encrypted to
one user id than to another in the same keyring.  I also suspect that
this is simply not true for many implementations - in the API we
designed for OpenKeychain, the user id to encrypt to is not even part of
the parameters.

 - V

---

From: Derek Atkins <[email-masked]>
Date: Thu, 16 Apr 2015 10:58:55 -0400

ianG <[email-masked]> writes:

> there an actual difference between them?  Why not just use the
> stronger one and be done with it?
>
> (Not wishing to start the algorithm agility debate, I'm sure
> everyone's familiar with the basics there, just wondering if there is
> any other motivation.)

Speed/Security tradeoff.  The two curves appear to be Curve25519 and
then Goldilocks-448.  The former is significantly faster than the
latter, so there is a desire for two curves to allow the speed/security
tradeoff.

> No RSA?  Is there consensus amongst devs that enough of us aren't
> going to implement RSA anyway?  We're ready to make a clean break, and

Just because RSA isn't MTI algorithm doesn't mean that it WONT get
implemented.  AES isn't MTI and most implementations seem to support it
today.

There's is a relatively small difference between MUST and SHOULD, a
larger difference between SHOULD and MAY, and a large canyon between MAY
and *NOT.

I believe the suggestions here are MUST v SHOULD.

> (I'm happy to join the witch-burning party, but it's had such long
> legs, it saw off the DSA challenger even tho many tried to kill it.)
>
>
>
> iang

-derek

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Apr 2015 16:05:58 +0100

To the extent that this is not openpgp specific, we have an
occasionally active list ([email-masked]) for topics
like that. So far though, I don't think anyone's gotten much
traction for anything on that, with the exception of CT that
turned into RFC6692 and now the trans WG. But if you want a
generic discussion of "whither now PKI" that is probably the
most appropriate IETF list. (Non-IETF lists might also be
appropriate too, depending on what you want.)

If you want an openpgp-specific discussion, that it'd be this
list, even if it's not so likely that a new WG would work on
that, or at least anytime very soon. (That's based on the
responses we got for doing "option 2" etc.)

I'm not clear if you wanted an openpgp specific discussion
or not though. (And the subject line combined with your
mail saying "I'm not saying I want to open up the debate"
also puzzled me mightily;-)

S.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 16 Apr 2015 11:19:52 -0400

> fingerprint is not the only way to address it.

True, but it's IMHO the best way in OpenPGP terms.

> principal application of fingerprints is analogous to a root.

Yes, but in PKIX you have the serial number.  We don't have that in
OpenPGP, and frankly I don't think we do need it or want it.

> key and the dynamics are different.

Not really.  The creation and expiration times in the "key" are (IIRC)
included not just in the self-singatures but also in all the additional
certification signatures, too.

I agree that if the Key has a creation date and expiration date then
those items should be immutable.

If the user wants to generate a new "key" using the same key material
(generally a bad idea, IMHO) then it should be considered a different
key (and as a result have a different fingerprint).

If the user believes that they might, down the road, want to re-certfiy
their key then the way to do that, IMHO, is to leave out the expiration
date in the key packet and just use the expiration date in the
self-signature to "time out" the key.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Thu, 16 Apr 2015 11:25:07 -0400

> I meant keyrings, as in primary keys + subkeys.

I must admit that given my 23-year history with PGP/OpenPGP, that is
*NOT* my personal definition of "keyring".  At least it's not where my
brain goes first when I see that word (it goes to the data file that
contains my local cache of all users' keys).

Ah, English -- so many ways to say the same thing.. or too few..

-derek

---

From: Derek Atkins <[email-masked]>
Date: Thu, 16 Apr 2015 11:29:07 -0400

Ian,

ianG <[email-masked]> writes:

> requirements </advert>.  To add further flesh to that, PHB is doing
> the same.  Jon will also have something to say on this, and others...
>

I'm not sure why you need to abandon OpenPGP to do this.  Me, I'm
building a PKI *using* OpenPGP.  It's actually working quite well,
although I wish there were more standard ways to do the things I
need/want to do.  But there's definitely enough flexibility in 4880 to
do everything I want/need.

Perhaps what we need is (as already suggested by Jon) a document or set
of documents that define how to do different types of PKI using OpenPGP
data structures.

-derek

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 16 Apr 2015 17:28:14 +0200

> *NOT* my personal definition of "keyring".  At least it's not where
> my brain goes first when I see that word (it goes to the data file
> that contains my local cache of all users' keys).

My use of the term was misleading I must admit, going by 4880.  I just
always found it confusing that a "public key" in OpenPGP lingo means "a
collection of one primary key and some subkeys", where each of those is
a 'public key' in itself in a cryptographical sense.

 - V

---

From: Werner Koch <[email-masked]>
Date: Thu, 16 Apr 2015 21:21:27 +0200

> I meant keyrings, as in primary keys + subkeys.

We use the term keyblock for this.  See 6.2. Forming ASCII Armor.

A keyring is a collection of keyblocks.

Salam-Shalom,

   Werner

---

From: ianG <[email-masked]>
Date: Fri, 17 Apr 2015 14:38:22 +0100

> do everything I want/need.

Right, that was what I was doing until recently.  Hence my historical 
interest in OpenPGP.

What caused the shift was a combination of bugs & failures, and outright 
cost.  I was working to get old software up and going, and had to get 
three different implementations of OpenPGP to behave.  I failed on all 
three, for different reasons.  So in the end I bit the bullet and wrote 
the stuff I needed directly [0] [1] [2].

> of documents that define how to do different types of PKI using OpenPGP

I would say: let's ground it to experience.  I'm uninterested in the 
pontifications of a group of cafe academics.  If you have real cases 
that are working for you, I'm interested in seeing that document.

iang

[0]   It took 1 month to write and another month to roll out through the 
rest of the code.  Since then it's been golden, a lot smaller, all 
totally aligned.

The older code bases probably cost me from 1-2 months of delay just in 
failing to get them going.  The first one that failed was Perl OpenPGP 
which relied on some maths library that just refused to install.  So 
this caused me to write the entire Perl application into Java - at a 
cost of 1-2m, but I always wanted to eliminate Perl ;)

The second failure was a combination of ye olde Cryptix and BouncyCastle 
OpenPGP implementations.  Part of the factor was that I drowned in the 
lower layer packets and APIs that just weren't documented enough, and 
the code was huge and opaque and comment shy.  Another part was 
dependency on JCE.  I hit something that was impossible on Android, too 
many dependencies, and decided enough was enough.

[1] Topic drift:  The approach I employ is also highly distinct to the 
older ways of doing things.  In the past, good design was based on 
packets and APIs.  We heavily standardised the packets & algs, then 
composed up from there, providing an API to build from individual bricks 
and knobs.

In a newer emerging method, if I may call it that, we standardise on 
high level interfaces and instead build vertical silo mini-protocols.  I 
now have a series of these heavy weight objects that do entire 
higher-level protocol things, that in some cases compose on other such 
objects.  However the internals of how they do it aren't the standard.

DJB's cryptobox is an example of this approach in the wild.

In contrast, the anti-pattern is Java's JCA.  There, you pass in strings 
like "AES/CBC/HMACSHA1" and have the Java Control Engine compose the 
things you're allowed to do.  Just to make the point, this is bad.

[2] It's also worth mentioning that back in the old days I had a team of 
people doing this stuff.  These days, it's just me.  So cost of 
development is a real killer issue.  I'm always looking for ways to 
build big powerful crypto stuff efficiently...

---

From: ianG <[email-masked]>
Date: Fri, 17 Apr 2015 14:44:04 +0100

> appropriate too, depending on what you want.)

(Just on that point alone, I think the better approach is to just do it. 
  Build it, show it works, and then worry about dox later on.  The 
solution on the table will drive the standardisation process.)

> or not though.

Yes, I was specifically speaking to openpgp, and more specifically 
speaking to the straw poll you raised a few weeks ago over whether to 
investigate the 't' in the 4 variants.

> (And the subject line combined with your

Indeed ;)  The point is, I think a lot of people might have not realised 
that there was a "higher force" pushing OpenPGP in the direction of not 
building a PKI.

It will take time for people to think about that, so I don't expect any 
change.  But next time this opportunity arises, there is now more data 
on the table.  I suspect in slow time this debate will open up now.

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Apr 2015 17:05:31 -0400

> of documents that define how to do different types of PKI using OpenPGP

I think that Stephen's proposal to use the right key for this is the
right approach.

What I want to do at this point is play. I want to strip the system
down and look at every part and decide what an ideal system might look
like and then look at how that maps to the legacy resources, including
OpenPGP and PKIX.

Looking forward, I want to eventually get to one PKI which combines
Web of Trust and Hierarchical concepts. I think I can demonstrate
mathematically that it is possible to achieve a higher work factor
that way than with either approach on its own. There are use cases
that I cannot satisfy with one or the other.

There are some features of a new PKI that I think are fairly obvious.
It is clear for example that the energy will come from the OpenPGP
world. It is also clear that ASN.1 is as popular as a dose of ebola
and there must be no new ASN.1.

But if we do have to do a lot of new stuff, I want to go to JSON
rather than trying to muck about trying to extend the 1990s style
structures.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 20 Apr 2015 11:22:33 -0400

> that I cannot satisfy with one or the other.

I'll note you can do that, today, with OpenPGP.  You run a CA -- start
signing OpenPGP keys with your CA Key.  Boom.  You're done.

> rather than trying to muck about trying to extend the 1990s style

I don't see what "new stuff" really needs to be done.

Seriously, please tell me what (other than Name Constraints) OpenPGP is
missing in order to support your concept of a PKI?  (And I'll note that
even NC can be done in OpenPGP via notations)

-derek

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 21 Apr 2015 01:33:38 +1000

> invalidating all signatures (i.e. those from other users).

While I can certainly see where you're coming from with this proposal,
the problem is that it is completely the opposite of the current
function of all key and subkey types.  There are quite a lot of
existing users out there who set expiration dates on their keys and
then keep changing them as the expiration date approaches.  So this
would be a nasty shock at the very least and may break some other
things, depending on what they're doing with all those keys.

To put it another way; that's a *lot* of old dogs we'd need to teach
new tricks to (and it's so often hard enough to teach the current
tricks to puppies already).

Regards,
Ben

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 21 Apr 2015 02:16:56 +1000

> more clear that we might have to revisit this.

I think part of the reason this keeps coming back to whether or not
trust definitions, signing policies and security policies keep coming
back is because of the lack of clarity, even amongst geeks.

I agree with the previous stance taken by most; we should not dictate
policy to end users, they're the ones in the best position to
determine how they use whichever implementation of the protocol
they'll use.  We should stick to specifying the tech involved.

The problem, however, is that current key management functions don't
really seem to address all the relevant components of different policy
types.  For example, I can sign a key locally, normally at certain
levels or assign a trust signature to indicate I trust the owner so
much they can make trust metric decisions for me (kind of).  Okay, but
why can't I include a specific notation value with my signature to tie
back to a published key policy on my site.  Then people could see
there's a signature and check a reference which indicates something
like "I met this guy, seemed honest, saw a license, but they can be
forged in this country, I'd readily encrypt to him, I'm pretty sure
he's legit, but I wouldn't bet my childrens' lives on that."

The real world is more complicated than the few options presently
available and if utilisation of trust metrics and relevant security
policies are to be effectively maintained then the end users need the
tools to put the scenarios they encounter into effect.  Some
additional functionality in that respect now would be good.  The same
goes for the totally arbitrary trust settings.  Presently I disable
the thing entirely because I have too many keys to locally sign
everyone I might encrypt to (everyone if I had my way).  Why can't I
say, "always trust when encrypting, but use the trustdb in relation to
signatures and determining authenticity of signed data."

There's also a lack of any way to indicate trust in the consistency of
a perceived entity being the same person, even without having
identities confirmed.  This could be useful for those establishing a
long term, consistent pseudonymous identity for whatever reason.

These are all functional, practical aspects of a trust system which
the specification should consider as a technical response to a lack in
the current standard.  Deciding on key usage policies would still be
entirely in the hands of end users as, indeed, it should be.  But
those users should have the resources to be more specific about how
their policies affect the usage of every component and application of
their keys within the context of their communications.

I am, of course, also aware that there is very often a fundamental
lack of understanding on where the lines are on things like that out
there, but as with cryptography itself, that is simply a matter of
education and familiarity.  There is, I will admit, a significant lack
of documentation in how to formulate a security or signing policy in
relation to OpenPGP, at least by comparison to sites with guides to
making keys and checking email.  That's another little beast entirely
and probably well beyond the scope of this WG.

It shouldn't be lost on anyone here, though, that the only crypto
users with specific key policies are those with a professional
requirement to do so or are interested in those aspects of information
security which make it relevant to them.  Everyone else coming to the
party tends toplay it by ear or ignore the entire thing.  This sort of
thing, however, deals with a great many things which go far beyond
just OpenPGP and it's definitely not something for the WG to handle.
Presumably someone will write something to help everyone else along
with it eventually ... by which I mean, once I've finished the outline
I've got in another buffer, I'll actually have to flesh it out.  ;)

Regards,
Ben

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 21 Apr 2015 02:34:21 +1000

> usable for different use cases, which is right now practically

Hmm ... if you think I'm taking the master/cert key for any of my
personal keys and leaving it on hardware controlled by an employer
then you'll be waiting a long time.

> sense to have e.g. different key prefs depending on the UID and/or

This bit is true and certainly the functionality of the first part
would be useful, but you can be sure that some people will still
separate keys to some extent.  Although in my case, the first thing I
always did with creating a new work key was to make sure I'd exported
the secret key and took a copy home.

It's not that I didn't trust a company and thought it might screw me
over one day, it's just that ... oh, wait, that was exactly it.

> IMO this vagueness may be even a security issue.

Yeah, my previous email responding to Ian deals with some of this.
There's still a separation of tech and policy or intent, but there are
identifiable functions which should be supported in order to provide
end users what they need to utilise a trust system and a security
policy effectively.

Regards,
Ben

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 21 Apr 2015 02:49:03 +1000

> A keyring is a collection of keyblocks.

While we're on this part, can we finally get some consensus on
keyblock formats?  Specifically that newly generated keys should *NOT*
consist solely of a primary with SCE or SCEA.  Though as near as I can
tell, this will mainly only affect the Kmail + Kleopatra Kontingent
(out of the box) and, maybe, the Bouncy Castle Java devs who continue
to insist on that kind of poor design choice and then inflict them on
unsuspecting end users to the detriment of those users and everyone
communicating with them.

Regards,
Ben

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Apr 2015 12:53:14 -0400

> even NC can be done in OpenPGP via notations)

It is not necessarily a question of capabilities as much as the effect of rails.

PKIX has a set of rules that are very useful and clarifying for cases
where the trust provider is an authority on the assertion being made.
If I have a CA that is bound to example.com then it can make
authoritative statements about *.example.com and *@*.example.com. If I
have an offline key it can create an intermediate that is almost the
same as it.

Such rules have value in the situations where they work. But they
don't work everywhere.

What we need is the PKI equivalent of structured programming. PKIX is
Pascal. PGP is BASIC. Yes, you can do anything with IF-THEN-GOTO. But
you probably should not try.

I don't think that it is going to be sustainable to have a PKI for
email and a PKI for non-email in the long term. There has to be merger
at some point. That was the origin of the assertion infrastructure
that became SAML when we were doing angle brackets. Now its curly
braces...

---

From: Werner Koch <[email-masked]>
Date: Mon, 20 Apr 2015 19:58:49 +0200

> tell, this will mainly only affect the Kmail + Kleopatra Kontingent

Sorry, I do not understand this.  I can imagine reasons why you want a
signing and encryption capable key and no subkeys.

What has this to do with Kmail + Kleopatra ?  They use standard GnuPG
and I am pretty sure that they create RSA+RSA keys; after all this is
what gpg4win does which is the standard installer for GnuPG.

> unsuspecting end users to the detriment of those users and everyone

In case you refer to a bug report where some Bouncy Castle based
implementation ignored the keyflags [1]: This is clearly a bug in that
implementation.  I actually heard stories at the weekend about
implementations which didn't implement even very basic requirements.  It
is not a problem of Bouncy Castle, though.

Shalom-Salam,

   Werner

[1] Which ignored the key flags and encrypted to the primary key which
    happened to be on a smartcard which enforces PKCS#1 for the key so
    that the reporter was not able to decrypt.
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Werner Koch <[email-masked]>
Date: Mon, 20 Apr 2015 20:04:57 +0200

> invalidating all signatures (i.e. those from other users).

A hard expiration time vor a v5 key format was proposed by Florian
Weimer many years ago.  IIRC, we even had consent that this should be
done by putting it into a v5 key packet.

Salam-Shalom,

   Werner

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 21 Apr 2015 05:49:21 +1000

> signing and encryption capable key and no subkeys.

Really?  Alright then at least make it so that in each implementation
that's not the default.

> what gpg4win does which is the standard installer for GnuPG.

No, Kleopatra's default config in gpg4win is to create RSA as SCE
with no subkeys.  Like this:

pub  rsa4096/0xD3..REDACTED..47
     created: 2014-12-29  expires: never       usage: SCE
[ unknown] (1). S**** L***** <[email-masked]>

BTW, this is a real key belonging to a prominent Australian political
figure, who has been somewhat vocal on privacy issues (hence using his
personal address and not his other one).  Fortunately for him we'll be
at the same event next week and I can help him fix it, but that's pure
chance and something all the other gpg4win users don't get.

It wouldn't be so bad if GPA was the default GUI, but it isn't,
Kleopatra is the default install with GPA requirong manual selection
when the installer launches.  Instead users get whatever defaults are
set by the Kleopatra team in that product (which seems to be to try to
turn OpenPGP into SMIME).  If there's some function that Kleopatra
performs and GPA doesn't then that sounds like a good reason to draft
some volunteer help in expanding GPA.  Even the little Qt thing the
GPG4USB team came up with would be better than Kleopatra if it could
work with 2.0.  Plus there are numerous reports of a higher frequency
of bad signatures and other errors from people using KMail clients,
very likely linked to other aspects of poor implementation.

The only way for gpg4win users to get a key with subkeys is to either
manually add one after key generation, use GPA instead, use the
command line instead or do ignore those frontends entirely and
generate within Enigmail.  The only thing in gpg4win's favour at this
point is that someone in a country that won't lock them up for
exporting crypto (so that rules me out ... at least once ECC is
involved) can build a version which removes Kleopatra from it
entirely.  At least that process looks pretty simple (a little line
removal in packages/packages.current should do it).

> is not a problem of Bouncy Castle, though.

I can't off the top of my head right now, but given BC is just the
java libs it might have been one of the other projects which leaned so
heavily on it.  Maybe Portable PGP, but I thought it was more recent
than that particular travesty.  Ah well, maybe it'll come back to me
later, still I guess if people are Hell-bent on breaking something we
can only advise them not to (and then get out of the line of fire).

>     that the reporter was not able to decrypt.

Wow, that's just hilariously bad.  I shouldn't laugh at that, but I
just can't help it.  :)

Regards,
Ben

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 21 Apr 2015 00:04:08 +0200

> then you'll be waiting a long time.
Actually the opposite:
You should be able to place your *secondary* key(s) onto your employer's
hardware.. but for that to be practically usable, we need some kind of
"UID or role attributes" or anything that like which can be connected
with certain subkeys.

> separate keys to some extent.
Sure... but that's a completely unrelated thing.

> over one day, it's just that ... oh, wait, that was exactly it.
Sure... but that's one of the reason why it might make sense to have
e.g. different key flags depending on the combination of UID *and*
subkey (of course right now, there is no connection between UID/subkey,
at least not in the sense mentioned above).

Cheers,
Chris.-

---

From: Werner Koch <[email-masked]>
Date: Tue, 21 Apr 2015 08:38:13 +0200

> Really?  Alright then at least make it so that in each implementation

Sure.  Everything else is a bug.

> with no subkeys.  Like this:

Oops.  That should not have happened.  Let's take this to
gpg4win-devel@.

Shalom-Salam,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Mon, 20 Apr 2015 23:50:59 -0700

> On Apr 20, 2015, at 11:04 AM, Werner Koch <[email-masked]> wrote:
> 

I wouldn't go quite that far as "consent" if by that you mean "consensus." There are many things that got punted into the future rather than argue now.

Personally, I think that the present way things are done is syntactically fine. Semantically, there are many bogosities. You can time-limit your signature on a key, but no one ever does. There are lots of reasons for that, I think, none of them technical. They all are social.

	Jon

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 21 Apr 2015 17:14:41 +1000

> Sure.  Everything else is a bug.

Excellent.

> Oops.  That should not have happened.  Let's take this to

I'll be on that list just as soon as the subscription messages work
their way past the grey-listing.  ;)

Regards,
Ben

---

From: Werner Koch <[email-masked]>
Date: Tue, 21 Apr 2015 11:45:22 +0200

On Tue, 21 Apr 2015 08:50, [email-masked] said:

> I wouldn't go quite that far as "consent" if by that you mean
> "consensus." There are many things that got punted into the future

Yeah, the latter of course.   In the context of a v5 key format we
should discuss whether it really makes sense.

Salam-Shalom,

   Werner

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 21 Apr 2015 13:50:25 +0200

On Mon, 2015-04-20 at 23:50 -0700, Jon Callas wrote:
> Personally, I think that the present way things are done is
> syntactically fine. Semantically, there are many bogosities. You can
> time-limit your signature on a key, but no one ever does.
As I've explained before, I don't think that this is the same as
hardcoding it into the key, as it wouldn't change the fingerprint, would
it?!

---

From: David Leon Gil <[email-masked]>
Date: Thu, 23 Apr 2015 00:46:06 +0000

S2K with MD hashes is a horrible KDF. It is very very much worse than
PBKDF2.

The main reason that there are no papers comparing them is that S2K is so
obviously bad that no-one thinks it is worth the effort of publishing about
it.

Scrypt is okay as a password hash. Lyra2 would be better.

---

From: Werner Koch <[email-masked]>
Date: Thu, 23 Apr 2015 09:13:14 +0200

> S2K with MD hashes is a horrible KDF. It is very very much worse than

Care to explain?

Salam-Shalom,

   Werner

---

From: Alessandro Barenghi <[email-masked]>
Date: Thu, 23 Apr 2015 07:55:20 +0000

>> S2K with MD hashes is a horrible KDF. It is very very much worse than

S2K is somehow lagging behind in considerations to prevent efficient
bruteforce :

-- Mode 0 allows to exploit time-to-memory tradeoffs (e.g. rainbow
tables) to break large amounts of passwords
-- Mode 1 adds salt, but still employs a single run of a hash function,
which is designed to be efficient, to derive the password. This allows
efficient bruteforce with just computational resources
-- Mode 3 has a maximum working factor of 255 (one octet to specify
iterations), which is both growing thin (current hash working factor are
around 1k-3k to cope with increased computational power and parallelism)

PBKDF2 is salted, and has a tunable working factor, although only
exploits computational and not memory needs to prevent efficient bruteforce.

Scrypt adds to a tunable working factor, the requirement for a tunable
amount of memory to compute the KDF.
Tuning the memory to be high enough you can hinder the bruteforce on
highly parallel architectures, as it is harder to obtain fast and large
memories than a large amount of parallel processors.

Cheers

Alessandro

---

From: Alessandro Barenghi <[email-masked]>
Date: Thu, 23 Apr 2015 07:56:25 +0000

Cheers

Alessandro

---

From: Nils Durner <[email-masked]>
Date: Thu, 23 Apr 2015 11:38:09 +0200

Hi,

> iterations),

The one octet encodes much larger values, see RFC 4880 section 3.7.1.3. for
the formula applied to it. A literal value of 255 in this octet would
compute to an iteration count of 65 millions.

Regards,

Nils

---

From: Nils Durner <[email-masked]>
Date: Thu, 23 Apr 2015 11:40:11 +0200

Wrong. It's not the iteration count - it's the octet count of how many
octets will be hashed.

2015-04-23 11:38 GMT+02:00 Nils Durner <[email-masked]>:

> The one octet encodes much larger values, see RFC 4880 section 3.7.1.3.
> for the formula applied to it. A literal value of 255 in this octet would

---

From: Alessandro Barenghi <[email-masked]>
Date: Thu, 23 Apr 2015 10:37:54 +0000

On 04/23/2015 09:38 AM, Nils Durner wrote:
> Hi,
> 
> 
> -- Mode 3 has a maximum working factor of 255 (one octet to
> specify iterations),
> 
> 
> The one octet encodes much larger values, see RFC 4880 section
> 3.7.1.3. for the formula applied to it. A literal value of 255 in
> this octet would compute to an iteration count of 65 millions.

Yep, sorry, my mistake. It is possible to tune the work factor to
match common ones for PBKDF2 in S2K.
The point on fixed memory requirements, on the other hand, still holds
in favor of scrypt

Cheers

Alessandro

---

From: Derek Atkins <[email-masked]>
Date: Thu, 23 Apr 2015 11:48:51 -0400

> hardcoding it into the key, as it wouldn't change the fingerprint, would

No, it would not, which is IMHO the right thing.

I.e., IMNSHO I feel you should expire your key by expiring your
self-signature on the key.  If you want to extend your key then you
re-sign it with a new self-signature.

-derek

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 23 Apr 2015 18:11:47 +0200

> re-sign it with a new self-signature.
Well but than it's useless to make the key as a whole expirable.

And as I outlaid before, this destroys the use case that a user wants to
limit the usability of his key, regardless of whether e.g. old signature
algos would be broken or his key compromised.

If that's only in the selfsig *without* invalidating the other
signatures, then an attacker could try a downgrade attack and e.g. forge
the selfsig with weaker algos... or more likely... simply create a new
selfsig when the key was compromised.

If the fingerprint and other users' signatures wouldn't invalidate them,
all the attacker needs to do is block the revocation (if any).

Therefore, it should be mandatory that both, the valid from and valid to
times are encoded in such a way, that changing them would render all
other signatures invalid and would change the FP.
(Of course it should be possible to specify and infinite expiration
time).

Cheers,
Chri

---

From: Earle Lowe <[email-masked]>
Date: Thu, 23 Apr 2015 10:18:50 -0700

The maximum work factor for RFC4800 S2K is lower than the maximum for (eg)
PBKDF2

As the maximum for RFC4800 is specified in bytes, the iteration count
(number of hash invocations) goes down as the size of the hash increases.

The max iteration count for SHA1 ~= 2^22; SHA256 ~= 2^21; SHA512 ~= 2^20,
etc, etc

(65011712 / sizeof hash)

So in this case, you can have a much higher work factor for the other
algorithms.

Although I'm not sure it really matters that much when off-the-shelf and
cheap GPUs can do billions of these a second.

I'd like to see PBKDF2 simply from an "certification" point of view (it's
well known to various certification agencies - common criteria, cesg, nist)

(although for others that same reason might be a detractor)

-Earle

On Thu, Apr 23, 2015 at 3:37 AM, Alessandro Barenghi <
[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iF4EAREIAAYFAlU4y4IACgkQE+mB79BmI3FR1AEAmiJ25uiY3cGP8HC2Kb66ZoO4
> S7cD++B76xa598iBzqoBAJhFY2/bQb35Fw15NeLlay6gqY/TNi/LEwNaooyVGHBz
> =6tlE
> -----END PGP SIGNATURE-----
>

---

From: Alessandro Barenghi <[email-masked]>
Date: Thu, 23 Apr 2015 18:19:31 +0000

On 04/23/2015 05:18 PM, Earle Lowe wrote:
> The maximum work factor for RFC4800 S2K is lower than the maximum
> for (eg) PBKDF2

Yes, although it is possible to match ones commonly used now (1k-3k)
and have a reasonable margin for raising the value (hitting around
100k is not a problem, which keeps the now-dying Moore law at bay for
another 10 yrs at worst).

> As the maximum for RFC4800 is specified in bytes, the iteration
> count (number of hash invocations) goes down as the size of the
> hash increases.
> 
> The max iteration count for SHA1 ~= 2^22; SHA256 ~= 2^21; SHA512
> ~= 2^20, etc, etc
> 
> (65011712 / sizeof hash)
> 
> So in this case, you can have a much higher work factor for the
> other algorithms.

Looking at section 3.7.1.3, the formula for the work count is defined as:
#define EXPBIAS 6
    count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

where c is the octet-sized value stored. I could not find the
dependence of the work factor from the hash size: could you possibly
point me to it?

> Although I'm not sure it really matters that much when
> off-the-shelf and cheap GPUs can do billions of these a second.

With respect to this, picking a memory hard KDF such as scrypt
nullifies the benefits of massively parallel hardware, as there's no
way of getting both fast and large memories for [G|C]PUs, and a
sizeable amount of SRAM takes up a lot of space in a dedicated ASIC
breaker.

Cheers

Alessandro

---

From: Earle Lowe <[email-masked]>
Date: Thu, 23 Apr 2015 11:52:38 -0700

Assume iteration count to mean "the number of times I call the hash
function - eg the number of times I call Sha256()" (this is my
understanding of the typical work factor eg for PBKDF2)

The OpenPGP work factor is a count of bytes to hash. If the hash function
hashes 32 bytes, then I would call that hash function "count / 32" - as
each invocation gives me 32 bytes.

(this may be overly simplistic a view - please correct me if I'm overly
simple )

-Earle

On Thu, Apr 23, 2015 at 11:19 AM, Alessandro Barenghi <
[email-masked]> wrote:

> iF4EAREIAAYFAlU5N7MACgkQE+mB79BmI3GURAD8D6g/znTgj2uZ7IwFwf7hoqiR
> CP7jmeOwXvm4LHlCQ3QA/jpoVvSn+UJ0v89+RWex0HigMkqSVd3lVFe+7as7FkBG
> =WJoE

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Apr 2015 15:03:17 -0400

> re-sign it with a new self-signature.

You are not expiring a key. That is impossible in any PKI and almost
certainly undesirable.

What you are doing is expiring an assertion binding between the key to
a set of attributes. Similarly you are not revoking a key, you are
making an irrevocable and permanent assertion that the key is not
valid.

Being precise about these things is going to be important if we are
going to actually clean up OpenPGP and not add more confusion.

It is quite possible to set a key fingerprint for expiry however. We
simply take a fingerprint of an assertion that includes an expiry
time.

---

From: Alessandro Barenghi <[email-masked]>
Date: Thu, 23 Apr 2015 19:35:58 +0000

> understanding of the typical work factor eg for PBKDF2)

Ok, I'm on the same boat

> The OpenPGP work factor is a count of bytes to hash. 

Ok, now I got the point, thanks :)

> If the hash
> function hashes 32 bytes, then I would call that hash function "count /
> 32" - as each invocation gives me 32 bytes.

As far as I know, the input to a hash function has a very large limit on
its maximum size (2^64 for SHA-2-... functions), so, if I get that
correctly, this means that given a count value C , the hash function
gets called:

(C- (size of passwd+salt)) / output_hash_size

correct?
(which, on a curious side note means "the longer the password+salt, the
lesser the amount of calls to the hash function", although the
computation effort is substantially the same)

Cheers

Alessandro

---

From: David Leon Gil <[email-masked]>
Date: Thu, 23 Apr 2015 19:44:49 +0000

The input to the hash function is predictable. You can thus (depending on
how the hash function is constructed) precalculate some portion of the S2K
function.

For example: For SHA-1 and SHA-2, message expansion is independent of the
chaining value. So for, e.g., an 8 byte password, you only need to expand
the message schedule *once*.

See https://github.com/google/end-to-end/issues/150

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 24 Apr 2015 00:19:02 -0700

In summary, I would be more concerned with users getting wrong 
impression that somehow their low-entropy password will get "upgraded" 
by a new S2K scheme. There is a cost of change, and I think if the 
OpenPGP does change the S2K, the choice should bring concrete additional 
benefits.

Here is why:

1. One should keep in mind what value the iterative methods like S2K or 
PDKDF actually provide. Assuming that the number of iterations is c and 
the password space has 2^n entries, the work factor for legitimate users 
is c*2^n, as opposed to 2^n without iterated calculations. Doubling the 
c slows the computation time in half for the attacker as well as for the 
the password holder; this is equivalent to adding 1 bit of extra entropy 
to password space. This offers one of the worst cost-benefits to 
legitimate users. Just compare this with any other computational 
security schemes, such as public key crypto (exponential v.s. polynomial 
complexity).

2. The Iterated S2K is essentially a

    M = M1 || M2 || M2 || M2 || ... || M2, where M1 includes the salt.
    S2K = Hash( M )

(assuming that hash output is no smaller than the number of bits 
required for the key).

In many respects, this construction is easier to analyze. There is no 
attempt to "fix" the hash function as in some other schemes. Imagine a 
sponge construction like SHA3 Keccak or many other hash functions with 
sufficient internal state (probably including SHA-256), which should be 
fine to handle the above task.

3. The max number of iterations that the S2K counter encodes is c = 
16+15^(15) + 6 > 2^58

For SHA1 S2K this is over 2^53 invocations and about the same for 
SHA-256. SHA-256 can only hash 2^64 bytes. Likewise, AES-256, as any 
16-byte block cipher, is considered insecure after about the same number 
of invocations due to the birthday bounds limitation.

This is plenty of iterations for the foreseeable future.

4. One can argue that the S2K construction is one of the strongest in 
active use today. If we assume that it's possible to recover M given the 
S2K as defined the above, i.e. to invert a hash function (even assuming 
somehow that S2K value is known, which it is not) then many existing 
schemes will be broken. For example, an attacker that is able to get M 
from S2K can use the same method to recover the authentication key K 
from an HMAC MAC value, leading to the forgery of MAC.

The proof is easy: use the "oracle" that returns M from S2K = Hash( M )  
to recover the HMAC key as follows: get M' = K ^ opad | H( K ^ ipad | m 
), which reveals the K as M' ^ opad with appropriate truncation.

The other problem one might try to solve with S2K construction is how 
the scheme behaves with non-uniform hash functions. ( Imagine that a 
hypotherical Hash() often returns all-zero output for random M). 
However, we don't intend to use these hash functions, will quickly 
replace them if we discover that we do.

It's hard to see that S2K and PBKDF are materially different. ( In less 
formal language: PBKDF2 should have the same resulting weakness, but 
long before this the collision resistance will likely be broken ).

Both schemes have the same problems. For example, both have an 
unfortunate property that if the two invocations of PBKDF (or S2K) use 
the same salt and password but different counters c1, c2, the S2K or 
PBKDF can be calculated from the previous values with just |c2-c1| 
iterations. I.e. it seems like an oversight that c was not hashed. As 
was noted by others, it may be desirable to increase memory footprint 
requirements.

HKDF is not designed to handle S2K. (It's main target are things like 
derivation of an AES key from a DH shared secret). At least it needs the 
stretching step defined.

---

From: Werner Koch <[email-masked]>
Date: Fri, 24 Apr 2015 13:45:27 +0200

>    M = M1 || M2 || M2 || M2 || ... || M2, where M1 includes the salt.

Actually M2 also includes the salt:

|  Then the salt, followed by the passphrase data, is repeatedly hashed
|  until the number of octets specified by the octet count has been
|  hashed.  [...]

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Fri, 24 Apr 2015 13:11:20 -0400

> Well but than it's useless to make the key as a whole expirable.

No, it's not useless.  If you know that when you generate the key you
absolutely never want it to be usable past a certain date, then you put
the expiry into the Public Key packet.  Once that date passes, the key
has expired.  The date should be immutable.

However if you're not sure, or you want to prove user liveness on the
key, you can perform similar functions (note that it's not exactly the
same function) by using expiring self signatures.

> algos would be broken or his key compromised.

It doesn't destroy the use case; you can still use the Key Expiry.  It's
just an IMMUTABLE setting.  If you change it then it should make it a
"new" key, which means a different fingerprint (and invalidating all
signatures).

> selfsig when the key was compromised.

Yes, this is a risk of not using the expiry field in the key packet.

> all the attacker needs to do is block the revocation (if any).

I'm not sure I understand this statement.

> (Of course it should be possible to specify and infinite expiration

Yes, that's why the key expiry should be immutable.  Changing it would
invalidate all signatures on the key, as well as changing the key
fingerprint.  I.e., it's a "different key".

However the key expiry should not be mandatory (i.e. it can be 0,
meaning "never expired").  There are use cases where you might not
necessarily want the key to expire, or you might not know when it should
expire.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Fri, 24 Apr 2015 13:38:27 -0400

> You are not expiring a key. That is impossible in any PKI and almost

Well, it depends.  In OpenPGP you *can* expire the key (by setting the
Key Expiration in the Public Key Packet by setting it to a non-zero
value).  My argument is that that setting should be immutable.  I.e., if
you change the value in the key packet, it's IMHO effectively a new key,
with a new fingerprint, and would require new signatures.

Whether or not it's desireable is an open question (and one I don't
think you or I can make for the users).

> going to actually clean up OpenPGP and not add more confusion.

I agree it's important to be precise.  And yes, the proposal I made
earlier to use the self-sig is indeed expiring the assertion binding the
key to a UserID.  I.e., the signature itself has an expiry (which is
independent of the expiry field in the Public Key Packet).  When the
signature expires then the assertion expires.  But of course you can
refresh the signature; it doesn't change the key.

Of course, as pointed out, you're only as strong as your weakest
algorithm, so there is a risk of someone being able to create a false
signature using a (supported) broken hash algorithm.  I consider this a
LOW risk, but it is still a risk.

> simply take a fingerprint of an assertion that includes an expiry

This is... different.  OpenPGP allows you to specify a fingerprint as a
dedicated revoker.  I.e., I assert (via a self-sig IIRC) that the key
with fingerprint X is allowed to revoke this key.  I'm not sure that you
would use your own fingerprint for anything like this.

-derek

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Apr 2015 12:03:00 -0700

> On Apr 20, 2015, at 9:53 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 

If only there were a way to do that.

Let's consider a machine that has a set of simple operations that it can do, like IF-GOTO and another language that did more complex things like IF-THEN-ELSE. If we could make something that could take the complex language and translate it into a set of the simpler statements reliably, then perhaps we could solve that problem.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Apr 2015 12:09:01 -0700

Okay, turning off my smartass mode for a moment.

PGP does this. By the way, PGP is registered trademark owned by Symantec. They presently call that software "Symantec Endpoint Encryption" and "Symantec Encryption Management Server" but that's PGP.

OpenPGP is an IETF standard for describing crypto syntax and protocols.

X.509 and OpenPGP are isomorphic to each other. You can do anything in one of them that you can do in the other. If you take an OpenPGP key, you can express the same thing with a set of X.509 certificates. It works. We did it. PGP does OpenPGP, X.509, CMS and S/MIME.

You can do it. You just have to want to.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Apr 2015 12:42:57 -0700

(Pulled into a new subject.)

> and non-determinism to those parts of the implementation which dealt

Because you want the key owner to issue a signed statement that says "this is how I want you to use my key" and you want that to be part of the self-signature that says "I own this key." You don't want a separate signature, because you don't want them to be torn apart.

> in OpenKeychain because the complexity/benefit tradeoff just wasn't

Let's face it. Revocation is not as good as people think it is. In the general case it cannot work. There are specific cases where it can work, but you must always account for the case that there is revocation information, you're just not getting it. It's true in OpenPGP, where a revocation signature can be stripped from the key, and true in CRLs where there are all sorts of spoofing things that can be done that block you from the information. You can in some cases *know* you've been blocked. (Suppose the connection to the CRLDP (etc.) fails outright, or it hands you an old CRL.)

Sadly, the correct thing to do is almost never to pull the emergency brake and stop whatever process you're doing. The reason is that the likelihood of a completely reasonable reason for the failure (your network sucks) is several orders of magnitude higher than a real needed revocation.

(There are many, many unneeded revocations. For example, I know a code-signing system where the code-signing cert includes a bunch of developer information. Every time the developer changes anything in their web profile, a new cert gets issued, the old cert gets put on a CRL, and the old cert is also thrown away. It's rigorous and tidy, but utterly unneeded.)

Anyway, I advise not going too far to fix revocation because there are edge conditions on the edge conditions. It works when it works and how it works, and just accept it.

But I didn't answer your question. Sorry. You can do that now -- Alice can give Bob a pre-revoked key and ask him to release it when she asks.

But you don't want to do that for a number of reasons. One is that you can't a priori know *why* you're going to revoke. You also can't a priori know *when* you want to revoke. If Alice loses her laptop on April 24, you want signatures she made on April 23 to still be valid. You really don't want to undo everything that key ever did. That makes revocation worse than useless. Presently revocation is kinda sorta often useful. 

On top of that, the thing that Bob has is dangerous data. It has to be stored somewhere with all the seriousness of a private key, if not more because it's trust issue. (Not this weird thing we call trust in public key infrastructure, but actual real trust.) It makes a whole huge OPSEC issue that's harder to solve than it is to implement the designated revoker. Yeah, having it makes it hard on a developer, but not having it pushes the problem to people who are incapable of doing it right.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Apr 2015 12:45:51 -0700

> On Apr 16, 2015, at 8:28 AM, Vincent Breitmoser <[email-masked]> wrote:
> 

And that's why sometimes you should just use the word "Certificate."

	Jon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Apr 2015 15:51:23 -0400

What I would like to see is a clear semantic and syntactic separation
between first and third party assertions.

I am aware that Symantec bought PGP, but it is still the name of Phil
Z.'s model.

PKIX and OpenPGP both conflate the two. But there is a big difference
between them when it comes to trust issues. A first party assertion
such as a PKIX root signing an intermediate is a direct assertion and
can be modeled in the same manner as a finger print. The only
assumptions I am making are that the crypto isn't broken and the key
holder has not lost control of their key.

Third party assertions are much more complex and problematic. We get
into recursion issues and fixed points on contraction mappings and all
the math stuff.

Neither PKIX nor OpenPGP really provide the end user with the full set
of tools needed to do comprehensive key management. The PKIX model is
that the user does not have a persistent key history at all, the CA is
the only party managing this. OpenPGP takes the UNIX/C attitude of
give the users a sharp knife and blame them when they cut themselves.

> You can do it. You just have to want to.

Yep. And I suspect that pretty much anyone that is doing a key
management app will do the same.

It is really easy to roll the same set of assertions in multiple
syntaxes. And that is necessary to solve a lot of real world use
cases. I have just bought a QNAP server, it has SSL but does not have
a CA issued cert so I get browser warnings.

I should be able to snap that server into my personal PKI keychain and
have it 'just work' and the protocol for doing that should be no
different to the protocol for setting up my email client or my Web
browser. And I should be able to do that without having to wait for
S/MIME or PGP to win the email format wars or TLS to support PGP
certs.

It is quite possible to express the full functionality of PKIX in a
far more compact form. That is what I was originally commissioned to
do by VeriSign in what became XKMS and SAML. TAXI was only about 30
pages long and it did everything the WebPKI does using PKIX. Just
instead of OCSP and SCVP and CRLs these were all expressed as
assertion validity conditions.

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Apr 2015 13:02:28 -0700

> On Apr 21, 2015, at 4:50 AM, Christoph Anton Mitterer <[email-masked]> wrote:
> 
> * PGP - S/MIME Signed: 04/21/2015 at 04:50:25 AM
> 

I read your explanation. I understand it. I just disagree.

I think that hard-expiration is not only a bad idea, but unenforceable.

It's a *good* thing for Alice to be able to update the expiration time on her key. It encourages putting a limit on (as opposed to no limit) if it can be changed later. It also allows advanced systems to be able to do some really cool things with short lived keys.

And you probably can't prevent it anyway. X.509 syntax people have kittens if you reuse a key in certs. And yet a major feature of many PKI systems is to "reissue" a cert with a new expiration time, because it makes operations much easier for everyone.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Apr 2015 13:08:34 -0700

> On Apr 23, 2015, at 2:40 AM, Nils Durner <[email-masked]> wrote:
> 
> Wrong. It's not the iteration count - it's the octet count of how many octets will be hashed.

it is isomorphic to iteration count. It's just screwy and too clever by half. Okay, I take that back. You know how there's a fine line between clever and stupid? It's so clever that it wraps the cleverness counter and ends up on the stupid side.

I would love to see PBKDF2 in there on the list of things acceptable. Please do not assume my comment above means that I have *anything* nice to say about the present iterator. It is, however, as secure as PBKDF2. It's just too clever by half.

	Jon

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 01:15:45 +0200

> making an irrevocable and permanent assertion that the key is not
And the important point here to add is, that there is basically no
guarantee, that this irrevocable and permanent assertion of revocation
ever reaches the user.
The contrary, it is likely extremely easy to selectively filter out
revocations for each (receiving) user.

So when e.g. Wener's key for signing gnupg is compromised, he notices
and revokes it, what keeps the ISPs, NSA, cyber criminals & Co. from
blocking the revocation?
Sure, when they'd do it, it *migh* be noticed, sooner or later,... but
when they do it really smart it may be never ever noticed and even if,
it may be too late for many people.

> simply take a fingerprint of an assertion that includes an expiry
Yep,... plus the same is needed for any other signtaures which are
calculated over the key material + UID data itself.

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 01:39:11 +0200

On Fri, 2015-04-24 at 13:11 -0400, Derek Atkins wrote: 
> No, it's not useless.
If the expiration time is *not* hard-coded into the FP and other
signatures... what does it give you that can't be done with revocation
signatures?

> If you know that when you generate the key you
Maybe I'm wrong, but I don't think there is a field for that.
Section 5.5.2 lists only the creation time as part of the public key
packet for v4 keys.

So to my understanding, with v4 keys (and IIRC v3 is deprecated?) any
expiration times are always stored in the signature subpackets.
But since these are not part over which the FP or other user's sigs are
calculated, they forgeries I've mentioned earlier are possible.

> However if you're not sure
As I've mentioned before, I don't think we should made an expiration
time mandatory - it should be hardcoded, but users should still be able
to set it to infinity or 1000 years if they want.

> , or you want to prove user liveness on the
> key
Proving "user liveness" is a) anyway questionable (if the user is dead,
who guarantees that noone else has his private key?) and b) much better
done by simply resigning the key+UID with a selfsig - but that doesn't
mean one cannot hardcode the expiration time.

> just an IMMUTABLE setting.
Well than please explain this more detailed.
AFAIU, when you now change the expiration time on a v4 key+UID, it
neither invalidates 3rd user sigs, nor it changes the FP.

Have a look at 5.2.4, where it's described how cert sigs are made and
AFAIU, these are only done over the UID+key, but not the selfsigs and
thus not the key expiration times.

> Yes, this is a risk of not using the expiry field in the key packet.
I guess you mixed up v3 with v4 keys, the former were still secure with
respect to meta attacks on the expiration time.

> I'm not sure I understand this statement.
Well I referred to the basic attack vector in this scenario:
- If I could create a key/UID with immutable expiration times, then I
could e.g. say, all my high security keys are only valid for one year.
If the key is compromised after that time, then an attacker could no
longer "re-sign" they key with a new expiration time (thereby tricking
my peers into trusting it), because it would change the FP and
invalidate their sigs.

- Right now (with v4 keys) they expiration is to my understanding only
set in the self-sigs and changing it doesn't invalidate other user's
signatures nor result in another FP.
So if my key is compromised now, than even if I set the expiration to
one month, the attacker could simply make another selfsig.
Further, he could probably block any revocation signatures from the
keyservers... and even any "older" self-sigs that contain the expiration
(which may otherwise look suspicious to the careful lookin user)

> fingerprint.  I.e., it's a "different key".
Well that's what I always say, isn't it? It's just not doable with
current key versions.

> meaning "never expired").
Sure, but I never said that we should force the user to actually set a
time.

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 01:43:11 +0200

Perhaps a side note on the key derivation function discussion:

I think it would be beneficial, the algorithm for that would be variable
(i.e. having an algorithm field like the other alogs).
Secret keys typically don't move so much, so this is really a place
where distros/implementations may to choose what they prefer.

And as usual, it would also allow us to move on much easier, when
new/"better" functions hit the market.

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 01:55:36 +0200

> I think that hard-expiration is not only a bad idea, but unenforceable.
Then please elaborate why, cause I gave some clear usage scenarios where
hard expiration times would be beneficial, and your points below don't
really seem to be good against.

> It's a *good* thing for Alice to be able to update the expiration time
> on her key. It encourages putting a limit on (as opposed to no limit)
> if it can be changed later. It also allows advanced systems to be able
> to do some really cool things with short lived keys.
But for all that I don't think we'd need to have a mutable expiration
time.
Just make they non-expiring at first, and release a revocation
certificate once the point has been reached, when it should really be
stopped from using.
Theoretically one could even make the revocation signatures themselves
expiring again, so that the revocation would only last for so and so
long (which is however really just hypothetically, and nothing that
should ever be done ;) ).

Further, my proposal of allowing for an immutable expiration time
doesn't mean that we have to drop the mutable on.
Just define it like this:
- if the expiration time in the key block itself is set to non-zero,
than this time is the expiation time and any other key expirations on
self signature MUST be ignored
- if the expiration time in the key block itself is set to zero, then
the key doesn't expire, but selfsigs may.

So you still could revoke single selfsigs and you could also resign your
key with new selfsigs, thereby getting the same behaviour as of now - a
mutable "key expiration time".

But the key expiration time signature subpacket should really go away,
it doesn't do what it's name promises, and it's effect could/should
rather be done with the expiration time of the selfsigs.

> And you probably can't prevent it anyway. X.509 syntax people have
> kittens if you reuse a key in certs. And yet a major feature of many
> PKI systems is to "reissue" a cert with a new expiration time, because
> it makes operations much easier for everyone.
I don't see why it shouldn't be possible.
Just put it back into the key block, then the FP will include it and the
cert sigs from other users as well.
Of course you can still use the raw key material and create a new key
with another expiration time and the same UIDs of it,... but that will
be a new and totally different key.

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 01:58:29 +0200

> give the users a sharp knife and blame them when they cut themselves.
You can have a CA model in OpenPGP as well, actually it's very simple by
using trust signatures.

Just found some "CA keys", sign them with an unlimited trust-sig, any
you'll believe whatever they sell you.

Cheers,
Chris.

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 24 Apr 2015 23:06:18 -0700

> |  until the number of octets specified by the octet count has been
I stand corrected.

My argument holds with even greater simplifications with the following 
adjustment:

   M = M1 || M1 || M1 || M1 || ... || M1, where M1 includes the salt.
   S2K = Hash( M )

If we use the Hash() which is insecure in this setting, we should expect troubles in other application of this hash function: e.g. in digital signatures or MAC.

---

From: Werner Koch <[email-masked]>
Date: Sat, 25 Apr 2015 10:31:11 +0200

> (i.e. having an algorithm field like the other alogs).

|  3.7.1.  String-to-Key (S2K) Specifier Types
|  
|     [...]
|         3           Iterated and Salted S2K
|         100 to 110  Private/Experimental S2K

Salam-Shalom,

   Werner

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 19:10:56 +0200

> |         100 to 110  Private/Experimental S2K
Ah... sorry for the noise then :-)

It's already some time ago that I was more closely familiar with the RFC
and apparently I have forgotten some things O:-)

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 25 Apr 2015 17:57:57 +0000

>Ok, now I got the point, thanks :)

That's always been a major pain with PGP's PRF, for every other PRF in
existence you're given an iteration count and just iterate the PRF that many
times.  For PGP you're given a value encoded as some bizarro fixed-point
format crammed into a byte value (saving *three whole bytes* per message),
which you then have to reverse-engineer into an iteration count, which is what
the PRF actually works with (complicated by the fact that the byte count and
hash sizes typically don't match, so you end up having to special-case
handling around the leftover bytes at the end of the hashing process).

For the next PRF, I would hope that the iteration count is just a straight
int32 telling you how many times to cycle the PRF.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 25 Apr 2015 18:07:51 +0000

Jon Callas <[email-masked]> writes:

>I would love to see PBKDF2 in there on the list of things acceptable.

Don't go for PBKDF2, wait for the PHC to conclude (which it will have by the
time any new PGP RFC is ready) and use that.  The product of the PHC will be
pretty much the best that we can design at the current time, and I say that
not as propaganda from someone involved in it (although please note the
potential conflict of interest there) but because the designers who have
submitted entries have looked at everything else that's been done and improved
on it, which includes cross-pollinating ideas from other submissions into
their own.  The result is going to be a really, really good password-
processing function that's about the best that we can currently design in
terms of working over a wide range of environments while resisting specialised
attacks using GPUs and ASICs.  So all that a future PGP RFC needs to do is
leave a hole to slot in the PHC winner.

Peter.

---

From: Nicholas Cole <[email-masked]>
Date: Sat, 25 Apr 2015 22:02:55 +0100

> done by putting it into a v5 key packet.

I don't see the benefit of a hard expiration time.

More users should be encouraged to use expiration times, because that
would help to limit the problem of losing control of keys through
forgetting a passphrase (probably the most frequent AQ on the gnupg
users list).  It seems to me possible that so few do so because they
do not realize that expiration times can be changed.

Introducing a hard expiration time would introduce complexity because
there would then need to be two kinds -- hard and soft.

What are the use cases for a hard expiration time?

1. Perhaps an organization wishes to be sure that employee keys are
not used beyond a certain date.  If so, the answer already exists:
refuse to renew certifications of the UIDs on that key and make sure
that all certifications have an expiration date.

2. Enforcing key rotation.  But if this is important to individual
users, the answer is simply: set an expiration time on your key and
don't extend it.

3. Preventing an attacker who has gained complete control of a private
key, and who can prevent the dissemination of a revocation
certificate, from extending the life-time of a key, assuming that that
same attacker is not in a position to forge or coerce the creation of
a replacement key.

Scenario 3 is so niche (in fact, are there *any* documented cases of
this?) that I don't see the benefit of adding the complexity necessary
to support this.

Just my $0.02

---

From: Dominik Schuermann <[email-masked]>
Date: Mon, 27 Apr 2015 14:08:49 +0200

> I don't see the benefit of a hard expiration time.

Full ACK. I also don't see the need for hard expiration times.

For me soft expiration is a way that prevents the usage of keys after
a certain amount of time, e.g. one year, when the secret key has been
accidentally deleted or the passphrase has been forgotten. So - and
this is important - these use cases are not really attack scenarios
they only provide convenience for key distribution.

> 
> More users should be encouraged to use expiration times, because
> that would help to limit the problem of losing control of keys
> through forgetting a passphrase (probably the most frequent AQ on
> the gnupg users list).  It seems to me possible that so few do so
> because they do not realize that expiration times can be changed.
> 
> Introducing a hard expiration time would introduce complexity
> because there would then need to be two kinds -- hard and soft.
> 
> 1. Perhaps an organization wishes to be sure that employee keys
> are not used beyond a certain date.  If so, the answer already
> exists: refuse to renew certifications of the UIDs on that key and
> make sure that all certifications have an expiration date.

ACK

> users, the answer is simply: set an expiration time on your key
> and don't extend it.

ACK

> 
> 3. Preventing an attacker who has gained complete control of a
> private key, and who can prevent the dissemination of a revocation 
> certificate, from extending the life-time of a key, assuming that
> that same attacker is not in a position to forge or coerce the
> creation of a replacement key.

If one consider the average time that a key is still valid (5 years
expiration on key generation in Enigmail) so 2,5 years on average
valid from the time it got stolen by an attacker, the attacker has
enough time to do her "thing", e.g., forge signatures. The scenario
that an attacker needs to use the key after 2,5 years is totally
unrealistic. Thus, hard exp solves nothing.

Regards
Dominik

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 27 Apr 2015 16:15:58 +0200

> Full ACK. I also don't see the need for hard expiration times.
I don't quite understand why people lobby against a use case, which
wouldn't have an effect on any other use cases if people choose so.

It's like "I only use signing - so let's remove any encryption
capabilities from OpenPGP" o.O

> a certain amount of time
As I've outlaid before, it doesn't really prevent this.

Chris.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 27 Apr 2015 10:18:52 -0400

Jon,

> I think that hard-expiration is not only a bad idea, but unenforceable.

It was enforceable with V3 keys.  It is, as Christoph pointed out, no
longer enforceable with V4 keys because it was moved out of the Public
Key Packet and into the SelfSig.  :-(

> to do some really cool things with short lived keys.

This is a reason for SelfSigs to expire.  However if the key itself is
stolen/compromised the attacker could then create an updated SelfSig
with an updated expiration.

If the key itself had an expiration (as it did in v3) then this attack
wouldn't work.  But then it also means Alice would *have* to generate a
new key after the old key expired.  (Or, worst case, Alice would have to
regenerate a new Certificate using the same key parameters and then
obtain all those signatures again).

---

From: Dominik Schuermann <[email-masked]>
Date: Mon, 27 Apr 2015 16:23:40 +0200

On 04/27/2015 04:15 PM, Christoph Anton Mitterer wrote:
> I don't quite understand why people lobby against a use case,
> which wouldn't have an effect on any other use cases if people
> choose so.
> 

I am not arguing from a user's perspective, I am arguing from the
perspective of an implementor of the standard. More features, more
complexity. I want to see a use case before we put something in the
standard that everyone MUST implement.

> 
> 
>> For me soft expiration is a way that prevents the usage of keys
>> after a certain amount of time

Please read my email again. It does not prevent it when you consider
an attacker, but we are not talking about an attack scenario here. If
you think we are talking about an attack scenario, I like to here what
hard exp can do for us.

Regards
Dominik

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 27 Apr 2015 16:28:30 +0200

On Mon, 2015-04-27 at 10:18 -0400, Derek Atkins wrote: 
> But then it also means Alice would *have* to generate a
Just to point that out once more:
The later here is actually the feature of the whole idea.

And in just in order to calm down (once more) all the opponents of a
hard coded expiration time:
- having a hardcoded expiration time, does NOT mean, that people have to
  use it
  One could still let people choose during key creation what they
  want... one could even "hide" such feature behind something like
  gnupg's --export

- even though it's IMHO rather useless, one could still allow for "soft"
  expiration times, although - as mentioned previously - I'd rather do
  that simply via the expiration time of the self sigs

So nothing of the current functionality is lost.

Cheers,
Chris.

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 27 Apr 2015 10:29:56 -0400

HI,

On Mon, April 27, 2015 10:23 am, Dominik Schuermann wrote:
> Hash: SHA1

Unless you've removed support for V3 keys from your implementation then
you effectively already have this implemented.

> you think we are talking about an attack scenario, I like to here what

You are correct that the current v4+self-sig-sub-packet does not prevent
an attack where the private key gets compromised.  That's exactly why some
of us want to re-introduce key expiration in the key packet (ala v3). 
What it allows is the ability to say "this key cannot be used after date
X".  Even if an attacker gets the private key there is no way for them to
change that.

Of course, if an attacker does obtain the private key they could still
sign stuff as of "date X-1".  But eventually that stops working.

> Dominik
______________

-derek

---

From: Dominik Schuermann <[email-masked]>
Date: Mon, 27 Apr 2015 16:51:00 +0200

On 04/27/2015 04:29 PM, Derek Atkins wrote:
> Unless you've removed support for V3 keys from your implementation
> then you effectively already have this implemented.

We removed support for v3 keys in OpenKeychain.

> You are correct that the current v4+self-sig-sub-packet does not
> prevent an attack where the private key gets compromised.  That's
> exactly why some of us want to re-introduce key expiration in the
> key packet (ala v3). What it allows is the ability to say "this key
> cannot be used after date X".  Even if an attacker gets the private
> key there is no way for them to change that.
> 
> Of course, if an attacker does obtain the private key they could
> still sign stuff as of "date X-1".  But eventually that stops
> working.

2,5 years on average until a key expires, even if you would argue
setting the expiry time to 6 month, it's enough time for an attacker
to misuse the key, I just don't see attack scenario prevented by
having expiration dates.
As outlined before, I see soft expiration dates as a convenience
feature, not something that prevents attacks. Thus, hard expiration
makes no sense in my model.

Some argue that expiration helps invalidating old crypto, I disagree.
Using 512 bit RSA keys should be rejected by the client software, no
need to place expiration dates inside the key. This is actually
something we currently have on our TODO list for OpenKeychain.

Regards
Dominik

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 27 Apr 2015 16:57:37 +0200

On Mon, 2015-04-27 at 16:23 +0200, Dominik Schuermann wrote: 
> complexity.
Well... I don't think that this adds *that* much more complexity... it's
just one more field that needs to be set and read out...

> I want to see a use case before we put something in the
Please have a look at my previous posts on that matter, I already gave
some possible usage scenarios respectively "attacks".

> an attacker, but we are not talking about an attack scenario here.
Well but that's what needs to be talked about ^^

>  If
See previous mails.

Cheers,
Chris.

---

From: David Gil <[email-masked]>
Date: Mon, 27 Apr 2015 08:09:24 -0700

A hash function which is secure on short inputs may not be secure on long inputs. This is, indeed, the case (generically) for the MD and SHA-[12] functions: See papers by Schneier et al. inter alia.

At Apr 24, 2015, 11:06:40 PM, Andrey Jivsov wrote:
I stand corrected.

If we use the Hash() which is insecure in this setting, we should expect troubles in
other application of this hash function: e.g. in digital signatures or MAC.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 27 Apr 2015 17:11:56 +0200

> to misuse the key, I just don't see attack scenario prevented by
What speaks against keys that are just used e.g. for some weeks? You
could have them signed by other long-term keys, which are kept on
offline systems and are thus "more secure".

> Thus, hard expiration
Well as said before, just because you or I don't use a certain scenario
doesn't mean that it's invalid for everyone else.

> need to place expiration dates inside the key.
And what has the one thing to do with the other?
You could have created a 4096 bit RSA key 4 years ago, it would still be
considered "safe", even though the real owner may have abandoned it
and/or it may have been compromised long ago.
Since revocations are per se blockable, the peers of the key owner may
continue to use it forever.

Cheers,
Chris.

---

From: Werner Koch <[email-masked]>
Date: Mon, 27 Apr 2015 17:29:32 +0200

> you effectively already have this implemented.

He has a new implementation and I actually hope it can't handle v3.  I
don't view the increased complexity as a serious problem in this case.
Hard expiration time is easier to implement than the v4 soft-expiration
time.  Thus it adds only a small bit of additional complexity.

A quick local search showed that the hard expiration time must have been
discussed before 2001-09-05 (Florian Weimer) and raised again by Bodo
Moeller on 2003-03-06.

FWIW: I have no real preference pro or contra a hard expiration time.

Salam-Shalom,

   Werner

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 27 Apr 2015 14:12:04 -0700

On 04/27/2015 08:09 AM, David Gil wrote:
> A hash function which is secure on short inputs may not be secure on 
> long inputs. This is, indeed, the case (generically) for the MD and 
> SHA-[12] functions: See papers by Schneier et al. inter alia.
>

I didn't look at the paper (which one?), but you are saying that if I 
have SHA-2 signed e-mail, I can concatenate the same message and achieve 
some "insecurity". As attacker can exploit this insecurity by e.g. 
prep-ending signed PGP/MIME messages. Most higher-level uses of OpenPGP 
will probably simply drop duplicated PGP/MIME parts or TAR files, etc. 
Not only the collision resistance is a more difficult problem (and thus 
is easier to exploit), the attacker knows the message and the output, 
which is not the case for S2K.

My argument was that other parts of OpenPGP protocol will fail before 
S2K and we can count on the quick upgrade of the hash function.

Of course, one can similarly come up with hypothetical insecurities in 
PBKDF2, e.g. how it cripples the sponge construction due to iterative 
nature of PBKDF2 and shrinking the sponge state to the hash output in 
each iteration...

>     > On Fri, 24 Apr 2015 09:19, [email-masked]
>     <javascript:return> said:
>     >
>     If we use the Hash() which is insecure in this setting, we should
>     expect troubles in other application of this hash function: e.g.
>     in digital signatures or MAC.
>
>
>
>     [email-masked] <javascript:return>

---

From: "David Leon Gil" <[email-masked]>
Date: Mon, 27 Apr 2015 14:16:48 -0700 (PDT)

I am not advocating for the use of PBKDF2. It is not a particularly good KDF, though it avoids the defects of S2K.

There is one exception: At present, the WebCrypto API does not provide any good password hash, so PBKDF2 may be the only option for some apps.

Again: scrypt is widely used, BSD-licensed code in every language under the sun is available. and it is much better than S2K. Is there some reason *not to* use it?

—
Sent using alpine: an Alternatively Licensed Program for Internet News and Email

---

From: Jon Callas <[email-masked]>
Date: Mon, 27 Apr 2015 15:00:41 -0700

> On Apr 25, 2015, at 11:07 AM, Peter Gutmann <[email-masked]> wrote:
> 

...

> So all that a future PGP RFC needs to do is

Yeah. But we should have PBKDF2, as well -- or perhaps more completely PBKDF2-HMAC-<algorithm>, since PBKDF2 is a wrapper around any PRF. PBKDF2 is the devil you know. It behaves in completely reasonable, completely understood ways. And it doesn't have the wackiness of the present S2K.

	Jon

---

From: Nicholas Cole <[email-masked]>
Date: Mon, 27 Apr 2015 23:29:16 +0100

> FWIW: I have no real preference pro or contra a hard expiration time.

I have not seen anyone in favour of a hard expiration time explain
what it is designed to prevent / enable. I think the new standard
should have a real prejudice in favour of excluding anything unless
there is a clear justification.  It could be that I've just missed
something, but I don't think that standard has been reached here yet.

What does a hard expiration time technically achieve that a soft
expiration time does not.

If the answer is encouraging the user to behave in a particular way,
that should be enforced / encouraged through other means.  I see no
security advantage at all.  As I say, I may be missing something.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 28 Apr 2015 00:43:31 +0200

> expiration time does not.
This has been explained now several times, by several people.

---

From: Jon Callas <[email-masked]>
Date: Mon, 27 Apr 2015 17:43:13 -0700

> Key Packet and into the SelfSig.  :-(

I'm well aware of this, Derek. I'm saying that hard expiration is in my opinion not only impossible even with V3 keys (just rewrite everything), but a bad idea.

> obtain all those signatures again).

Yeah, and I'm saying that think the current behavior is a good thing, all in all. Gentlepersons can disagree on this, I'm just giving my opinion.

	Jon

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 28 Apr 2015 03:34:45 +0200

On Mon, 2015-04-27 at 17:43 -0700, Jon Callas wrote:
> I'm saying that hard expiration is in my opinion not only impossible
> even with V3 keys (just rewrite everything), but a bad idea.
Can you please explain both?
While the later may be a matter of taste, I can quite see why it
shouldn't be possible.
If the expiration date is part of the key, the FP and other signatures
should change / become invalid as soon as anyone tries to change the
time. 

Cheers,
Chris.

---

From: Werner Koch <[email-masked]>
Date: Tue, 28 Apr 2015 09:01:46 +0200

On Tue, 28 Apr 2015 00:00, [email-masked] said:

> Yeah. But we should have PBKDF2, as well -- or perhaps more completely
> PBKDF2-HMAC-<algorithm>, since PBKDF2 is a wrapper around any
> PRF. PBKDF2 is the devil you know. It behaves in completely

You may be right on this.  However, for backward compatibility it is
anyway required to implement S2K.  Thus I consider it better to wait for
the outcome of the PHC and make one of winners the MUST algorithm while
keeping S2K-3 as a MAY algorithm for backward compatibility
(symmetrically encrypted messages).

Shalom-Salam,

   Werner

---

From: ianG <[email-masked]>
Date: Tue, 28 Apr 2015 12:51:19 +0100

Just to echo what Jon said...

> Because you want the key owner to issue a signed statement that says "this is how I want you to use my key" and you want that to be part of the self-signature that says "I own this key." You don't…

This is getting into the nature of what a real WoT looks like.  In 
normal human conversational semantics, a statement is meaningless unless 
it is backed by whosoever said it, and what foundation we've got to 
believe (rely on) that statement.  Unless we can mirror those human 
lines of trust, the system is approximately worthless for a real WoT.

This of course assumes that the goal is a WoT.  There may be of course 
other practical reasons for doing things such as having the key usage & 
flags in the inner signed key package.  Which is to say, it's important 
to frame the question with the goals...  and some of us hold out hope 
for building a real WoT one day.

> Let's face it. Revocation is not as good as people think it is. In the general case it cannot work. There are specific cases where it can work, but you must always account for the case that there is revocation information, you're just not getting it....

That's a pretty good statement.

Revocation as an algorithm is too unreliable to be relied upon, and we 
now have scientific proof of that [0].  What is the role of a 
cryptographically unreliable algorithm in our thinking?  Normally we run 
a mile from such things, why do we pander to it this time?

iang

[0] By that I mean, back in the 2000s, CA/PKI's revocation was predicted 
to not be reliable enough to work well enough to be worth the effort, 
and when subCAs started failing a few years back, the browser vendors 
found it necessary to start shipping new browser distros with hard-coded 
revocation lists in them.  In essence, we are seeing the über-CAs move 
to doing dynamic revocation within the browsers, but they don't call it 
that, nor do they admit that they are CAs.

---

From: ianG <[email-masked]>
Date: Tue, 28 Apr 2015 13:15:46 +0100

> Let's consider a machine that has a set of simple operations that it can do, like IF-GOTO and another language that did more complex things like IF-THEN-ELSE. If we could make something that could…

Right.  As an analogy, this is the trap that the bitcoin folks are 
falling into.  They believe that because they can express complicated 
transaction flows in a program, they have encapsulated the contract or 
agreement between folks.

They haven't, what they've achieved is the performance of a contract 
only, not the entire contract.  The wider contract also includes 
semantics & exceptions, and these cannot typically be coded into a 
language other than the natural language that the humans use in forming 
their agreement.

Sadly, it seems that human level semantics will remain in wordage, and 
agent-level performance will be limited to code.  The two should work 
together.  Which is why in the CA/PKI world there is a fairly clear 
separation between the technology and the documentation;  the two are 
supposed to walk hand in hand, and they are supposed to cover distinct 
areas of the agreement.  It is this latter documentation aspect -- e.g., 
the EULA which should point to PKI's CPS -- that the OpenPGP world is 
lacking in its thought process.

To bring it back to the technology level: an assertion made in OpenPGP 
that doesn't also in some reliable way point to the doco tree that 
grounds the statement is approximately worthless.

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 09:10:10 -0400

On Tue, Apr 28, 2015 at 8:15 AM, ianG <[email-masked]> wrote:
>> Let's consider a machine that has a set of simple operations that it can
>> do, like IF-GOTO and another language that did more complex things like
>> IF-THEN-ELSE. If we could make something that could take the complex
>> language and translate it into a set of the simpler statements reliably,
>> then perhaps we could solve that problem.
>
>
>
> Right.  As an analogy, this is the trap that the bitcoin folks are falling
> into.  They believe that because they can express complicated transaction
> flows in a program, they have encapsulated the contract or agreement between
> folks.
>
> They haven't, what they've achieved is the performance of a contract only,
> not the entire contract.  The wider contract also includes semantics &
> exceptions, and these cannot typically be coded into a language other than
> the natural language that the humans use in forming their agreement.
>
> supposed to walk hand in hand, and they are supposed to cover distinct areas
> of the agreement.  It is this latter documentation aspect -- e.g., the EULA
> which should point to PKI's CPS -- that the OpenPGP world is lacking in its
> thought process.
>
> To bring it back to the technology level: an assertion made in OpenPGP that
> doesn't also in some reliable way point to the doco tree that grounds the
> statement is approximately worthless.

This is the reason for the Conditions section in SAML. It provides a
mechanism for imposing constraints like acceptance of terms.

---

From: Derek Atkins <[email-masked]>
Date: Tue, 28 Apr 2015 10:01:46 -0400

Hi,

> something, but I don't think that standard has been reached here yet.

You have seen them.  You've just ignored them.

It prevents someone who gains access to your private key the ability to
keep your public key going past your pre-selected expiration time.
Using soft expiration doesn't help in this case because the attacker has
access to your private key and could, as a result, issue additional
self-sigs with extended expirations.

> expiration time does not.

The above.

If you want to reuse your key material in a new key/certificate you can,
but it would be considered a completely "new key" so existing signatures
would be invalid.  That's the goal.

> security advantage at all.  As I say, I may be missing something.

No, it has nothing to do with encouraging specific behavior.  But if you
don't see a security advantage then you're either not looking or not
reading.

-derek, who should have paid more attention during the V4 key designs,
        but was probably on PGP Hiatus at the time.
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Tue, 28 Apr 2015 10:04:39 -0400

Jon Callas <[email-masked]> writes:

> I'm well aware of this, Derek. I'm saying that hard expiration is in
> my opinion not only impossible even with V3 keys (just rewrite
> everything), but a bad idea.

Rewriting means that all the signatures on your key become invalid.
It's effectively a completely "new" key/certificate.  Sure, there is
nothing to prevent a user (or an attacker) from doing that (reusing key
material), but then they would have to go out and social engineer
certificate signatures in order to gain trust for the "new" key.

> Yeah, and I'm saying that think the current behavior is a good thing,
> all in all. Gentlepersons can disagree on this, I'm just giving my
> opinion.

Of course.  And in many use cases that's probably sufficient.  I see use
cases where it is not sufficient so I'd like to re-gain that feature.

-derek

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 11:36:38 -0400

> cases where it is not sufficient so I'd like to re-gain that feature.

I think this is a use case but a distinct usecase from the usual
interpretation of fingerprint on a businesscard.

We need a range of fingerprints for different purposes and that is why
I want to have the content-type to be part of the data that is being
hashed.

One use case is to create a persistent identifier that is indexical to
a public key they are the holder of. This form of identifier can be a
'life long' identity that is immutable and can be depended no not to
change even though the holders name (marriage) and email address are
likely to.

The way to address that use case is to hash a public key and algorithm
identifier and absolutely nothing else and if the identity is going to
last a lifetime you probably want that to be just a signature key for
an offline root.

If the syntax is PKIX then this would be application/pkix-keyinfo. For
PGP the content type application/pgp-keyinfo probably makes sense.

Another use case is to introduce a key that is going to be used to
execute contracts. Here my preferred mechanism would be SAML because
that is what the assertion infrastructure was originally architected
to support.

I can see applications that fall short of binding contracts where it
makes sense to expire the fingerprint and to bind it to both an
expiration date and a subject identity.

If the syntax is PKIX then this would be application/pkix-cert. For
PGP the content type application/pgp-keysigning probably makes sense.

Long term I would want to redo SAML with {} instead of <> and the
result would probably be something like application/json-assertion.
But that is currently at the research stage.

Yet another use for fingerprint technology is in exchanging and
displaying status of append only logs. Over the past couple of weeks I
have been looking into that and the results are very encouraging. JSON
sequences work extremely well. Much better than might have been hoped.

Lets say you go past a billboard in Times Square New York that has a
fingerprint on it. You look at your watch and you can see that its the
same as the hash of last night's closure on the blockchain. If it is
different then you know that someone, somewhere is doing something
dishonest or they have messed up big. Important information either
way.

The fact that your watch has the same closure as everyone else is
demonstration that your entire personal digital infrastructure is in
sync with the consensus.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 28 Apr 2015 17:59:00 +0200

> I want to have the content-type to be part of the data that is being

Maybe it's just me but you seem to often mix up different topics...

What has the question of hard expiration times to do with the
fingerprint formats, content-types or fingerprint use cases?

> last a lifetime you probably want that to be just a signature key for

With that alone you make hard expiration times impossible, and open the
window for attacks based on the expiration time not being hard.

> But that is currently at the research stage.

All of that goes seems to go way beyond the scope of OpenPGP.
We're a generic crypto message format... I don't think we shold mix
OpenPGP with 3rd party protocols, unless these are really *basic*
(things like BASE32).

> displaying status of append only logs.

None of our business,... these are higher level apps which may use our
stuff..
We need to provide the means for
- encryption
- signing / authentication / etc.
- timestamping
- certifying different kinds of identities (names, images, birthdays,
  etc.)
- build trust networks respectively relate the different identities
- revocation, expiration
- extensibility of the message format
and things like these.

But it's not our business to make special things form mail, SAML, and so
on.

Cheers,
Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 12:07:49 -0400

> fingerprint formats, content-types or fingerprint use cases?

Derek and Jon are both discussing opposed use cases within OpenPGP
scope. I am pointing out that we are discussing one special case of
what should be a generic mechanism.

While IETF charters are narrow, we are also supposed to be looking for
ways to work with other IETF groups and make our work as useful as
possible to other groups.

Charter fetishes really don't help. Especially when we don't have a charter yet.

Putting the MIME content type in the data to be digested is the right
approach for OpenPGP and the right approach for IETF in general.

---

From: Nils Durner <[email-masked]>
Date: Tue, 28 Apr 2015 19:55:34 +0200

> [...]  Thus I consider it better to wait for
> the outcome of the PHC

I agree; and I'm not convinced a future standard should be built on past
technology - apart from being for the sake of backwards compatibility.
The PBKDF2 argument is today's version of a 2000's "AES is fine and
well, but we should also include DESede - it's the devil you know".

Besides that, what do others think about OpenPGP's variant of CFB - in
particular the computationally cheap oracle it entails? Should it also
be updated, perhaps with an authenticating cipher mode which might also
kill the MDC birdie with the same stone?
With the CAESAR competition conclusion being a bit more down the road -
end of 2017 - what would a suitable AE mode be?

Regards,

Nils

---

From: Werner Koch <[email-masked]>
Date: Tue, 28 Apr 2015 21:11:43 +0200

> be updated, perhaps with an authenticating cipher mode which might also

That is already on the list.  See for example AEAD at
https://wiki.gnupg.org/rfc4880bis

> end of 2017 - what would a suitable AE mode be?

Is it correct that the outcome of that competition might be a non-online
algorithm, meaning it it can't be used in a streaming mode (pipeline)?

Shalom-Salam,

   Werner

---

From: Nils Durner <[email-masked]>
Date: Tue, 28 Apr 2015 22:54:31 +0200

>> [OpenPGP CFB replacement]

ah, thanks!

> algorithm, meaning it it can't be used in a streaming mode (pipeline)?

This is not a stated requirement as per the Call for Submissions, that's
right. NORX is an online candidate, but I cannot say if there are any
other non-online ciphers in the lineup.

Regards,

Nils

---

From: David Gil <[email-masked]>
Date: Tue, 28 Apr 2015 21:32:29 +0000 (UTC)

There isn't any particular need to wait for the outcome of CAESAR on this one: SIV mode has been standardized, and is appropriate for messages. (In particular, it is a misuse-resistant / "robust" AEAD mode.)
I would consider streaming encryption as entirely out of scope for this WG. - dlg

     On Tuesday, April 28, 2015 1:57 PM, Nils Durner <[email-masked]> wrote:

ah, thanks!

Regards,

Nils

---

From: David Leon Gil <[email-masked]>
Date: Tue, 28 Apr 2015 21:51:32 -0700

(I think I emailed about this already, but from an account which gets
dropped by DMARC policy.)

There is a perfectly good (standardized even!) robust authenticated
encryption mode: SIV.

A nonce-length of 128-bits (which you get using a 128-bit block
cipher) is rather short, but note that for asymmetric encryption
modes, a new key is used per message.

I think that streaming encryption is well outside the scope of this
WG. Is there some compelling argument that it is required for
encrypting email messages?

---

From: David Leon Gil <[email-masked]>
Date: Tue, 28 Apr 2015 21:56:36 -0700

> (symmetrically encrypted messages).

I agree, but only to the extent that the language is limited to
decryption. E.g.:

An implementation MAY decrypt SKESKs using the deprecated S2K
algorithm, but MUST NOT create new SKESKs using those algorithms.

---

From: Werner Koch <[email-masked]>
Date: Wed, 29 Apr 2015 08:15:32 +0200

> encrypting email messages?

OpenPGP is not only for email but even for that it is important.  Being
able to process data in one pass is a MUST.  It has actually been a
design criteria for all core IETF protocols.  Think only about backups.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Wed, 29 Apr 2015 08:16:39 +0200

> algorithm, but MUST NOT create new SKESKs using those algorithms.

Nope.  That depends on the capabilities of the recipient.

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Wed, 29 Apr 2015 10:02:36 -0400

Phillip,

> approach for OpenPGP and the right approach for IETF in general.

You are still, as Christoph pointed out, mixing topics.  I think we all
would appreciate it if you kept to the thread topics, or at least make
it clear how and why you are jumping ship.

On the face of it, talking about hard expiration times has NOTHING to do
with fingerprint formats.  It is, however, tangentially related only
because part of what Jon and I are discussing is whether the (OPTIONAL!)
hard expiration time should be in a portion of the data structure that
gets included in signature and fingerprint calculations.

Now, whether the user decides to use that optional feature is, of
course, up to the user.  If they choose not to (i.e., leave it at 0)
then the fingerprint (and signatures) would cover the key material
forever.  However if they DO decide to use the feature (and set an
expiration time) then the fingerprint would change if someone tried to
manipulate that expiration time (also invalidating all existing
signatures).

<with my former chair hat on>
Still, this discussion is absolutely completely orthogonal to
fingerprint output formats, using text or image representations, or
whether to include a checksum in the (printed) fingerprint.  For these
types of discussions please use a different thread.
</...hat off>

Thanks,

-derek

---

From: Derek Atkins <[email-masked]>
Date: Wed, 29 Apr 2015 10:08:28 -0400

> design criteria for all core IETF protocols.  Think only about backups.

+1.

Streaming data has been and always should be in-scope for OpenPGP.

---

From: David Leon Gil <[email-masked]>
Date: Wed, 29 Apr 2015 14:15:11 +0000

A SHOULD NOT might be more appropriate in this case.

---

From: David Leon Gil <[email-masked]>
Date: Wed, 29 Apr 2015 14:18:19 +0000

I think that both I and Tom Ritter have previously linked to Adam Langley's
post on this: Doing this right requires 'packetizing' data and computing
partial authenticators.

I also am not sure how backups are in scope for a network working group...
Is there something I'm missing?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Apr 2015 10:36:50 -0400

> gets included in signature and fingerprint calculations.

The reason I raised fingerprints is that it is the only thing that
causes it to make a difference.

Precise language is critical. You were confusing people when you
talked about expiring a key. That is impossible for the reason Jon
points out.

Using the terms 'key' and 'key binding assertion' interchangeably
leads to confusion.

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 29 Apr 2015 11:05:24 -0400

Phill,

> On Wed, Apr 29, 2015 at 10:02 AM, Derek Atkins <[email-masked]> wrote:
[snip]
> causes it to make a difference.

Not exactly.  It also would affect all signatures on the key.

> talked about expiring a key. That is impossible for the reason Jon

If by "key" you purely mean the "N,e" values (in RSA terms) then yes, you
are correct that there is absolutely no way to revoke a key.  (PS: I call
this the "key material" specifically to be precise)  However if you embed
the expiration time into the Key Packet (see below) then you CAN cause a
validator to raise questions about potentially "bad" signatures if your
private key data gets compromised because any signatures made after the
"hard expiration" would be considered invalid.

For example, what would you do if you saw a signature dated 2014-12-31 on
a key that claimed it was generated on 2015-04-01?  (Note that the
generation date *IS* still included in V4, and therefore included in
fingerprint/keyid/signature calculations).

So yes, while you could still reuse the "key materal" in a new "key"
(again, see below for nomenclature), if we returned the hard expiration
value (ala V3) then it would be a "different" key, which a distinct
keyid/fingerprint.  It means the WoT would do its job (existing signatures
would not apply to the "new" key with the "old" (copied) key material. 
And signatures made with the new key would either use the new keyid (going
back to the WoT non-verified key) or, if they tried to fake it as use the
original keyid would revert back to my argument of the previous paragraph,
where the dates would need to be forged too which, eventually, stop making
sense.

I suppose we could raise the question, what is the definition of "revoked"?

> Using the terms 'key' and 'key binding assertion' interchangeably

I've not been using those terms interchangeably.   If I have please refer
me to my messages where I did so I can make sure I clarify my statements.

For the record, when I say "Key" I mean the OpenPGP Public Key Packet
(c.f. RFC4880 sec 5.5.2).  When I say "key binding assertion" (which I
really don't -- I use the phrase "signature" or "selfsig") I am referring
to... a signature.  ala RFC4880 sec 5.2).

Thanks,

-derek

---

From: Nicholas Cole <[email-masked]>
Date: Wed, 29 Apr 2015 16:12:07 +0100

> self-sigs with extended expirations.

No. I haven't ignored them.  What you cut out of my email was the
point I made that assuming an attacker is in a position to forge or
coerce an extension of the key expiration time but would not be in a
position to forge or coerce a new key is a very niche model of an
attacker.   That was the point I made.  Unless you think that scenario
is likely, I am against adding complexity to the new standard, even if
it is small complexity.

Please don't tell me I ignored something I didn't.  I completely
understand the *technical* point being made. What I do not understand
is whether the use-case is realistic.

Has there *ever* been a confirmed attack that this feature would have prevented?

N.

---

From: Nils Durner <[email-masked]>
Date: Wed, 29 Apr 2015 18:24:38 +0200

> I also am not sure how backups are in scope for a network working
> group... Is there something I'm missing?

My application of OpenPGP is encryption of data at rest on potentially
memory constrained devices for storage in the cloud.
So +1 for streaming.

Regards,

Nils

---

From: Nils Durner <[email-masked]>
Date: Wed, 29 Apr 2015 18:32:48 +0200

>     Nope.  That depends on the capabilities of the recipient.

OpenPGP currently offers great compatibility/interoperability. That's
not something I would want to see given away simply because S2K-3 is not
perceived hype-du-jour compliant without being an actual security problem.

+1 for S2K-3 as MAY algo

Regards,

Nils

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Apr 2015 13:13:56 -0400

> fingerprint/keyid/signature calculations).

That is precisely why I would not call that a key.

There are two possibilities:

1) A new Key Packet was created that reused an existing key
2) The signature is making a false claim.

There are protocols that allow the generation time of keys to be
established with certainty within tightly controlled bounds.
Specifically, not before one block chain output and not after another.

Possibility (1) does occur by accident rather too often. Specifically
when an insufficiently random pool is used to generate the key :( One
of the things we discovered doing XKMS was that there was a ridiculous
number of duplicates for certain keys...

Now if you include the fingerprint of the KeyPacket within the scope
of the signature, this issue does not occur. Alternatively you can fix
the date of a signature exactly via a blockchain.

> I suppose we could raise the question, what is the definition of "revoked"?

Again, I would assert that it is a statement about a certificate, key
packet, key assertion, etc. and not actually a key.

---

From: Werner Koch <[email-masked]>
Date: Thu, 30 Apr 2015 10:01:19 +0200

> post on this: Doing this right requires 'packetizing' data and computing

IIRC, that is about "cat foo | decrypt | tar xf -"

There are lot of reasons why storing data on a system may fail.  It does
not help if you are early notified about tampered data instead of
checking that after having processed all data.  For example an attacker
might tamper with the last blocks of the data and your intermittent
checks won't help at all.

Using Unix tools requires workmanship.  Unix is a set of tools which are
very powerful if used right.  For example for using above quoted
pipeline you need to make sure several things: For example, is your tar
safe and does not follow ".." file name parts.  Of course you unpack
into a freshly created subdirectory to avoid cluttering the current
directory.  You need to check that all tools finished with success, have
all kind of extra checks applied to verify signatures during "decrypt",
and only then to the mv dance to replace old data by the freshly untared
one.

Remember: Unix is a user-friendly; it is just picky with whom it chooses
to be friends.

I would also like to a have a random access encrypted data format option
but I doubt that this should be the goal of OpenPGP.

Salam-Shalom,

   Werner