Subject: Re: [openpgp] rfc3880bis - hard expiration time

From: Derek Atkins <[email-masked]>
Date: Mon, 04 May 2015 09:20:42 -0400

Phillip Hallam-Baker <[email-masked]> writes:

>> 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).
>
> That is precisely why I would not call that a key.

Sorry, but that horse has already left the barn.  This is precisely
OpenPGP nomenclature.  A Key is a packet that contains a set of data,
part of which is what I would call the "Key Material" but it also
includes other data.

> There are two possibilities:
>
> 1) A new Key Packet was created that reused an existing key

Let's use correct OpenPGP nomenclature, please.  A new Key was created
that reused existing key material.  I'll point out that this can happen
using any protocol.  Indeed, I've reused key material for my X509 certs
too (at least before Heartbleed -- I've regenerated them all since
then).

> 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.

Please stop conflating fingerprint and signatures; they are two separate
things.  However you are correct in that the data included in the
fingerprint hash is also included in signature hash.  This is why you
either get both or neither.

Using the V3 Key format, if you reuse the key material and change the
expiration date then you have just changed the data going into the
fingerprint and signature hashes, which means you change the fingerprint
and invalidate all hashes.  Using the V4 Key format this is not the case
because the expiration date is no longer in the Key, but got moved into
the SelfSig.

>> 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.

