Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt

From: [email-masked]
Date: Thu, 06 Mar 2003 06:24:14 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-07.txt
	Pages		: 71
	Date		: 2003-3-5
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 6 Mar 2003 15:53:30 +0100

5.2.3.3. Notes on Self-Signatures

[...]

   Revoking a self-signature or allowing it to expire has a semantic
   meaning that varies with the signature type. Revoking the
   self-signature on a user ID effectively retires that user name. The
   self-signature is a statement, "My name X is tied to my signing key
   K" and is corroborated by other users' certifications. If another
   user revokes their certification, they are effectively saying that
   they no longer believe that name and that key are tied together.
   Similarly, if the user themselves revokes their self-signature, it
   means the user no longer goes by that name, no longer has that email
   address, etc. Revoking a binding signature effectively retires that
   subkey. Revoking a direct-key signature cancels that signature.
   Please see the "Reason for Revocation" subpacket below for more
   relevant detail.

[...]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

What about appending a new section after 5.2.3.3 as follows to ensure
that there is a way to express key expiry such that keys cannot be
un-expired by attackers later (see the threads at
     http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
     http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
     http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
and finally
     http://www.imc.org/ietf-openpgp/mail-archive/msg04220.html
):

5.2.3.?.  Notes on certification signatures

   While the version 3 public key packet format includes a field for
   stating key expiry, the version 4 public key packet format does
   not: key expiry is now expressed via the optional key expiration
   time subpacket in signature packets instead.  Thus, unlike with the
   version 3 public key packet format, certification signatures do not
   automatically cover the key expiration time.

   This is a feature -- it makes it possible to issue keys with short
   life-time that can be extended later; as key expiry does not
   automatically carry over into certifications, re-certification can
   be avoided.  But for the same reasons, it is a problem when handled
   naively -- just as well as the legitimate key owner, an adversary
   who somehow obtains the private key can bring supposedly expired
   keys back to life.

   To avoid the potential problems without losing the feature, the
   following procedures should befollowed when certifying a user ID:

   Any validity period defined in direct-key self-signatures for the
   key to be certified is just used to determine whether the key is
   currently valid (at time of certification).  Such validity periods
   do not automatically carry over into certifications.

   Key expiration that is intended to be final (such that the key
   cannot be un-expired later) should be set in certification
   self-signatures, not in direct-key self-signatures.

   When certifying someone else's user ID, the currently valid
   certification self-signatures for the user ID/public key
   combination to be certified should be examined for key expiration
   times.  By default, the new certification should have signature
   validity extending no further into the future than the maximum key
   validity that has been found in these certification
   self-signatures (if there is a valid certification self-signature
   according to which the key never expires, then the new
   certification signature need not expire either).  Note that this is
   just a reasonably safe default, no fixed rule -- the key owner
   might inform the certifying party of an appropriate expiry date via
   out-of-band means.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: David Shaw <[email-masked]>
Date: Fri, 21 Mar 2003 19:14:54 -0500

>      http://www.imc.org/ietf-openpgp/mail-archive/msg04220.html

I've read all this, and I believe I understand what you are trying to
do: get back the "hard" expiration date that v3 keys had, rather than
the "soft" expiration date of v4 keys.  However, while the suggested
fix results in something closer to a hard expiration date, it is not
as hard as the original v3 expiration date since the expiration date
still vulnerable to manipulation if an attacker can influence the key
distribution channel.  This attack is not possible with the v3
expiration system.

I'm not proposing this as something for 2440bis, but I'm curious why
you aren't proposing a v5 key format with the expiration date in the
key packet as it was in v3 keys?  This would seem to give the best of
all worlds - the "hard" expiration date in the key packet is truly
hard, and if the hard expiration date is not used, then the same
"soft" expiration date from the self-signature that is in use now can
be used.  (Incidentally, this is how GnuPG handles expiration on v3
keys with v4 self-sigs.)

Whether the direct-key signature solution or the v5 key solution is
used, it will take some new code written and released to handle it, so
why not use the more rigorous solution?

Again, I'm not suggesting v5 keys for 2440bis.  I'm sure there are
other things that people would want for a v5 key format aside from
hard expiration dates.

David

---

From: [email-masked] (Bodo Moeller)
Date: Sat, 22 Mar 2003 02:07:02 +0100 (CET)

> distribution channel.  [...]

Can you elaborate?  With my proposal, to set a "hard" expiration date,
you include it in the certification self-signatures.  Thus an
adversary who wants to remove the expiration date has to remove the
self-signatures, rendering the key invalid (at least for software that
rejects keys without self-signatures -- possibly this is a requirement
that is missing in the specification, but this problem would affect V3
keys as well).

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: 22 Mar 2003 13:23:15 +0100

> that is missing in the specification, but this problem would affect V3

