Jim Schaad (Exchange) wrote:
I would strongly disagree that the place to put this is in the CMS or
S/MIME specifications. This is the type of statement which belongs in
the Certificate Policy statment for the certificate itself and not on
individual signatures. I don't see a case where you would have some
signatures from a person being binding and some not binding. (What
happens if the signer forgets to set the bit, does it then become
binding on the corperation?)
The problem with this approach is that it means a person must have
a different certificate for each privillege level they have.
I am anticipating disclaimers of the form 'the value of any contract
agreement entered into under this message is less than $1000'. I
would expect an automated 'contract box' to accept input in the
form of signed S/MIME messages, consult some corporate database of
project budgets and possibly authorize some small value contracts
automatically. Doing this requires either that we solve the AI
problem and parse the contract or we find some other method of
limiting the exposure due to such a device.
Also consider the alternative scheme in which the contracts would
be vetted in some way. There is obviously a need to ensure that
those vetting the contracts do not exceed their authority (e.g.
they are in collusion with some fraud and making authorizations
beyond their authority).
The other problem is that it does not address the four corners issue.
The reason certificate policies were largely abandoned as a means of
specifying the criteria for issuing a certificate was that they
might not be binding in court. As Michael Baum points out, a court
might decide that they are not even admissible. Courts are likely
to decide to restrict their debate to the 'four corners' of the
document in dispute.
So if your disclaimer happens to be in a different document (the
certificate) you may be out of luck.
If you have two documents A and B where A makes mention of B but
B makes no mention of A, A is quite likely to be ruled out in
in a dispute concerning the enforcability B.
This is why the Certificate Practices Statement is bound into
the certificate issued and certificate policy statements are
not generally employed as a means of stating a CA's certification
policy.
The problem Jim raises may well not have a perfect soultion,
but just because we cannot prevent fraud does not mean we should
not do what we can to avoid incompetence!
Also note that if fraud can be proven (as seems likely) there
are other remedies - insurance etc. and the court case is
likely to be of a rather different nature.
A particular form of incompetence that concerns me is the
incompetence of automated signing robots. I suspect that at
some level in the corporate infrastructure there will emerge
a need for some device that is essentially accepting some
input and signing it. I would like to try to ensure that
we can errect some safeguards arround such devices so that
the effects of various attacks can be mitigated.
Phill
smime.p7s
Description: S/MIME Cryptographic Signature