All,
I believe that I can answer my first question. "external signatures" are
needed to support the application/pkcs7-signature MIME Type. Please ignore
my first comment. All of my other comments/questions still apply.
- John Pawling
Return-Path: <owner-ietf-smime(_at_)imc(_dot_)org>
Date: Mon, 17 Nov 1997 19:12:05 -0500
X-Sender: jsp(_at_)ajsn101
To: ietf-smime(_at_)imc(_dot_)org
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: Comments to CMS-01
Sender: owner-ietf-smime(_at_)imc(_dot_)org
Precedence: bulk
Russ (and friends),
Thank you for incorporating my previous comments into the November 97
Cryptographic Message Syntax (CMS-01). I have a few comments to CMS-01:
1) Sec 3, last para: This paragraph discusses "external signatures". This
concept adds significant complexity to the CMS security services. Is it
really needed?
2) Sec 3, last para: If it is decided that the CMS spec still needs to
support "external signatures", then the following issue needs to be
clarified. Is it true that the signatureValue in a SignedData object in
which the content is absent is calculated exactly as with a SignedData in
which the content is present? If so, then please add a sentence to the last
para of Sec 3 stating that fact.
3) Sec 3, last para: If it is decided that the CMS spec still needs to
support "external signatures", then please add the following sentence: "In
this case, the content type within the ContentInfo must be id-data and the
content field of the ContentInfo must be omitted (i.e. absent)."
4) Sec 5.2: This references PKCS #9. The WG still needs to duplicate the
PKCS #9 contents in an IETF-controlled document. The CMS should then be
changed to reference the IETF-controlled document.
5) Sec 6, Intro, Step 3: Do you think that it is worthwhile to mention in
the CMS spec that a sending agent should include a copy of the
content-encryption key that is protected using the originator's key material
so that the originator can always decrypt the message?
6) Sec 7.1: This section states: "The definition of
CertificateRevocationList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateRevocationList".
However, the 97 X.509 Recommendation includes the following definition of
CertificateRevocationList:
"certificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID
id-at-certificateRevocationList }
CertificateList ::= SIGNED { SEQUENCE {
version Version OPTIONAL,
-- if present, version must be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL }
OPTIONAL,
crlExtensions [0] Extensions OPTIONAL }}"
I believe that the intent was for the CMS SignedData and OriginatorInfo
syntaxes to include a SET OF CertificateList rather than SET OF
CertificateRevocationList (which would be a SET of attributes containing
CertificateLists).
In summary, please change sec 7.1 to state: "The definition of
CertificateList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateList".
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================