On Thu, Mar 06, 2003 at 06:24:14AM -0500, Internet-Drafts(_at_)ietf(_dot_)org
wrote:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-07.txt
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 <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
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