Jim,
Thank you very much for your comments. I have the following responses:
1) Agree.
2) I don't believe that we need to add text regarding the validation of the
originator's cert. RFC 2632 (CERT), section 1 states: "Before using a
public key to provide security services, the S/MIME agent MUST certify that
the public key is valid." I believe that covers the case of validating the
originator's cert.
3) Agree. Recommend the following text:
"7. SMIMECapabilities Attribute Conventions
7.1. RFC 2633, Section 2.5.2 defines the SMIMECapabilities signed attribute
(defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a
partial list of algorithms that the software announcing the
SMIMECapabilities can support. When constructing a signedData object,
compliant software MAY include the SMIMECapabilities signed attribute
announcing that it supports the KEA and SKIPJACK algorithms.
7.2. The SMIMECapability SEQUENCE representing KEA MUST include the
id-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include
a KeyWrapAlgorithm SEQUENCE in the parameters field. The algorithm field of
KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID. The parameters field of
KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD
be included in the key management algorithms portion of the
SMIMECapabilities list. The SMIMECapability SEQUENCE representing KEA MUST
be DER-encoded as follows: <TBD: insert ASCII characters representing hex
values here>.
7.3. The SMIMECapability SEQUENCE representing SKIPJACK MUST include the
id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the
parameters field MUST be absent. The SMIMECapability SEQUENCE for SKIPJACK
SHOULD be included in the symmetric encryption algorithms portion of the
SMIMECapabilities list. The SMIMECapability SEQUENCE representing SKIPJACK
MUST be DER-encoded as follows: <TBD: Insert ASCII characters representing
hex values here>."
Does anybody disagree with these changes?
============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
john(_dot_)pawling(_at_)wang(_dot_)com
<mailto:john(_dot_)pawling(_at_)wang(_dot_)com>
============================================
-----Original Message-----
From: Jim Schaad (Exchange) [
mailto:jimsch(_at_)Exchange(_dot_)Microsoft(_dot_)com
<mailto:jimsch(_at_)Exchange(_dot_)Microsoft(_dot_)com> ]
Sent: Thursday, November 18, 1999 1:41 PM
To: John Pawling (E-mail)
Cc: Ietf-Smime (E-mail)
Subject: Comments on draft-ietf-smime-cmskea-02
1. It would be useful if section references to CMS included section numbers
rather than just section titles. An example is the first paragraph of
section 4.
2. Section 4.2.2 --- One of the discussion that I have every so often with
you and Russ deals with the question of validating the originators
certificate during the decrypt process. The current text makes no reference
to doing this or what should happen if this validation fails. Is this what
you want? Do you want to put in some text about doing the validation and
what to do if it fails? Suggested text could run along the lines of "If the
originators certificate is used for the purposes of origination
authenticiation, then the originators certificate MUST be validated prior to
decrypting the message and the decryption MUST NOT proceed if the validation
fails."
3. The document is missing the specification of the SMimeCapability field
to be used for CMSKEA. Please include a small section with the necessary
parameters and a binary version of the encoded attribute so that everyone
uses the same byte sequence.
jim