Welcome back, Steve. I was beginning to wonder whether
you had fallen off a cliff. :-)
I also believe that the recent thread on CRL management
was significant, and I believe that as a result of these
discussions some real progress was made. In particular,
I believe that we have agreement with several of the
most significant "commercial" PCAs (notably the RSA
Commercial Hierarchy PCA and the COST PCA) as
to what the requirements should be in this area. I should
also say that most of these issues are generic to any
digital signature system, and not necessarily specific to
PEM. The pem-dev board is just the most convenient
place to discuss them.
Without reiterating all of the previous arguments, let me
comment on a couple of your points and summarize what
I think this thread has concluded:
1. The current PEM RFCs require that CRLs be posted
at least every 30 days. If, as you agree, it is necessary
to archive the CRL _following_ the issuance of
a message in order to assure nonrepudiation,
the maximum time would be 60 days. Those intervals
were _not_ arbitrary choices on my part, as they are in
the current RFCs and were specified by several
commercially important PCAs. I was merely
pointing out that this much latency was totally
unacceptable from the standpoint of virtually all
commercial transactions, and even for routine private
correspondence it was perhaps an unreasonably long
time.
2. As a result of those discussions, I suggested
that PCAs consider adopting a rule that would
require CRLs to be posted at least every 14 days
(nextUpdate = D+14), but that the _nominal_
period between updates should be 7 days. This
would allow the CA, the PCA, and the various users
a grace period of 7 days to recover from technical
or procedural glitches before a CRL would be
considered stale. This would also allow the CAs
and the users to retrieve current CRLs over the
weekend, which would minimize Internet traffic
and even toll charges for dial-up users. Although
two weeks is longer than I would prefer, I believe
that a 7 day nominal and a 14 day maximum
period between CRL updates represents a reasonable
compromise for many, and perhaps most, business
purposes. I believe that the RSA Commercial Hierarchy
PCA and the COST PCA(?) will adopt this guideline.
(I also understand that the MIT PCA has a more
stringent CRL update poliocy that 30 days, but I
don't yet know the details.)
3. The discussion served to clarify one point about which
there was some confusion, namely that the PCA
is obligated to post (i.e., at least make available
for a "pull" inquiry) any emergency CRL as quickly
as possible -- waiting until the next scheduled update
time is not acceptable. I also observed that the
user should have the right to have his or her CA
transmit an emergency CRL on an urgent basis;
and that in the case where an employee becomes
"unaffiliated" on less than friendly terms, the CA
should promptly revoke his certificate. Therefore, if
revocation "matters" (i.e., if it is more important than
a simple change of address or name change), then a
current CRL would be available on demand for anyone
who needed it, certainly on a less than 24 hour basis.
4. Although the 7/14 day distribution cycle should
solve the certificate validation problem for most
routine business correspondence, and retrieving the
current CRL from the PCA would be sufficient for
most EDI transactions as well, even a 24 hour response
time may not be sufficient for certain high value or
time critical applications, e.g., buying or selling
stock or conducting currency arbitrage. Admittedly,
this is pretty clearly outside of the scope of PEM
per se, but it does bear on the functionality that
is required of a CA. (I certainly hope and expect
that we wil not have to have two different CAs
within one organization, one or PEM and one for EDI,
when both are using the same X.509 certificate
and the same digital signature algorithm.) For such
purposes, it is necessary to have a very dynamic,
real-time access to the CRL. At that point, we
began to realize that it would be better to go to the CA
directly for such purposes -- the PCA just gets in the
way.
5. About this time, a more important philosophical point
began to emerge regarding the trust model and who
was responsible for what. It is clear that there is a
very close trust relationship between the CA and the
user. In most cases, IMHO, the CA will be the user's
employer or at least a highly respected industry
authority, such as a Federal Reserve bank for the
banking industry. And as Peter Churchyard pointed out
the CA can impersonate anyone within its domain
of authority (a very good reason for insisting on
name subordination). However, I as a user do not have
any kind of contractual relationship with the PCA,
and therefore I cannot enforce any requirements
upon the PCA, nor the PCA on me. I therefore have
no legal, i.e., enforceable, basis for trust in the PCA
(or in the IPCA, for that matter). If the PCA fails to
post a CRL, neither the originator nor the recipient
is likely to have any legal recourse. And because
the liabilities might be huge, any PCA with a decent
lawyer will make sure that no warranty or other
representation is made that would imply any liability
on the part of the PCA. The upshot of this argument is
that both the originator and the recipient of a signed
document are much better off making direct inquiries
of the CA, rather than the PCA, as to the validity of a
user's certificate.
6. Finally, I tried to think through exactly what would be
required in order to provide nonrepudiation of an
archived document, especially as regards the validity
of a user's certificate at the time that the document
was allegedly signed. In the past, we have discussed,
and I have been assuming that it would be necessary
for the recipient to send a copy of the signed message
to a trusted timestamp service in order to establish
when the message was received. But unless the CA
is required to to be _accurate_ with respect to the
date and time of any CRL, it would be necessary
for the trusted timestamp server to also go to the
PCA and request the latest CRL, and then timestamp
that. It is not sufficient for either the originator or the
recipient to retrieve the information, for they might not
provide the latest one. Unfortunately, this now requires
that the trusted time server actually _do_ something,
and do it reliably. It is not sufficient to simply file
a request in a chronological file. I also noted that it is
unfortunate that the PCA is not required to affix a
trusted timestamp to the CRL at the time the CRL
is posted -- now we have to trust that the PCA posts
the CRL promptly.
7. It then occurred to me that a simpler and more elegant
method of assuring nonrepudiation is to ask the CA
directly "Is the referenced certificate valid as
of the current date and time?" And better yet, in
order to eliminate the sunchronization between
the message and the certificate, have either the
originator or the recipient of the message send the
digital signature of the message in question, and
ask the same question. The CA would then answer
the question and sign both the answer and the digital
signature of the original message. It would be helpful
if the CA would also append an accurate timestamp,
for synchronization with external events such as laws
regulations, but this is not as necessary as with the
previously assumed mechanism.
Since the CA is responsible for issuing and revoking the
user's certificate, it can speak authoritatively and
conclusively as to whether the certificate has been
revoked or is presumed to be valid at that particular
moment in time, without having to be absolutely precise
as to exactly when that time was. This is not only much
simpler than the current system of having to wait for the
next issued CRL, but it puts the burden of trust where it
belongs -- on the CA.
Although I would like to see this approach to
nonrepudiation architected and standardized rather
than being subject to ad hoc approaches, I believe
that it can be developed as a CA function that is
independent of PEM. Since the COST people have
been quite responsive to addressing the needs of
business users, I hope they will develop this capability
and publish essentially a defacto standard. Other
implementors will then have a refenrence model to guide
them, instead of requiring another year's worth of
discussion as to whether this is worthwhile.
Finally, with regard to the issue of mapping a CA's DN to
its mailbox address, it seems to me that this is a
major deficiency in the current X.509 certificate definition,
at least to the extent that PEM has pre-empted its
original purpose of authenticating access to a directory
which would presumably contain this information.
For that reason, in a recent message I proposed to Hoyt
Kesterson that the X.509 standards group consider
adding optional fields to contain such information as
e-mail address, physical address, etc., both for CAs and
users.
At the present time, we are being forced to burden the
DN with all sorts of semantics for which it is not well
suited. Worse yet, some of the semantics may be
mutually exclusive, such as in the case of a "Guest" user
who receives his mail and may even be issued a
certificate by a CA, but who is not employed or otherwise
affiliated with or accountable to that organization.
Another example is a user or CA which is connected
through CompuServe or Dockmaster.
Granted that some of these problems could be solved by
the kind of "hacks" of the type that I have become
rather infamous for proposing, e.g., adding another
attribute for e-mail address and incorporating it in the
DN as a multivalued RDN, these are at best bad
workarounds and very poor architecture, and almost
certain to bite us in the end (pun intended).
As I concluded in that message, I think we either need to
fix PEM and add this type of information, departing if
necessary from X.509; or fix X.509, and adopt/modify
PEM to use or at least tolerate the new format. If we
don't do it now, the problem will become almost infinitely
worse as the number of users increases.
Bob Jueneman