RE: Comments on draft-ietf-smime-cmskea-02
"Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com> Thu, 18 November 1999 21:06 UTC
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02087 for <smime-archive@odin.ietf.org>; Thu, 18 Nov 1999 16:06:23 -0500 (EST)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA05146 for ietf-smime-bks; Thu, 18 Nov 1999 12:28:32 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05142 for <ietf-smime@imc.org>; Thu, 18 Nov 1999 12:28:31 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XB2W25ZY>; Thu, 18 Nov 1999 12:29:30 -0800
Message-ID: <EAB5B8B61A04684198FF1D0C1B3ACD194A7135@dino.dns.microsoft.com>
From: "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
To: "'Pawling, John'" <jsp@jgvandyke.com>, "Ietf-Smime (E-mail)" <ietf-smime@imc.org>
Subject: RE: Comments on draft-ietf-smime-cmskea-02
Date: Thu, 18 Nov 1999 12:28:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-smime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Not having anyting for item 2 is fine with me. I have no arguments with the proposed text. -----Original Message----- From: Pawling, John [mailto:jsp@jgvandyke.com] Sent: Thursday, November 18, 1999 12:10 PM To: Ietf-Smime (E-mail) Subject: RE: Comments on draft-ietf-smime-cmskea-02 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.pawling@wang.com <mailto:john.pawling@wang.com> ============================================ -----Original Message----- From: Jim Schaad (Exchange) [ mailto:jimsch@Exchange.Microsoft.com <mailto:jimsch@Exchange.Microsoft.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
- Comments on draft-ietf-smime-cmskea-02 Jim Schaad (Exchange)
- RE: Comments on draft-ietf-smime-cmskea-02 Pawling, John
- RE: Comments on draft-ietf-smime-cmskea-02 Jim Schaad (Exchange)