Re: More on KEKIdentifiers, and a suggested addition to CMS

"John Ross" <ross@secstan.com> Mon, 15 March 1999 10:32 UTC

Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19454 for <smime-archive@odin.ietf.org>; Mon, 15 Mar 1999 05:32:38 -0500 (EST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA08771 for ietf-smime-bks; Mon, 15 Mar 1999 01:16:13 -0800 (PST)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA08767 for <ietf-smime@imc.org>; Mon, 15 Mar 1999 01:16:11 -0800 (PST)
Received: from jrwork (e2c9p51.scotland.net [148.176.238.51]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id JAA06531; Mon, 15 Mar 1999 09:22:11 GMT
Message-ID: <002c01be6f07$c0709350$0400000a@jrwork>
From: John Ross <ross@secstan.com>
To: pgut001@cs.aucKland.ac.nz, ietf-smime@imc.org
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Date: Mon, 15 Mar 1999 09:17:38 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-smime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I agree with Peter, CMS should allow the extension of the Choice syntax
 i.e. in text using  the old ASN.1 rules), which gives a good pointer to the
implementors that they should not object if the they receive an extended
choice.

I also agree with John Pawling, that any extension must be controlled and
should only be done when there is a requirement not met by the current
syntax. As per Peter's comment, control of the choice can be achieved by the
normal RFC process.  Also, if more control is required on S/MIME for
interoperability reasons, the S/MIME specification  (not the CMS spec) could
prohibit the expansion of the choice unless a new version number is agreed.


Regards
JR