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

pgut001@cs.aucKland.ac.nz (Peter Gutmann) Tue, 16 March 1999 05:21 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 AAA29413 for <smime-archive@odin.ietf.org>; Tue, 16 Mar 1999 00:21:51 -0500 (EST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA23531 for ietf-smime-bks; Mon, 15 Mar 1999 20:20:49 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA23522 for <ietf-smime@imc.org>; Mon, 15 Mar 1999 20:20:46 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id RAA32147; Tue, 16 Mar 1999 17:27:07 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92155842632353>; Tue, 16 Mar 1999 17:27:06 (NZDT)
From: pgut001@cs.aucKland.ac.nz
To: ietf-smime@imc.org, ross@secstan.com
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Reply-To: pgut001@cs.aucKland.ac.nz
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 16 Mar 1999 17:27:06 -0000
Message-ID: <92155842632353@cs26.cs.auckland.ac.nz>
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>

"John Ross" <ross@secstan.com> writes:
 
>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.
 
This sounds like a good way to handle it, that way MSG can profile the stuff
specifically required for S/MIME leaving CMS able to be extended to handle
things which aren't necessarily useful for S/MIME, but are useful for other
applications (things like protection of stored data, of which PKCS #15 is a
prime example).
 
Peter.