sen_ml(_at_)eccosys(_dot_)com wrote:
From: Ian Brown <I(_dot_)Brown(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk>
Subject: Forward secrecy
Date: Wed, 05 Jul 2000 11:55:43 +0100
Message-ID: <3963142F(_dot_)E8971209(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk>
John Noerenberg suggested we publish it as an informational RFC. We would
be grateful for feedback from this group before we take that step.
here are some comments:
-this document seems to be focused on the use of openpgp for mail in
particular. is there anything to be said for other uses? (e.g.
openpgp key usage in ssh)
We should certainly extend it to cover other uses. Good idea.
-section 2.1 says:
Key distribution can be eased by submitting new keys to key
servers, where they will be available for other users to retrieve.
Submission and retrieval SHOULD be performed automatically by
software. Expired public encryption keys MUST be deleted by users
and keyservers to remove information on old key pairs. Expired
private encryption keys MUST be securely deleted to prevent later
compromise.
i think whether the key distribution should happen automatically
should be a matter of policy. some of us have keypairs of which the
public portion is not really made widely public, nor do we want it to
be made so. perhaps such relevant policy can be expressed in the key
and implementations could interpret it appropriately.
It is a SHOULD rather than a MUST so a compliant implementation can
choose to not do it. However, we should probably make a specific note to
that effect. OTOH, I notice that one of the changes I intended to make
has not been: that is that it is not necessary to delete public keys,
only private ones. In fact, expired public keys may be required to check
the validity of (old) revocations.
i wonder how much success one will have w/ convincing the
keyserver folks that they should delete expired public keys. i would
like the ability to be able to tell a keyserver to remove a public key
for which i have the corresponding secret key (or may be even the
typically existing email address), but i don't get the impression that
it's a popular idea thing among implementors.
I have exchanged some mails with (some of) the keyserver folks, and the
widespread use of short-lifetime encryption only keys will kill the
keyservers if they do not expire them. So, I think they may well wish to
do it.
-section 2.2 says:
Before an OpenPGP client exports a private key as plaintext, the
associated public key MUST be revoked and redistributed.
i think i see a good reason for this, but i wonder whether it is
practical. doesn't redistribution of the key require net
access?
to implement this correctly, when requested to export
a private key as plaintext, the implementation first revokes the key,
then redistributes the key by sending it to the keyservers, and
then exports the private key (perhaps after confirming that the
redistribution has been successful). if it cannot contact a keyserver
(or verify that redistribution was successful), a correct
implementation would not export the private key as plaintext,
i presume. perhaps i'm nitpicking...
I guess it needs addressing.
also, which takes precedence, the deletion of expired keys from
keyservers or the distribution of revoked keys? is this also a matter
of policy that could be reflected in the key?
-how about saying "attackers" instead of "hackers" in section 6?
Sure.
-how about some "secure deletion" references in the references section?
For example?
off-topic: how about you guys write an informational rfc that suggests
best practice methods for email message header confidentiality ;-)
I thought someone else was doing that already?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/