Elliott,
IMHO, the purpose of protocol specifications is to provide the minimum
amount of information necessary to ensure that independent organizations can
build products that are interoperable. IMHO, your error reporting proposal
is not required for interoperability. The S/MIME specs should not mandate
design constraints that are not required for interoperability. The customer
should be allowed to make those decisions. If a vendor does not properly
implement error processing, then the customer should not buy that product.
I believe that there is sufficient information in the X.509 Recommendation
and PKIX I specs from which the local organization can determine the optimal
error-handling strategy for their environment, so I disagree with the
addition of your proposed text. The S/MIME CERT spec should only include
info that is unique to S/MIME message processing. The reporting of cert
path validation errors is not specific to S/MIME. It is a topic that
belongs in the PKIX WG, not S/MIME WG.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================
At 08:12 AM 4/10/98 -0400, Elliott Ginsburg wrote:
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