Tom,
This is a point I still do not understand -- HOW DOES THE
RECIPIENT OF A PEM MESSAGE KNOW WHERE TO SEND A REQUEST FOR A
CERTIFICATE OR A CRL? All that PEM puts in the message is the
Distinguished Name of the CA. Where will the "PEM user agent" go
"automatically" to get the required certificate?
Every PCA is required (RFC 1422 3.4.2.5) to provide an interface to a
global CRL database, and every user is expected to know the email
address of his PCA. RFC 1424 provide the format for email requests
against this database. PCAs may provide other means of CRL database
access beyond what is required by the RFCs.
--- Next thought
<delected 1422 text>
If the PEM user agent "really" needs a current CRL, I can see why there
is no reason to put a certificate into a PEM message, since the
recipient can NEVER trust a certificate without looking for ALL
hierarchical CRL's..... Or am I missing something obvious.
As 1422 states, there is an assumption that a user will cache
certificates and CRLs, to facilitate processing for both message
reception and submission. It is possible (likely) that you will have
cached a CRL for a CA, but will not have all the certificates issued
by that CA. Thus inclusion of a full certification path in a message
can be useful even without sending a full CRL list.
--- Next thought
Imagine this.. A company employee is certified by the company. (As I
understand it, this is the standard way to go.) The company
issues a PO signed by the employee. Until the next time that
someone requests a CRL the company seems to have the right to list the
employee's certificate on its CRL. Therefore it would seem that
unless the CRL is requested immediately prior to accepting a PEM
message, the PEM message can legitimately be repudiated by the
company. Please show me how this logic fails.
This issues has been discussed before, Tom. For non-repudiation
purposes, the requirement is really to have the CRLs issued AFTER the
message was signed, so that they cover the interval during which the
message was signed. Having the CRLs issued before the message was
signed still leaves open a window of vulnerability for repudiation. I
think this illustrates a difference between the more casual processing
of a signature for message origin authentication vs. non-repudiation.
For authentication, most users are probably willing to live with
validation against the "current" CRL, whereas for non-repuidation, it
is the next CRL that is required. Of course, people may choose to
initiate delivery of goods based on a current CRL check, and live with
the consequences, especially for small-value transations.
Tom Jones - ViaCrypt div. of Lemcom Sys
Steve Kent