A few comments.
John Pawling wrote:
Slide #3: Signature Algorithms:
DSA-with-SHA1 is mandatory to implement. The attendees decided that the CMS
I-D will state that the parameters must be absent (not ASN.1 NULL). This is
required for consistency with PKIX Part I.
I presume it is implied that a NULL parameter should be tolerated. I
know of some implementations that generate NULL.
Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
document RC2 in CBC mode as a "should" to implement (rather than "may").
The RC2-CBC OID will be used.
Will this include the number of bits that may/should be supported as
well?
1) Denis Pinkas asked if there was a way to verify the "correctness" of a
CMS message. Dennis considers signature generation time to be a critical
factor in determining whether or not that signature is valid. If the
signing key is revoked, then the signing time would indicate if the message
signed before or after the revocation date. John Pawling pointed out that
the MSG I-D already states that the signingTime attribute should always be
included in signed messages. The attendees agreed that wording was
sufficient.
IMHO this may need an additional comment.
For example should the valdity (i.e. expiry) of the signing certificate
chain use the current time or the signingTime?
The signingTime attribute cannot be trusted in many cases.
If a certificate is revoked due to key compromise an attacker could
generate a message with a signingTime before it was revoked.
The corollary to this is that if a certificate has been revoked then the
posession of a signed message with a signingTime before the revokation
time is not sufficient for nonrepudiation purposes. Some corroboration
as to the signing time is required: such as a trusted timestamp
countersignature.
3) Doug Maughn asked about the processing requirements for generating a
countersignature. It was proposed on the list that the generator of a
countersignature must validate the original signature before generating the
countersignature. Russ has included that proposal in the CMS draft that he
has not yet published. He stated that "validate" means verify the signature
value of the CMS signedData, not necessarily validate the signer's cert path.
Does "verify the signature value of the CMS signedData" imply that just
the digital signature of the signedData is checked or the messageDigest
value as well, implying that the original content must be checked?
IMHO checking signedData is tolerable but the original content
verification has very serious implications, as I've mentioned before.
Even so this affects some existing implementations: for example the
Verisign AuthentiCode timestamper just takes the signedData signature
and produces a trusted timestamp countersignature from that.
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.