From: jueneman%wotan(_at_)gte(_dot_)com
To: Steve Kent <kent(_at_)bbn(_dot_)com>
Cc: pem-dev(_at_)tis(_dot_)com
...
With regard to the stuff below, it occurs to me that CAs and/or PCAs
could offer a service where they forwarded mail with their own
signature and time. With this feature a user could just include their
own certificate in the mail and send it to, for example, their CA.
The CA would perform a number of checks (reasonable date&time,
currently valid certificate, etc.), perhaps manipulate the address
headers such as the To: field a bit, and then create a new message
containing the modified original message and signed by the CA, with
the date&time of signing and the CA's certificate. Etc. While this
might create a choke point if the volume were too high the CA can (1)
set up multiple hosts that provide this service and/or (2) charge for
it.
(Perhaps something more elegant can be done but it would be adequate
to just use the % hack and send mail for user(_at_)host(_dot_)xxx to
user%host(_dot_)xxx(_at_)CA(_dot_)xxx(_dot_) The CA can detect that it is
forwarding
mail for someone with a certificate it issued and act as above if
it is providing this service.)
Donald
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.
...
Bob Jueneman