ietf-openpgp
[Top] [All Lists]

Re: [openpgp] rfc3880bis - hard expiration time

2015-05-04 08:20:58
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> 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
       derek(_at_)ihtfp(_dot_)com             www.ihtfp.com
       Computer and Internet Security Consultant

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp