ietf-openpgp
[Top] [All Lists]

Re: Principles and Principals

1997-10-02 09:40:05
From: Jon Callas <jon(_at_)pgp(_dot_)com>

At 11:05 PM 9/24/97 -0700, Patrick Richard wrote:

  If you develop a system that goes around this, then the key is
  not the principal...
   
I disagree. One of the things that I want to see in PGP is an
"I-used-to-be" certificate. With proper setup of one of those, you have a
key-as-principal system, but delegation of authority with transfer of
authority, it all flows.

      Jon


An interesting assertion, but it's incorrect.  Pat is correct that if you
develop a system that allows key revocation, then the system does not use
keys as principals.  Proof by inspection.

SPKI principals are keys.  If Alice's private key is compromised, then both
Alice (the good guy) and Bob (the bad guy) are now keyholders corresponding
to the single principal that you might refer to as alice, and there is no
way to distinguish between them.   If "alice" creates an "I'm-gonna-be"
certificate delegating to a new principal, you have no idea whether that
certificate was actually created by the good keyholder or the bad keyholder.

(Going in the opposite direction, creating an "I-used-to-be" cert signed
by the new principal, makes no sense.  Anyone could make up one of those.
What sort of mechanism do you mean by "transfer of authority"?  Does it
involve a trusted third party - i.e. an identity CA?)


From: "Bonatti Chris" <bonattic(_at_)ieca(_dot_)com>

Key revocation due to compromise is far less common that normal
periodic key expiration in some environments.  Those of us who
are paranoid about security :-) change keys *more* often than
we change names/jobs/email-addresses/whatever.

You're quite right, of course.  However, I guess one of 
my unstated assumptions was that this would not be something 
that we would use a revokation mechanism for.  Normal cert 
expiration dates are usually used to reflect planned rekeying.

Planned rekeying is done for a reason - you assume that the liklihood
of undetected key compromise increases with time, and at some time that
liklihood rises above your threshold of pain.  In that sense, key
revocation and key expiration/update are done for the same reason.  In
one case you know that the key was compromised, and in the other you
assume it has been.

In either case, key-centric models such as SPKI fail catastrophically -
if the key is revoked/expired, the principal has expired too, since
they are one in the same.  You can't get around this simple fact by
delegating, because the key signing the delegation has (potentially
or actually) been compromised.

<Prev in Thread] Current Thread [Next in Thread>