Steve,
Thank you very much for your feedback. My replies are in-line:
At 09:24 PM 9/25/98 +0100, Dr Stephen Henson wrote:
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.
[JSP: In the case of id-dsa-with-sha1, there was no specific discussion
during the meeting of accepting a NULL parameter. The proposed text for
CMS, Sec 12 regarding id-dsa-with-sha1 includes the following:
"12.2.1 DSA
The DSA signature algorithm is defined in FIPS Pub 186 [FIPS 186]. The
algorithm identifier for DSA is:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }
The AlgorithmIdentifier parameter field must not be present."
In my opinion, if the receiving software is supposed to be tolerant of a
NULL parameter in this case, then that fact should be specificaly stated in
CMS, Sec 12.2.1. Personally, I believe that a NULL value should be
tolerated, especially since the X9.57 document that defines this OID is
ambiguous regarding this point.
In summary, I believe that you have a valid comment regarding CMS Section
12, but not against the minutes since this issue was not discussed regarding
this specific OID.]
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?
[JSP: There was no specific discussion of this issue during the meeting.
The proposed text for CMS, Sec 12 regarding RCS CBC includes the following:
"12.5.3 RC2 CBC
The RC2 algorithm is described in RFC 2268. The algorithm identifier for
RC2 in CBC mode is:
RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2}
For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as:
RC2-CBC parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING (8)}
For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0)
is a negative number in ASN.1."
Does this answer your question???]
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.
[JSP: Were these statements made during the meeting? I confess that I did
not hear every word said during the meeting and that the tape player that I
used to record the meeting was not sensitive enough to pick up every word
said at the meeting. The minutes of the meeting are supposed to cover the
events of the meeting. If these statements were made during the meeting,
then I do not object to their inclusion in the minutes. The minutes are not
intended to cover every possible point (valid though they may be) regarding
a topic, so if these statements were not made during the meeting, then I
don't believe that they should be included in the minutes.]
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?
[JSP: This issue was not specifically discussed during the meeting. I
believe that you have a valid comment regarding CMS, but not against the
minutes.]
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.
[JSP: Recommend that you continue to pursue this point on the list.]
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.