I agree with Steve in that it should not be mandatory that a counter signer
verifies the original content.
S/MIME needs to allow for a recipient to detect that the counter signer has
verified the contents not force counter signers to check the contents,
since in some cases the verification is unnecessary and possably
impossible.
Tim Dean has proposed a solution to identifying counter signers which have
verified the content by using the SignatureType attribute defined in
draft-ietf-smime-domsec-00.txt. I agree that this is a valid solution but I
don't believe it is the best solution for this problem. For a SignatureType
attribute to be present the signer has to meet different requirements
depending on what type to use. For example, if the type is 'domain' then
the content must be verified. Other types may not have this requirement.
This could lead to types of 'TimestamperContentsVerified' and
'TimestamperContentsNotVerified'. As more and more types are introduced the
more messy this gets.
A far better solution would be to have an authenticated attribute, within
the SignerInfo, which must be present when that signer has verified the
contents.
Bill.
------------------------------------------------------
William Ottaway,
L323, Tel: +44 (0) 1684 894079
DERA Malvern, Fax: +44 (0) 1684 896113
St. Andrews Road, email:
w(_dot_)ottaway(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk
Malvern,
Worcs,
WR14 3PS
-----Original Message-----
From: Dr Stephen Henson
[SMTP:shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk]
Sent: Friday, October 02, 1998 9:18 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Countersignatures and verification of original content.
There has been some debate as to whether a countersigner should always
verify the original content of a message. IMHO there are compelling
reasons for not enforcing this which I'll mention below.
I'm not saying that a countersigner cannot verify the original content
just that it should not be forced to do so.
One form of countersigner is a trusted timestamping authority. Its
purpose is solely to demonstrate that a signature existed at a certain
time. As has been mentioned before, such a signature has an essential
puropose for nonrepudiation.
In addition it can be used to demonstrate the validity of a signature
after the certificates have expired: for example if CMS is used for code
signing. The alternative would be for software signatures to become
invalid after their certificate has expired (and they would typically
stop working) this is clearly unacceptable. The trusted timestamp could
cover several hundred Mb of data (for example an MPEG file).
Current systems of timestamping (for example the Verisign authority)
allow a request to be sent in plain text using HTTP. The request
includes just the SignatureValue portion of a SignerInfo structure. The
returned data is usable as a counterSignature attribute to establish the
signing time of the message.
In this case no attempt is made to verify the original content because
this is not necessary: no statement is being made by the timestamper
about the original content.
If the original content must be verified even for a timestamp then this
has several consequences.
1. Volume of data.
Potentially very large amounts of data would need to be passed to a
countersigner. This would make it impracticable to use over dial up
lines for example.
2. Security issues.
Currently only the digital signature is sent in plain text over http. If
the content needs to be verified as well, then potentially sensitive
data would need to be passed over insecure networks. This would
necessitate the use of some secure means of transferring the data such
as S/MIME envelopedData or SSL. Encryption laws in some countries would
mean that only inadequate weak encryption could be used for such
purposes. In some countries encryption would not be permitted at all.
3. Privacy issues.
If the content needs to be verified then the timestamper needs to be
sent a copy of the original content. The potential for abuse is
considerable. I for one would be very reluctant to send copies of all my
signed mail to a timestamping authority.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.