You're thinking in X509 terms.  This is OpenPGP.  The terms *are*
different, as well as the ability to encode and do things.
Particularly, in OpenPGP you *can* have a Key (which obviously includes
its key material) without a Signature, and that *IS* a valid data
structure (although I would propose that most people wouldn't trust it).

-derek

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

---

From: Derek Atkins <[email-masked]>
Date: Mon, 04 May 2015 09:26:11 -0400

Nicholas Cole <[email-masked]> writes:

> On Tue, Apr 28, 2015 at 3:01 PM, Derek Atkins <[email-masked]> wrote:
>> Hi,
>>
>> Nicholas Cole <[email-masked]> writes:
>>
>>> On Mon, Apr 27, 2015 at 4:29 PM, Werner Koch <[email-masked]> wrote:
>>>
>>>> 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.
>>
>> 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.
>
> 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.

I don't see it as a niche at all.  It's quite possible for an attacker
to have obtained the secret key without the user being aware.  They
could have spent the resources to factor N (for RSA) or surrepticiously
obtained a backup data and determined the users' passphrase.  None of
these positions would put the attacker into a position to cause the
original user to generate a new key.

If you mean that they could generate a new OpenPGP Key Packet using the
same Key Material, you are correct...  Anyone could do that, even
without the secret data.  However, in the case of V3 keys doing so would
change the fingerprint and invalidate all existing signatures.  So it's
no different than an attacker generating a new key with your email
address and posting it to the keyserver to say she is you.

However with V4, an attacker with access to the secret material COULD
create a new SelfSig with an extended expiration.  This is a very
different (and expanded) attack surface, becuase it means they could
take over your existing Key+Signature/Certificate, precisely because
changing the expiration does NOT invalidate all existing signatures on
the Key.

> 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.

It is absolutely realistic!

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

Yes.

> N.

-derek

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 May 2015 10:43:38 -0400

> part of which is what I would call the "Key Material" but it also

It is not the nomenclature of the field.

People are getting confused. And no wonder. People don't know if what
you are talking about is a public key or a PGP 'key'. And you seem to
be getting confused yourself.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 04 May 2015 16:48:31 +0200

> be getting confused yourself.

Unfortunately "key" is used in many contexts, but I think that David is
right and that one must at least assume it to be the term that means key
material + UIDs etc.

Anyway... do we really need to nitpick about that question? o.O

Cheers,
Chris.

---

From: Nicholas Cole <[email-masked]>
Date: Mon, 4 May 2015 16:02:47 +0100

On Mon, May 4, 2015 at 2:26 PM, Derek Atkins <[email-masked]> wrote:

[snip]

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

Citation please?

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 4 May 2015 11:09:52 -0400

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

I'm afraid I am not at liberty to disclose that information.  Sorry.

However even back in 1993 there were projects to test the strength of PGP
Key Material based on factoring attacks.  The RSA-129 project came about
through one of those discussions, and I seem to recall that at least one
RSA Key was factored after RSA-129.   I don't have a reference for that
effort (and my google fu isn't working immediately).

-derek

---

From: Derek Atkins <[email-masked]>
Date: Tue, 05 May 2015 09:43:52 -0400

> It is not the nomenclature of the field.

Umm, it is exactly the nomenclature PGP/OpenPGP has been using since,
oh, 1992.  It may not match the X509/PKIX world, but lucky for us we
don't have to do that.  :-D

> be getting confused yourself.

No, I know exactly what I'm talking about, but trying to explain it to
people that don't innately grok the (Open)PGP nomenclature requires the
use of additional phrases.  A PGP Key (aka Key) is a packet that
contains a version, algorithm, key material, creation date, etc.

-derek

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 May 2015 11:24:23 -0400

> don't have to do that.  :-D

I am pretty sure that Diffie, Rivest et. al. have been using the term
'key' to refer to a public key, a private key or a symmetric key and
nothing else since the mid 70s.

It is not a question of matching the PKIX world. Lauren Kohnfelder set
out the nomenclature back in the 80s.

> contains a version, algorithm, key material, creation date, etc.

Where we are now is that we have two PKIs that don't talk to each
other. That means we can't use keys from the PGP system with TLS and
we can't use keys from the PKIX system with PGP message formats. And
both cause problems.

I would really like to be able to use some sort of client side public
key based authentication with HTTPS web sites. That means using keys
that are in the user space. Do we really want to insist on the user
having to maintain two separate sets of keys for the different
protocols?

If you want to call a key packet a PGPKey, fine. But we are working in
a standards organization here and one of the things that requires us
to do is to ensure that our nomenclature is consistent across the
organization.

Key fingerprints are useful for far more than just email.

I am just working on setting up Web Service that is distributed across
a set of hosts. Now obviously for external purposes, those hosts are
going to acquire WebPKI certificates. But how do I authenticate the
host to either the CA or LRA?

The simplest solution is to use a public key pair. Lets say the
fingerprint of the public key is:

MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI

Lets also say that there is some TPM capability on the platform so
that I can store the private key on the platform in such a fashion
that I can issue instructions to make use of the key with the above
identifier but can't extract it from the machine without electron
microscope type effort.

So each host has a config file that looks something like:

{"Service" : "Confirmation",
 "HostKey" : "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI",
 "Domain" : "example.com",
 "CA" : {"dns" : "acme.example.com",
     {"root" : "SJE2U-OVCFK-JBVIS-S2JZD-EKURS-IJDVE"}}

And the ACME LRA server would have a config file containing a line
something like:

{Hosts : [
   "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI",
   "MI5GT-ERCTJ-ZNFER-2BGRD-UOT2C-KFGU2-NCEKF",
   "MGVEV-KHIJK-EISK2-JJJU2-SSSIR-FU4SS-RJBBF",
   "MERCP-JZKEE-R2NGN-KE6WS-KKVGV-CWKUI"] }

The combination of these techniques allows me to address one of the
biggest headaches in TLS admin which is how to authenticate a host
before it has a certificate. By far the biggest reason for bad certs
is that admins lose control of their private keys. Automating the
process allows me to go to short lived certs (24 hour rollover).

The point of a certificate is to establish a trust relationship. That
is a different problem to setting up the underlying security
relationship.

Regardless of what you want to use to configure your external trust
relationship (PGP, PKIX, whatever), this is a different problem to
setting up the security relationships.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 05 May 2015 19:07:41 +0200

> nothing else since the mid 70s.
I don't think they are the standards body defining which words to use
for what.

> other. That means we can't use keys from the PGP system with TLS
rfc6091

>  and
Why? I don't see any need why e.g. OpenPGP should be compatible with it.
Actually I'm quite happy it's not.

> having to maintain two separate sets of keys for the different
I don't think you or anyone else here will solve the fundamental
problems of "web crypto" (i.e. TLS and X.509),... nor will we be able to
make the world take over OpenPGP for it.

And again you seem to mix in completely unrelated topics here.
Please focus.

> to do is to ensure that our nomenclature is consistent across the
It's important that the nomenclature is consistent within the
standard/documents we produce... but apart from that it's probably
impossible to reach that goal.
"Key" alone can have many colloquial meanings,.. public key, private
key, the key material, the pair of public/private key, the key material
+metadata, + the UID.

> process allows me to go to short lived certs (24 hour rollover).
What has all this to do with our discussions here? At least I can't see
anything, apart from that I feel the need to comment that any rollover
techniques are IMHO security wise stupid.

Let's focus on concrete questions about OpenPGP.

Cheers,
Chris.

---

From: Werner Koch <[email-masked]>
Date: Tue, 05 May 2015 22:13:21 +0200

> other. That means we can't use keys from the PGP system with TLS and

I don't know what the second PKI is in your book.  OpenPGP is not a PKI
and does not define one.

This thread is on how we may change OpenPGP's expiration time feature.
It is not about other protocols or ideas.  Please change the subject to
to discuss off topic things.

Salam-Shalom,

   Werner

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