[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CRL format revision -Reply
Hi Bob.
Thanks for these thoughts on CRLs.
At 12:07 PM 8/7/96 -0600, Bob Jueneman wrote:
>One reason field that you might want to consider is a SUSPENDED flag.
>[...reasons...]
>(Of course, if the certificate doesn't contain anyone's name or identity,
>or is otherwise issued willy-nilly, then there may not be any due diligence
>requirement, so you can just blast them out without confirmation or
>acknowledgment of receipt.)
That's a very interesting possibility. I should let it sink in for a while....
My first reaction is that this is more relevant to the X.509 world than to
SPKI, but I'm not comfortable saying that authoritatively since I'm not
really part of the X.509 world.
Try this analogy:
It hit me the other day, in listening to a news report about national ID
cards in Turkey, that at least the original plan for an X.509 certificate
might be like the digital version of a national ID card -- some single ID
which everyone would have (issued by various sources but part of the same
single hierarchy) -- while SPKI certs, Kerberos tickets or Lampson
capabilities would be more like my ATM card which doesn't have my name on it
and which causes ATMs to give me money if I possess the card and know the
PIN. [As an aside, PGP, SPKI and SDSI are also capable of binding names to
keys -- not as a national ID card for lack of a hierarchy -- so this forms a
3rd possibility, muddying the waters. I'll ignore that use, here.]
First of all, I'd be curious about whether you think that analogy is valid.
If you think so, then it helps explain some of the religious disconnect I've
experienced between myself and the X.509 folks. That is, it's clear that
there's a disconnect in some basic assumptions which we just don't discuss
up front -- so we use words for which we have different definitions and the
other ends up sounding crazy.
Assuming the analogy is valid, for this second, I can see far more
hesitation over revocation of a citizen's national ID card than over
revocation of one of his many ATM cards. Getting a new ATM card is
relatively simple and in the meantime he has other alternatives.
Still, the idea of suspension is interesting. I don't like it for the case
of immediate issue of not-active-yet certificates. I'd much rather have a
cert issued only when it's active. But there might be a use for "well, I'm
not sure -- there is some claim of failure here". For example, I've known
several people who have lost their wallets -- called the credit card
companies, DMV, etc., to cancel everything -- then found the wallet a few
days later.
>ON THE OTHER HAND:
>
>As long as you are departing substantially form the X.509
>certificate format, you should perhaps consider departing from the
>CRL paradigm entirely, and moving to an on-line, positive acknowledgment
>of the validity of a signature/certificate.
>
>The CRL paradigm was modeled after the now abandoned credit
>card hot list that was the norm perhaps 10 years ago, when universal
>connectivity to the Internet was not the norm. Perhaps it is time to reexamine
>that premise.
Exactly. I am not a fan of CRLs myself. That's why I didn't bother to
define a CRL format. SDSI flatly rejects them.
The only reason I included CRLs in the definition, as an option, is that
there is a not-uncommon situation in which CRLs have a strong performance
advantage over revalidated certificates.
For this to be true, you need:
1. the verifier to have storage to hold a CRL and just receive deltas;
2. many certs to verify from that same issuer during the lifetime of one
CRL (delta);
3. a very low percentage of revoked certs.
In that case, (as in SET for the CAs and Merchants), CRLs have a major
performance win over short-lived certs.
I did a performance analysis of CRLs versus short-expiry a while ago on the
back of an envelope and really should write that up as a real paper and post
it. I started that process as a firm opponent of CRLs and was forced by the
analysis to admit that there was a place for them.
However, I'd rather have the CRL semantics remain identical to the
short-expiry semantics and I'm not sure SUSPEND does that.
Aha! SUSPEND does fit the semantics, sort of. What SUSPEND gives you is
one more layer of CRL. That is, you now have a revokable CRL -- a CRLRL --
only it's a little more under control. :)
------------------------------------------------
>The CRL paradigm is really awkward from the standpoint of non-
>repudiation, because it requires a trusted timestamp be applied to both the
>signature of the document (generally not available, except by means of
>a trusted third party, and to the CRL (the next one AFTER the document was
>signed, and to the certificate itself. Coordinating all of these clocks in
a reliable
>manner, and having trusted third parties sign statements that they have in fact
>checked the status of the certificates with the CA, etc, etc, is extremely
>cumbersome.
I'm not sure the CRL has much effect here. If it does, then I'm not
following you properly.
Don't we have this problem no matter what, if we want non-repudiation? The
CRL and short-expiry models are exactly functionally equivalent -- including
the use of time. So I should be able to express the same lifetime of a
certificate either way. Once I have a certificate with limited lifetime and
a signed document, I get into the question of non-repudiation.
>From a legal point of view, it's even messier (I assume). That is, I might
discover my private key is missing or might have been copied -- but I'm cut
off from the net and the phone (maybe I'm on a 2-week backpacking trip when
I look in the pocket of my backpack and see my floppy holding my private key
is missing). When I get back, I want to claim my key was missing much prior
to the time I report it missing. This gets me into a shouting match with
the bank that released my cash based on that key, on the first day of my
backpacking trip. We end up in court and I have to call Ross Anderson over
to testify for me.
>Since the CA is the only essentially the only trusted entity which can speak
>authoritatively about the status of a certificate at a particular moment in
time,
It can certainly speak for the status of a certificate but not for the
status of a private key. The certificate is a statement about that private
key and the CA is not a completely trusted source for that statement.
[This, BTW, is one reason I take all the elaborate policy questions about CA
trust with more than one grain of salt.]
>it makes a lot more sense for any relying party that wants to establish
>nonrepudiation to send the digital signature portion of a document to the
>CA which allegedly signed the user's certificate, and have that CA say
>once and for all time whether the certificate was valid as of the moment the
>document was received. Of course it is still necessary to confirm the
>validity of the CA itself, but this can be done recursively.
It makes the most sense for the verifier to check with the real source --
the user. That brings us back to the question of I&A. Until we have really
trustworthy hardware (e.g., monitoring of the thumb print and pulse and
temperature of a living thumb from the same tamper-proof card which holds a
private key (and a duress key)), we won't get close to the kind of trust I
think you're looking for. Even then, there's the possibility that the
crooks have kidnapped me and have forced both normal and duress PIN from me
-- testing those to see which is which....
>The other real virtue of this approach is that it lets the CA know whenever
>a transaction has occurred that someone thinks is important enough to
>validate. From the standpoint of controlling the CA's aggregate liability, this
>is exceedingly important.
IANAL, but this looks like the policy version of building a bank safe door
into a plywood house. Until we have provable connection between the private
key and a person, with proof that the person isn't being coerced built into
the physical process, I don't see much use for getting iron-clad CA
liability protection.
>The ideal solution to the overall problem would be some scheme that would
>distribute base-level CRLs on a CD-ROM-of-the-month, plus delta CRLS
>that could be downloaded according to the relying party's perceived
>risk, plus an on-line positive validation scheme for near real-time, high-value
>transactions.
That sounds like a plan.
You could have different spending authorizations in different SPKI
certificates -- each with a different validation mechanism. That's one
advantage we have over X.509 or any other identity certificate.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+--------------------------------------------------------------------------+