Not having read all the references, I could be wrong. But IIRC the
really hard thing about v3 expiration date was that changing the
expiration date would also change the key fingerprint (and keyid?). So,
even when the adversary comes to possess the secret key he can't
unexpire the key.

cheers
-- vbi

-- 
NOTE: my email addresses in usenet postings change frequently!

---

From: David Shaw <[email-masked]>
Date: Sat, 22 Mar 2003 11:17:31 -0500

> even when the adversary comes to possess the secret key he can't

V3 key fingerprints are calculated differently than v4, so the
V3 fingerprint would not change.  However, changing the expiration
date on a v3 key does change the hash of the key which causes all
certifications on the key to break.  A completely uncertified key is
of little use to an attacker.

David

---

From: David Shaw <[email-masked]>
Date: Sat, 22 Mar 2003 11:15:44 -0500

> that is missing in the specification, but this problem would affect V3

I think I wasn't clear enough.  An attacker that gets the secret key
for an expired v3 key cannot un-expire that key without causing all of
the certifications on this key to become invalid.  However, with your
proposal for handling expiration on v4 keys, this same attacker - if
she can control the key distribution channel - *can* perform this
attack.  All she needs to do is issue a new certification
self-signature without the key expiration subpacket, remove the old
self-signature, and distribute this new key.

I do agree that your proposal is "harder" than the current v4
expiration system, but at the same time, it is not as hard as the v3
system where any expiration tampering breaks every single
certification.

This is why I was wondering why you didn't propose a v5 key that put a
hard expiration date back into the key packet itself.  That is a truly
hard expiration date as it cannot be tampered with even if the
attacker can influence the key distribution channel.  Any tampering
would break every certification on the key (whether self-sigs or
otherwise).

David

---

From: Jon Callas <[email-masked]>
Date: Sat, 22 Mar 2003 23:00:21 -0800

> even when the adversary comes to possess the secret key he can't

The V3 fingerprint is computed by the MD5 hash of the two RSA MPIs (sans
lengths). So no, it wouldn't change the fingerprint.

The V4 fingerprint *includes* the creation time of the key, which is in most
people's opinion, a flaw. We were considering a V5 format to change that at
one time.

    Jon

---

From: [email-masked] (Bodo Moeller)
Date: Mon, 24 Mar 2003 11:56:40 +0100 (CET)

>>>> un-expired by attackers later [...]

> self-signature, and distribute this new key.

Er, yes, actually I am aware of this, I don't know what I was thinking
when I wrote my previous message.  -- The attacker could not actually
"un-expire" an expired key (because that key would not have any valid
certifications at all once it has expired assuming that all
certifications follow the suggested procedure); but if an attacker
obtains the secret key for a key that has not yet expired, he can
increase key lifetime beyond the intended expiry date by issuing new
self-signatures.  (In consequence, new certifications by others could
last longer than intended by the legitimate key owner.)  So while key
expiration would be final, expiration dates would not be as hard as
with the V3 format.

