I understand your objections and those of others, and I'm not at all sure
what is appropriate to put in a standard. However, I'm still concerned that
what we've got so far is not sufficient. In your response, you say you
believe that local organizations should decide what actions to take. I
AGREE COMPLETELY WITH THIS. My point is, the spec doesn't say anything
about leaving these decisions to the customers; it says that the products
must do something. I way trying to find a way to assure that customers
would be able to implement their own policies, rather than having the
products hardwire the actions to take. For example, if a product rejects
any message whose signature does not validate, this is implementing a
particular policy.
I think we all agree that we'd like to have products that allow customers
(recipients or system admins) to configure policy. The question is, what,
if anything, do we put in the standard to assure we get products that allow
this in one way or another? My suggestion of having a set of identified
errors was an attempt to push products in this direction.
I'm certainly open to any suggestions of how to proceed. I've considered
the possibility of, rather than requiring anything, instead including a
good discussion in the security section to at least make sure this issue is
well inderstood.
Suggestions?
elliott ginsburg
At 07:03 PM 4/9/98 , John Pawling wrote:
Elliott,
I respectfully disagree with your proposal because I believe that it is too
detailed for inclusion in the S/MIME Cert I-D. I believe that the local
organizations should decide what specific actions should be taken in the
case of cert path and signature validation errors. I believe that there is
sufficient information in the X.509 Recommendation and PKIX X.509
Certificate/CRL Profile (PKIX I) from which the local organization can
determine the optimal error-processing strategy for their environment.
You stated:
I also proposed a return status mechanism which can be used both for
configuration and by automated processes. Because it is specified in the
spec, it is interoperable.
I especially disagree with the inclusion of the PKIStatusInfo SEQUENCE in
the S/MIME CERT I-D because I don't believe that there is a requirement for
this error info to be communicated between applications, so IMHO there is
not an interoperability requirement. This error information is only used
locally by the application, so there is no reason to mandate a standard
ASN.1 syntax to hold the info. It makes sense in the CMP I-D because the
error info will be communicated between platforms on a regular basis, but
this is not needed in the case of an S/MIME agent encountering an error.
In summary, I believe that the S/MIME CERT I-D should be left as is. If
anything, we should delete the last three paragraphs of CERT, Section 5
because that text is redundant to X.509 and PKIX I.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================