Subject: [openpgp] Key Validity Scenarios

From: Vincent Breitmoser <[email-masked]>
Date: Tue, 05 May 2015 22:04:20 +0200

Bringing up a topic related to expirations, one thing that has bothered
me for a while is that the validity periods of keys, in terms of
expiration and revocation, are very ambiguous.

Consider these scenarios:

- Key expired two weeks ago. Status of a signature from three weeks ago?

- Key revoked two weeks ago, because it was compromised. Status of a
  signature from three weeks ago?

- Key revoked two weeks ago, because no reason given. Status of a
  signature from three weeks ago?

- Key revoked two weeks ago, because it was superseded. Status of a
  signature from three weeks ago?

It's possible to argue for all extremes in all of these scenarios, and
the conservative choice would always be to reject the signature, however
this is not necessarily applicable for all implementation circumstances.

So the possibilities here are:

a) try to cover the key validity for most scenarios in the standard.
this seems tricky because I don't think all needs can be covered.

b) leave the main standard purely focused on data format, but add an
informational one with this sort of definitions.

c) add an explicit definition about treatment of retrograde signatures
to the expiration and revocation signatures themselves, i.e. delegate to
the implementation which creates the key.

d) none of the above, i.e. leave it to the implementation which uses the
key.

I'd like b), but that one implies a bunch of extra work.

 - V

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 06 May 2015 01:42:32 +0200

> expiration and revocation, are very ambiguous.
Well that's one of the points I've mentioned in my original wishlist:
While I don't think we should overly aggressive define trust models,
some of the questions you answer are not well defined, so one can
basically only hope that the implementation makes a sane choice.

But such ambiguities always leave up some space for meta-level attacks,
social engineering and so on.

> - Key expired two weeks ago. Status of a signature from three weeks ago?
IMHO not well defined.
One may e.g. choose to consider the signature still valid, but not the
key... and e.g. an implementation may then say "valid signature from a
trusted but expired key".
In addition it may e.g. make some "guess"... like when they expiration
is 5 days ago it may just print the warning... but if it was 10 years
ago it would start to flash the screen like mad and play alert sirens at
all sound devices.

One clearly sees... nothing well defined... quite ambiguous.

>   signature from three weeks ago?
Not sure whether it's formally standardised, but it's clear that the
signature needs to be considered invalid in any case, as the attacker
can of course forge any date.

>   signature from three weeks ago?
Again... not defined.
I (personally) would probably say that in case of "no reason given" one
must assume the worst case (key compromise - the revocation certs may
have been created for that purpose at the key creation, but without a
reason, since it wasn't known yet).
So same as directly above.

>   signature from three weeks ago?
As above.... not well defined.
I'd probably choose something like the first paragraph above.

> informational one with this sort of definitions.
I have no strong opinion whether such definitions should be part of the
"core RFC", but they should be definitely standard and mandatory
defined.
The reason is simply that people may actually depend their security on
such things being used/interpreted as they should (whatever that is).

Cheers,
Chris.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 6 May 2015 07:31:09 -0700

On 5/6/15 at 4:42 PM, [email-masked] (Christoph Anton 

>ago it would start to flash the screen like mad and play alert sirens at

This answer is clearly wrong for several useful scenarios. For example:

I am looking at a ten year old audit report for a company 
prepared by an audit firm. The audit firm signed it with their 
then-current key, which they change regularly, following "best 
industry practices". It is not a red light alert for the key to 
be expired. It is not a red light alert for the data to be old. 
The only time an alert is justified is when the key expired 
before the signature was made.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 May 2015 11:07:07 -0400

We have been going round on the question of how to validate a
signature for 25 years now. I have yet to see a rigorous approach with
S/MIME or PGP and I suspect that is because it is impossible to
address the problem using just a signature. But the problem can be
addressed quite easily with a blockchain approach.

The first thing to do is to draw up a lifecycle for the keybinding as
a finite state machine:

[Valid]
     Expire -> [Expired]
     Revoke -> [Revoked]

[Expired]
      Revoke -> [Revoked]

The next thing to do is to decide why you are checking the signature:

1) To see if the key holder still backs an assertion
2) To see if the key holder backed an assertion at the time the
signature was created
3) To see if the key holder backed an assertion at the time the
signature was received

The mapping of these criteria to the state machine states is pretty
straightforward.

If we are checking key signings, certificate chains, SAML assertions,
etc. we have a type 1 problem. If we are checking a contract in an
archive system then we have a type 2 problem. But for email, we have a
type 3 situation.

