[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Entity life after compromise.
Hello all.
In identity based systems like X.509, the life after certificate
expiration and key compromise is just and administrative issue. The
"only" things to do is make sure all people can access the CRL and to
issue a new certificate with the new validity time (and new key). I
Think that's way the use of "administrative" validity times for X.509
certificates can be easily justified.
The situation is really different in SPKI. Here the key is the entity
itself, and its compromise invalidates all its existence. Once, an SPKI
environment is set-up, it is clear that recreating the hole amount of
certificates issued over a principal for another principal will be a
difficult, if not impossible, task.
To solve that problem two things are needed:
1. A cryptographic evaluation of the estimated key life, which implies a
certificate that expresses it, including its very first use. (This
certificate must be securely time stamped ?)
2. A chaining mechanism that enables the effective transfer of the
authority in case of key compromise or expiration.
In big words this mechanism is enabled as it follows:
- The key holder of the A principal (to be compromised) have also a B
principal.
- The B principal is never used, except of A principal compromise. Thus
the B principal is protected, and we can assume that his life is
effectively extended until its very first use.
- The A principal issues a certificate over the B principal ( which must
appear in hashed version only) delegating all authority over it which
validity time "never except when a TTP principal declares the opposite".
This certificate must be securely time stamped, otherwise it can be
issued after key compromise over other principal C.
In that way, once A is compromised, B can be used in its place, enabled
by a new certificate issued by TTP. It will be convenient to point the
same TTP as a CRL or revalidation entity when the certificate pointed in
(1) is issued.
More discussion about the secure time stamp certificate can also help.
Xavier.
--
----------------------------------------------------------------
Xavier Serret Avila
Universite Catholique de Louvain
Laboratoire de Telecommunications
Batiment Stevin
2, Place du Levant
B-1348 - Louvain La Neuve
mailto:serret@tele.ucl.ac.be Tel.: +32 - (0)10 - 478072
Fax : +32 - (0)10 - 472089
----------------------------------------------------------------
From ???@??? Thu Jun 25 12:21:55 1998
Received: by mis01.reston.cybercash.com; id LAA12541; Thu, 25 Jun 1998 11:58:50 -0400 (EDT)
Received: by callandor.cybercash.com; id LAA11109; Thu, 25 Jun 1998 11:58:11 -0400
Received: from blacklodge.c2.net(208.139.36.35) by callandor.cybercash.com via smap (3.2)
id xma011084; Thu, 25 Jun 98 11:58:03 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id IAA08332 for spki-outgoing; Thu, 25 Jun 1998 08:47:23 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-spki@c2.org using -f
Date: Thu, 25 Jun 1998 12:45:41 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
Reply-To: Ed Gerck <egerck@laser.cps.softex.br>
To: Xavier Serret <serret@tele.ucl.ac.be>
cc: spki@c2.net
Subject: Re: Entity life after compromise.
In-Reply-To: <35920DF0.95C8A59E@tele.ucl.ac.be>
Message-ID: <Pine.LNX.3.95.980625115945.13732K-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-spki@c2.net
Precedence: bulk
Status:
On Thu, 25 Jun 1998, Xavier Serret wrote:
>Hello all.
>
>In identity based systems like X.509, the life after certificate
>expiration and key compromise is just and administrative issue. The
>"only" things to do is make sure all people can access the CRL and to
>issue a new certificate with the new validity time (and new key). I
>Think that's way the use of "administrative" validity times for X.509
>certificates can be easily justified.
>
This is a very timely remark since, as some of this list may have
followed, this issue is being discussed at depth in cert-talk,
mcg-talk and dig-sig. The threads are under the name either of
"zombie certs" or of "passive certs" (equivalent names).
>The situation is really different in SPKI. Here the key is the entity
>itself, and its compromise invalidates all its existence. Once, an SPKI
>environment is set-up, it is clear that recreating the hole amount of
>certificates issued over a principal for another principal will be a
>difficult, if not impossible, task.
IMO, instead of a bug, this is a feature of SPKI.
This further shows that one needs to understand the usefullness and
limitations of the concept of "key is all", as defined in SPKI, and
not negate it because some facts are outside of SPKI.
Of course, one cannot make a do-all express-all protocol, there is
always something you did not think of.
Further, SPKI is based on the notion that *there is* a layer which
you can take out of the certification "witch's brew" and this layer
is based on authorization.
This is a fundamental point. If, now, the other layers are brought in
... then one will quickly get into a quagmire since all the other
mechanisms for all the other layer's management needs, are missing.
If SPKI is SPKI then it considers the key as the keyholder's
representative -- the key speaks for its owner. However, since keys
do not talk back, all decisions rules are added by the issuer. For
example, the issuer establishes relationships, grants privileges,
defines how the other party is to be represented... and the other
party assumes a fully passive role -- it is a key and cannot talk
back.
This is certainly not a dialogue or a binary relationship (as in the
zombie thread when cert expiration is negotiated), it is a monologue
-- a unary relationship. For instance, who decided that a key could
represent well the other party, why not use a secure and mobile
software agent? Who decided to rely upon such grant and to what
extent can it be relied upon, for how long, etc? Clearly, these
questions were not decided by the other party, who was entirely
passive to the act. Only by the issuer. Which means that the issuer
relies on the issuer's declarations.
This is a circular authorization loop that represents a type of
"crypto-memory" for the issuer. Not valid for Alice or anyone else
in the world. But, which can be useful for the issuer.
What is the bottom-line? IMO, SPKI expresses what happens at
world coordinates centered on authorization. Authorization can be
unary -- I authorize -- and SPKI neither has nor needs agreement
protocols which are binary and m-ary, just establishment protocols
which are unary.
Which can be useful as an "atomic" design component. IMO, to try
otherwise will fall into a (purposeful) lack of expressing "language"
-- as perhaps already counterexemplified below:
>
>To solve that problem two things are needed:
>1. A cryptographic evaluation of the estimated key life, which implies a
>certificate that expresses it, including its very first use. (This
>certificate must be securely time stamped ?)
>
Estimated by whom? Must be by the private-key holder, not by the
issuer -- who must however access it. Further, the issuer must be
able to rely upon such estimate in a qualified way even without being
able to directly measure it (ie, must trust it). This is not included
in SPKI's layer.
>2. A chaining mechanism that enables the effective transfer of the
>authority in case of key compromise or expiration.
Transfer of authority is not the case -- authority is unary. It must
be transfer of binary trust. This is not included in SPKI's layer.
The verifier only trusts himself in SPKI.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
--- Meta-Certificate Group member, http://www.mcg.org.br ---
Follow-Ups: