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.
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.