> would break every certification on the key (whether self-sigs or

I definitely would suggest to include provisions for hard expiration
dates in the V5 format when it is defined.  My proposal does not do
this because I wanted to show what can be done without redefining the
format in an incompatible way.

---

From: "Michael Young" <[email-masked]>
Date: Mon, 24 Mar 2003 12:07:37 -0500

Jon Callas noted:
> people's opinion, a flaw.

Could you say why people thought this was a flaw?

I presume that everyone agreed that it must be included in the hashed
material for signatures.  Otherwise, the relative times in the various
subpackets would be meaningless.  (I think that using relative times
there was ill-advised anyway, but that's another matter.)  It would
make the time in the key packet completely worthless -- anyone could
change it arbitrarily without disturbing fingerprints or signatures.

If it were used in signatures but not fingerprints, this would leave us
with the same collating mess as we have for v3 keys.  The fingerprint
would not be sufficient as a unique key for indexing key material.
You'd have to tack on this other field, or compare the whole key, or
compute yet another strong hash.  I can't see how this is a feature
you'd want to retain from v3 :-(.

Now, if the argument was that the creation time didn't belong in the
key packet at all, I'd have to agree.

---

From: Mike Markowitz <[email-masked]>
Date: Mon, 24 Mar 2003 13:41:27 -0600

At 02:07 AM 3/22/2003 +0100, Bodo Moeller wrote:

>... With my proposal, to set a "hard" expiration date,

I think *something* -- preferably along the lines of a "MUST" -- needs to be
added about software rejecting invalid keys.

PGP 8.0 has the following interesting "feature": if you simply render the
self-signature on a V4 key invalid (say by modifying the embedded hash value),
PGP8 *quietly* ignores that signature block (along with its expiration date)
when importing the key and allows it to be used like any other (unsigned) key.

So, if I create a key for myself with a fixed expiration date -- anticipating
the public revelation of my private key shortly after that date -- an attacker
can thwart my intentions by simply changing a single byte in the key. No PGP8
user would ever know the key had been tampered with... or that it was supposed
to expire. After all, the "fingerprint" on the key is still valid, so even 
if a
user checks it against the value published on my website, they'd never detect
the attack! (I don't think there is a solution, since the attacker can also
simply strip off the signature block. I guess I'm really complaining that
OpenPGP keys do not behave like X.509 certificates: if the signature block
contains a critical attribute like an expiration date, stripping it *should*
render the key invalid AND unusable... or at least generate a warning!)

In any case, since PGP8's strange behavior doesn't appear to violate anything
in the latest draft, I can't help feeling that 
draft-ietf-openpgp-rfc2440bis-07's
claim to "discuss implementation issues necessary to avoid security flaws" is
rather empty.

-mjm

---

From: Jon Callas <[email-masked]>
Date: Mon, 24 Mar 2003 14:10:40 -0800

> Could you say why people thought this was a flaw?

The reason is that if you have two keys that have the same key material,
they will have different fingerprints (unless they also have the same date).

People who believe this is a flaw think that the fingerprint should be a
function of the key material (and perhaps some other constants).

Here's the central question: If Alice and Bob each have a key that by some
coincidence share the same key material, should their keys have the same
fingerprint?

None of the key management utilities give an easy interface to ask the
question of whether two keys have the same key material by directly
comparing them.

Suppose Bob takes the key material from Alice's key, and makes a new key
(which he doesn't have the private key to), and claims that one of Alice's
signatures is actually his own. There is no easy way to figure out what's
going on. If the fingerprints were the same, it'd be a snap.

    Jon

---

From: "Michael Young" <[email-masked]>
Date: Mon, 24 Mar 2003 17:59:47 -0500

Thanks for the explanation.

> coincidence share the same key material, should their keys have the same

It depends what you want the fingerprint to do.  If you want to use
the fingerprint to detect this specific sort of reuse, then you want
them to be the same.  If you want the fingerprint to be useful as a
unique index (up to breakage of the hash) for the key and its
signatures, and those signatures incorporate the non-MPI material,
then you want them to be different.  I think the latter is far more useful.

[Just so everyone's clear on the indexing problem, here's an example.
Alice creates a key with <time1,MPIs>, and gathers some signatures for
it.  Bob later creates a key with <time2,MPIs> and gathers his own
signatures.  Charlie receives both Alice's and Bob's keys.  Since they
have the same fingerprint, Charlie thinks they're the same, and merges
them together.  Whichever timestamp he keeps, Charlie will effectively
destroy the other key -- the signatures based on the key with the
other time won't verify.  This is very close to a real-world example:
Charlie is one of many keyservers that assume that fingerprints are
unique; Bob is created by an automated signing agent that (accidentally)
mangled Alice's timestamp.]

But, as I said before, if the point was to remove the creation time
from the key packet entirely (meaning that it wouldn't get hashed into
all signatures, either), then the fingerprint will serve both
purposes.  I'd be quite happy with that.  Was that the nature of the
proposal for a V5 format?

> question of whether two keys have the same key material by directly

[Actually, GnuPG offers a switch to see the key material.  You might
argue that its interface isn't "easy", though. :-]

> going on. If the fingerprints were the same, it'd be a snap.

I don't find this at all compelling.

First, if Bob wants to thwart this use of fingerprints, he simply
has to use the same creation time.  What does Bob gain by using
a different time in this attack?

Second, there *is* an easy way to figure out that Bob is bogus.  His
identity will have no valid self-signature; if you press him for one,
he can't produce it.  GnuPG, for one, rejects such things by default;
other tools *should* do the same (or at least note the impropriety loudly).
Alice *can* demonstrate a valid self-signature.  If your argument is that
Bob can pull this off by hiding Alice's key, then fingerprints won't
help, either.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 25 Mar 2003 12:05:20 +0100

[...]
[...]
> going on. If the fingerprints were the same, it'd be a snap.

Having the fingerprint depend solely on the key would not totally rule
out this kind of attack, however.  It's still easy to derive related
keys such that at least some signatures remain valid.  (For DSA,
inverting the public key value  y  modulo  p  will yield a new public
key value for which 50% of signatures are still valid, namely those
for which the exponent of  y  in the verification equation is even.
Also I wouldn't want to rely on all software rejecting MPIs with extra
leading zeros -- an easy approach to creating an equivalent but
differently looking key is to represent the key differently without
actually changing the values.)

There may be signature schemes designed to avoid the "key stealing"
attack that you described, but this is not part of the usual security
notion for digital signatures, and certainly DSA is not safe in this
respect.  If you think that this is a flaw, then you should be aware
that changing the fingerprint algorithm does not avoid it; we'd also
have to pick appropriate signature schemes.

I don't really think that OpenPGP has a problem here.  (Bob's key with
Alice's key material won't have a valid self-signature anyway.)