Working with existing infrastructure, the way to check the signature
of PGP mail would be to look at the time the message was received.

The way to solve the problem comprehensively is to intern all key
bindings and signatures in an unforgeable notary log as they are
created.

---

From: ianG <[email-masked]>
Date: Thu, 07 May 2015 13:21:12 +0100

You're talking about the status of signatures for the purpose of human 
signing, not keys nor digsigs.

Such things as human signing digsigs can only be assumed / used within 
some form of context.  Such a context could be a CPS or a contractual 
agreement (eg rules of keysigning party) or a cooperative (eg CAcert) or 
a law (eg Estonia & EU Directive).  Without such an approach, the notion 
of human signing lacks foundation.  With such an approach, it is up to 
the approach to decide what the status of signatures for human signing is.

In other words, it is out of scope of OpenPGP as it is currently 
constructed.

iang

> I'd like b), but that one implies a bunch of extra work.

So, yes, b).  BUt old chinese proverb:  be careful what you wish for!

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 May 2015 10:53:42 -0400

On Thu, May 7, 2015 at 8:21 AM, ianG <[email-masked]> wrote:
> Such things as human signing digsigs can only be assumed / used within some
> form of context.  Such a context could be a CPS or a contractual agreement
> (eg rules of keysigning party) or a cooperative (eg CAcert) or a law (eg
> Estonia & EU Directive).  Without such an approach, the notion of human
> signing lacks foundation.  With such an approach, it is up to the approach
> to decide what the status of signatures for human signing is.
>

It is out of scope. But we don't really understand what that scope is right now.

My vision for IETF next generation public key apparatus is that we
should arrive at a next generation system round about 2020 that offers
a superset of the capabilities of PKIX, OpenPGP and SAML.

I don't expect that to be a single consistent infrastructure. In fact,
I think it is going to look very much like electrical plugs do today
with different countries having different shaped plugs, different
voltages and different frequencies. And that is going to have long
term consequences for applications in that I think we are going to
have to accept that the equivalent of 'switching power supplies' is
going to be required.

If you want to use an infrastructure for using digital signatures on
transaction documents then you should look at the SAML assertion
infrastructure. That is what the assertion layer was designed to do.

At this point I do not want to redo SAML-lite in OpenPGP. Nor do I
want to invest further effort in XML or ASN.1. While they are both
capable of supporting the necessary features, they are clearly not
capable of achieving an industry wide consensus.

So right now what I would like us to focus on in developing a well
defined specification for an OpenPGP 'wall socket' that people can
plug an email messaging application into.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 08 May 2015 00:44:13 -0400

Hi Vincent--

> expiration and revocation, are very ambiguous.

Thanks for raising this.

Your subject line is about "key validity", but all your scenarios below
are about "signature validity".

Much of this is covered in the "Reason for Revocation" section of RFC
4880 already:

  https://tools.ietf.org/html/rfc4880#section-5.2.3.23

> - Key expired two weeks ago. Status of a signature from three weeks ago?

This is a "valid signature from an expired key", which means "the
keyholder made this assertion with their key at a time that the key was
legitimate for them to use."

>   signature from three weeks ago?

This is an "invalid signature", because it was made with a compromised
key.  Compromised keys can forge any date they like in the signature, so
nothing about them can be relied on.

>   signature from three weeks ago?

This is also an "invalid signature".  if no reason was given, we should
assume the worst.

>   signature from three weeks ago?

This is a "valid signature from a revoked key", which means "the
keyholder made this assertion with their key at a time that the key was
legitimate for them to use."

Note that there are really only two cases here, given that the signing
key (whether revoked or expired) is considered not currently valid.

The two cases are:

 a) invalid signature (should never be relied on for anything)
 b) valid signature from a no-longer-valid key

It's pretty straightforward to dismiss signatures that fall into
category (a).

It is harder to know generically what to do what to do with signatures
in category (b), because that gets into "trust models".  Trust models
are attempts to formalize/standardize who should be willing to rely on
which cryptographic assertions for what purpose.

So dealing with a signature from category (b), how i would interpret it
would very much depends on what the signature was (data signature over
signed e-mail?  identity certification?  authorization statement
delegating access to a service?), who the keyholder is, and what
question i'm trying to answer by reviewing the signature.  It might also
depend on how much time was elapsed, and other human factors that might
not be directly implementable in software.

hth,

        --dkg