[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CRL format revision -Reply
Bob Jueneman:
> [re: perceived need for suspension, and the nature and history of CRLs]
I think I'd be a fool to publicly disagree, and arrogant to agree
over-loud, with someone having your apparent depth of experience in
matters such as these. I will therefore not argue your opinion of the
need for a suspension feature, but only discuss effective means of
accomplishing it. I think that there are several ways of dealing with
these matters that do not require suspension, although suspension could
also work.
If what is desired is to issue a credential that means "when the right
time comes, you will have this privilege", then a suspension seems
excessive, since there will have to be one issued every time this sort
of certificate is issued. Instead, the validity method chosen could be
one of:
- validity start time, if the process of full approval requires relatively
fixed time;
- real-time validation, that doesn't work until some online process accepts it;
- or a policy cert that says that the issued certificate alone is not
sufficient, but requires an additional activating cert.
PolicyMaker-like logic, along with the CRCert process we describe,
allows for the automatic creation of a cert that can stand alone
when the conditions are met.
If the need is to suspend a previously fully valid privilege, a
validity method that uses a CRL is probably indicated, but as I noted
earlier to Carl, when you negate the expression of a privilege, rather
than the privilege, it is easier merely to reinstate the privilege by
issuing a new certificate. This would, of course, require explicit
action for the restoral, but the original certificate should supply
sufficient evidence for the appropriateness of the action, since it was
that certificate which was in suspense and had been exonerated.
Alternatively, your suggestion would work: put a REASON: SUSPENDED
field in, with (or without) an expiration date, but it need not be the
only way of accomplishing this.
All of these, and more, are methods that we have discussed that SPKI can,
I believe, support well.
A point I would really like to emphasize is that under circumstances
where issuance is easier and the trust model more direct, short expiry
is much more practical than before, and makes sense in more cases to
replace CRLs as a method of ensuring validity. Carl's discussion of
that topic has convinced me of that. The SPKI design has made room for
your OTOH observations as well:
>
> 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.
This is one validity method we explicitly mention in the draft. A very
nice feature of SPKI is that the verifier, which is in most cases the
issuer as well, has a lot of flexibility in this. If desired, two
certificates that give the same privilege can use different methods of
validity, based on the requirements of the application. CAs, as TTPs,
need not be involved so much, since a great deal of the responsibility
goes back where it really belongs, in the hands of the relying party.
> 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.
I think that many agree. Three basic methods are available: CRLs,
real-time validation, and short expiry(requiring efficient reissuance,
which I think we have licked). The choices are application-specific,
and things will be much easier if the applications can control them,
which SPKI's issuer-as-verifier model facilitates nicely. That is one
of two things which moved me from the "SPKI are ASN.1-hating cranks"
opinion to the "hey, we could do something with this!" camp.
One last thing: on non-repudiation, I consider myself even less an
authority than on some of this. However, it seems to me that two
things have to be established: 1) the signature happened at the time
indicated; and 2) the certificate binding the signing key to some
legally-verifiable identity was valid at that time. 1) is accomplished
rather simply using Haber & Stornetta's "Surety" service at the time of
the signing; 2) seems the hard part to me, and it seems that, at
minimum, a similar certification of the CRL existing at the time is
needed. The nice thing is that Surety-style services don't really need
to meet traditional TTP trust requirements since everything they do is
publicly verifiable as a matter of public record. I don't see how
anything in either the structure of either a certificate or a CRL could
accomplish this.
Thanks for your contribution.
Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755