I've been unable to keep up with the traffic on pem-dev for
several weeks due to extensive travel. However, before taking off
again for a while, I began reviewing traffic, beginning with a message
from Bob Jueneman, dated 9/17. I think this message triggered a
significant thread and thus it is especially important to respond to
it.
Bob's message criticized CRL management in PEM, espevcially
from a perspective of responsiveness for use in a commercial
environment. It is worth noting that the requirement for PCAs to
maintain a global CRL database is an interim measure, in the absence
of directory server facilities, and I think that is pointed out in
1422. The various "flaws" Bob cites for PEM CRLs are no worse than
those that derive from use of X.500 as a CRL repository, and the
inclusion of the nextUpdate field in the PEM version of a CRL improves
the situation by notifying users of when they should request a new CRL
for a given CA (or PCA).
Bob' initials arguments include some arbitrary time values
(e.g., 30 or 60 day intervals) that he chose for worst-case analysis
purposes. One can begin by observing that a PCA serving a commercial
clientele might require CAs to issue CRLs more frequently than his
worst case examples, e.g., weekly. So this first aspect of the
argument is a overstated. A PCA is free to establish a short interval
for required CRL issuance as part of its policy. So, for example,
Bob argues that a 24-hour window might be a minimum acceptable delay
for hot listing a revoked certificate and that can be accommodated by
the current CRL management scheme.
Bob correctly observes, as I stated on previous occasions,
that a recipient of a signed message must not only have the message
timestapmed by a (trusted) timestamp server, but must also wait until
the next CRL is issued by the CA (more precisely, all of the CAs up
the chain) in order to have the proof required for non-repuditaion.
Then, the CRLs for the certification path must be asseblmed into a
message and timestamped as well.
I think Bob errs in suggesting that this approach is not
sufficient, stating that the recipient might gather old CRLs and try
to "prove" that a message was valid by getting the timestamp server to
sign the resulting bundle. Instead there is a very small residual
vulnerability associated with the CRLs for the certification path IF
the IPRA were to disclose the private key it uses to sign its CRL.
Getting a timestamp notary to sign the IPRA CRL would address this
problem, but only to the extent that the timestamp notary's private
key is secure. There is an obvious recursive problem here that is
probably best addressed by a combination of very stringent protection
for the private keys used by the IPRA, and by a timsetamp chaining
approach with published checkpoints, such as the one developed by
Bellcore. (A different vulnerability arises in the CRL-variant model
that Bob envisions, unless the CA signs the response to a CRL request,
but there is not a problem in the current model.)
Bob goes on to argue, using the exaggerated 30-60 day example,
that the current PEM CRL design is fatally falwed. He also compares
PEM to PGP, disparagingly, by suggesting that even outside of a
commercial environment this system does not scale well and does not
handle revocation well. Since I don't think PGP handles revocation
through any systematic means, and since PGP is not set up to ensure
globally unique name assignment, I find this comparison highly
dubious.
Bob states that if certificate revocation cannot be effected
within 24 hours, then it is generally worthless. I think this
statement may be true for some potential PEM application environments,
but I don't think Bob can demonstrate that this is a universal
requirement. We have tried to include in the common certification
system policy only those requirements that are universal in nature,
and so I'd argue that a 24-hour timeliness requiremenst for CRLs is
not appropriate as part of the common policy. Instead, as I noted
above, it is something that one or more PCAs can decide to offer, and
if there really is a requirement for this feature, one would assume
market forces would cause PCAs to offer this very responsive CRL
service.
Note that even for financial transactions there are varying
degrees of timeliness with regard to verifying the validity and
finality of the transactions. Before dialup credit card verification
became cheap enough for almost all merchants, VISA and Master Card
survived (and prospered) with monthly hot lists for many merchants
(for low value purchases). Many stores accept checks without online,
realtime verification (e.g., via Telecheck). Some major consumer
transactions have builtin "cooling off periods," e.g., house purchases
in the U.S. involve a 3-day right of recision period. So it is
unwarrented to claim that ALL financial transactions require very
timely CRL checking ability, much less that ALL email messages of any
sort require such service.
Bob uses the 24-hour CRL to argue for an inquiry-based
revocation system, as opposed to the combination pull-push model
offered by PEM, much less the pull-only model incorporated into X.500.
One can quibble over access mechanism details, for CRLs, but I agree
that a more efficient and potentially more responsive CRL-style
facility can be provided as Bob suggested. Provision of such a
facility as an additional service is NOT in conflcit with 1422, and it
could be offfered by PCAs who are convinced that their clients require
this service. However, there are a variety of costs to providing this
sort of facility. It requires realtime access, something not
available to all email users. Remember that some email users have NO
realtime access capabilities at all. Getting a timestamped CRL from a
PCA, or directly from a PCA, could provide a more responsive
mechanism, but it need not! Adding in the need for a timestamp notary
to be invoked by the PCA/CA in sending back a response will add more
delay to the process.
I note in a (somewhat) later message that the COST PEM folks
applauded the idea of getting a CRL-like service directly from CAs vs.
PCAs. Let me observe that, if one uses real DNs in certificates, as
called for in 1422, then it is not obvious how one determines the
mailing address of a CA for a given user. Each user can be informed
of the mailbox address of the PCA that serves that user, e.g., as a
part of user registration through the CA. However, (in the absence of
X.500 services) there is no general mechanism for mapping from a CA DN
to its mailbox address, so direct contact of CAs for CRL access is
potentially much more difficult than CRL access provided through PCAs.
Also, any form of CRL access directly through a CA imposes a
potentially greater burden on the CA operator, e.g., in terms of
continuous, realtime connectivity, that may be hard for some CAs to
provide or may introduce additional security problems for CAs. Thus,
provision of online CRL service by CAs is fine as an option, even as a
requirement under a given PCA policy, but it is hardly appropriate for
ALL CAs under the PEM umbrella.
(Also, the COST PEM system is non-compliant because their "PCA" fails
to participate in the global CRL database scheme. This would require
non-COST PEM users to have to contact COST PEM CAs to retrieve CRLs
that otherwise should be available by request to each user's PCA.
This sort of non-compliance would impose an undue burden on the rest
of the PEM user community. Thus I cannot see the COST PEM system
being certified by the IPRA, but rather it may operate as an island
outside of the PEM certification system. It's a pity, since COST PEM
could offer its CA-centric CRL service as AN ADDITIONAL service,
participate in the required PCA-centric CRL service, and thus comply
with the PEM certification system standards. Mr. Muftic claims
complaince with PEM, the message format, but not PEM, the
certification system, which is antithetical to interoperability
purposes.)
Bob suggests that "many of these difficulties will be
alleviated when we all have access to a distributed X.500 system." He
admits that X.500 is not intended to provide precisely synchronization
throughout the system, and observes possible problems with flushing
caches in directories. I am completely puzzled by these comments. In
practice, there is no guarantee that a ubiquitous X.500 system will be
any more responsive with regard to CRL propogation than the system we
have proposed for initial PEM deployment. There are no guarantees
that a CA would update the CRL entry in the relevant DSA any faster
than he would provide it to his PCA for inclusion in the global CRL
database! If the CA cannot directly update his entry, e.g., if he
must go through a DSA administrator as Bob envisions in his
discussion, then one can argue that this indirection may introduce
just as much delay as going through a PCA. Also, retrieving a CRL
from a DSA provides no more assurance about its timeliness than
retrieving it from the PEM CRL database. As noted above, the current
PEM CRL database design is intended as an interim measure which
micmics the functionality of X.500 (for CRL retrieval), via an email
interface.
Bob cites several potential difficulties associated with
frequent, demand drived fetching of CRLs (or verifications of
indivdiual user certificate validity). These are valid concerns, and
if anything, they argue against requiring this instantaneous service
for ALL PCAs, or suggetsing to users that ALL PEM messages be
validated in this fashion, etc. These concerns are among the
motivations for the less dymanic CRL model embodied in X.500 and PEM
today.
A few later messages address some of Bob's comments, but soke
of these message also embody some confusion about what is required for
support of non-repudiation. For example, Anish Bhimani commented on
the possible need for timestamping retrieved CRLs, but I think he was
following through on Bob's (incorrect) comment about a requirement for
this capability under the current PEM system. Let me try to state
what I believe is required for high quality non-repduaition under the
current scheme:
- The recipient of a signed message should have the message
hash signed by a timestamp notary, to verify that the message was
received by the recipient no later than the timestamped indication.
While PEM does not contains any specific provisions for timestamp
notary operation, I believe such a facility can be construsted on top
of the existing PEM protocols and work is underway to do just that.
- The recipient must collect the full certification path for
the sender, and there is a provision for providing exactly this data
with the message.
- The recipient must collect a CRL from the CA, the PCA and
the IPRA. The CRL from the CA must be issued AFTER the timestamp
value, to show that the user's certificate was valid at the time the
message was timestamped. The CRLs from the PCA and IPRA must be dated
to cover the time when the CA and PCA CRLs (respsectively) were
issued.
- To protect against the effects of compromise of the IPRA's
private key, and thus ensure the integrity of the CRL chain, one could
have the IPRA's CRL timestamped by a notary. However, then one has to
deal with the question of who certifies the notary's public key and
manages the CRL on which it would be listed, or what form of public,
widely distributed checkpoints are available to prevent backdating of
notary-applied, timestapmed, signatures. Because compromise of the
IPRA key would be really awful for this system, it isn't clear that
this last level of timestamping is generally necessary.
There is lots more to say about the subsequent message in this
thread, but I'm leaving town again for a week and don't have time
right now. Still, having read the message from Tom Jones on 9/20 (it
was sandwiched between Bob's message and the COST PEM message), I must
ask if Tom really reads the RFCs about which he complains so
frequently? His message asks what a certificate is and, having
answered his own question, postulates that there are only two possible
reasons for revocation. RFC 1422 states what a certificate is quite
clearly and explains the precise reasons for revocation. Other that
Tom's continuing confusion between authorization and authentication,
the rationale provided in 1422 roughly matches the reasons he
provides. Tom's continuing harrangue, the avowed purpose of which is
to convince us that symmetric key distribution is better than
certificate-based public-key distribution, is even less persuasive when
attributable from an obvious lack of reading of the RFCs.
Steve