Francois Rousseau wrote:
In response to Russ request for the "Security Considerations" section of
CMS, I agree with others that CMS should not force a counter signer to
validate the original content mainly for backward compatibility reasons.
For discussion on this mailing list, the suggested addition to ESS about
this new attribute could read as follow:
"6. Countersignature Scope Attribute
The counterSignature attribute from [CMS] includes a digital signature that
is computed on the content signature value, thus the countersigning process
need not know the original signed content. This structure permits
implementations efficiency advantages; however, this structure may also
permit the countersigning of an inappropriate signature value. Although
implementations that perform countersignatures could validate the original
signature value prior to countersigning it (this validation requires
processing of the original content), there are currently no means to
indicate that the original content was validated. This shortcoming, which
might be adequate in most circumstance, does not address scenarios where a
counter signer would have to explicitly indicate whether or not the
original content was validated.
To effectively define the scope of the countersignature, the
counterSignatureScope attribute MUST be present, in addition to existing
attributes that are currently allowed in a counterSignature (e.g.
counterSignature, messageDigest, signingTime, and signingCertificate).
The counterSignatureScope attribute MUST be a signed attribute; it cannot
be an unsigned attribute, an authenticated attribute, or an unauthenticated
attribute.
The following object identifier identifies the counterSignatureScope
content type:
id-aa-counterSignatureScope OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) <TBD> }
The definition of CounterSignatureScope is:
CounterSignatureScope ::= INTEGER {
content validated (0),
-- the countersigning process has validated the content
content not validated (1),
-- the countersigning process has NOT validated the content
}
A counterSignatureScope attribute must have a single attribute value."
I agree with the principle but I would suggest that a BIT STRING would
be more appropriate and have several bits with different meanings to
allow the term "validated the content" to be more precisely stated.
Exactly what bits are used is open to debate. I'll suggest a few
possibilities, some of these could be combined or further qualified.
CounterSignatureScope ::= BIT STRING {
signatureValueValid (0),
messageDigestValid (1),
chainValid (2),
signerNotRevoked (3),
timeStampTrusted (4) }
signatureValueValid: the signatureValue of the signedAttributes is
valid. This need not imply that access to the original content is
available.
messageDigestValid: the messageDigest attribute matches that of the
original content.
chainValid: the signing certificate chain is valid but no revocation
checking has been done.
signerNotRevoked: the signing certificate has not been revoked.
timeStampTrusted: the timestamp on the message can be considered
reliable.
Another possible flag would be that the countersigner verified some kind
of proof of private key possession.
There are several security issues involved. For example for
signerNotRevoked to be useful the signingCertificate attribute must be
present in the original signedAttributes (to avoid a substitution
attack). signerNotRevoked and trustedTimeStamp should imply that the
signing certificate was valid at some time on or after the timestamp.
This allows the counterSignature attribute to cover a whole range of
possible uses from a simple trusted time stamp to reliable
nonrepudiation.
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.