From: Brad Templeton (brad@templetons.com)
Date: Sat Oct 20 2001 - 11:53:26 CDT
On Sat, Oct 20, 2001 at 01:37:12PM +0000, Charles Lindsey wrote:
> In <20011017113139.B29163@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
> "You" in this context is the CA? To renew any certificate SHOULD require
> looking at your records to see why you certified it last time, and to see
> whether those conditions still apply, and what tests need to be repeated.
> OK, in the case of a simple email challenge/response certificate,
> repeating the challenge may be good enough, but I would like something a
> little stronger for a Usenet injecting site. And if the certificate is to
> say that "Cancelmoose is to be trusted as a canceler", then the proper
> response should be to say "Hey, I don't think Cancelmoose is still doing
> cancels these days".
Because you can always revoke a certificate, automatic renewal is not
necessarily an issue. If cancelmoose is not doing cancels, and then suddenly
starts using his renewed certificate to do cancels, and you don't like it,
you revoke it (and undo the cancels if you provided a facility for that.)
If the certificate needs to be re-verified, then re-verify it. If it doesn't,
you don't need to. For example, if I have a moderator certificate for
foo.bar.baz, and I pass along moderation duties to another, well then when
you create the certificate for that other, you are going to probably revoke
mine or add it to a "not for renewal" list.
Renewal of domain ownership certificates can be done any number of ways.
You're not relying on your own database there, but on the database of
domain registrars. For example, you can auto-renew a domain certificate
if a whois query shows the same contact-id as you put into the original
certificate. You don't have to store records, because you can put something
like a NIC handle into the certificate, or a hash of one.
Of course you _can_ store records, and I am not sure why you feel that is all
that hard, but it's not a requirement.
>
> Incidentally, an odd feature of Open PGP I just noticed. A modern PGP key
> has NO expiry date. Ergo, a PGP key revocation has to be kept around FOR
> EVER. Even more odd is that the old 2.6.3 keys DID have expiry dates in
> them.
>
> OTOH, a PGP certificate does (or at least can) have an expiry date, so if
> the certificate gets revoked, you don't need to keep the revocation beyond
> the time the certificate expires.
That's the right way. Keys don't expire, per se. Keys have no meaning
without some association between the key and some attribute about the holder
of the key. It is those associations which control all trust and
those associations which must be renewed.
>
> Hipcrime is a specialist at locating organisations with lax security. I am
> sure he could easily obtain a plausible-looking certificate to do
> something unpleasant. The only defence is for people who trust certificates
> to ensure that they only trust certificates from well-run organisations.
Obviously, when you delegate trust you try to do it to people worthy of
the trust.
However, the scrutiny you apply depends on the power you are delegating,
and on the damage that can be caused through misuse, and how hard it is
to clean up that damage.
I continue to recommend that all actions we define have an undo. In
particular, "rmgroup", "mvgroup" and "cancel" should have an undo.
(you could make these undo operations a SHOULD rather than a MUST, but
frankly I don't think any are particularly hard. mvgroup, done perfectly,
is its own undo, unless you are merging two groups together, but it may
be easier to do it less perfectly and support an easy undo just by keeping
a copy of the old info, since group moving will be very, very rare.)
So I look at it in terms of what people can do with certificates that
might be compromised. You protect the powerful ones (rmgroup power
for example) and you don't care a lot about the minor ones (email address)
because they can't do a lot of damage, and you can fix it.
All actions using certificates are signed, and leave a clear audit trail
back to the key. If the key was stolen that might tell you much, but again,
you just revoke the certificates for it.
To agree with one point, people doing certificate collapse should write
it to a log file to complete the audit trail, or store some sort of
compact chain of certificate numbers, at the cost of a few bytes, in the
collapsed certificate. However, cert collapse is mainly for commonly used
keys -- moderators, big sites and bulk cancellers.