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

jsp@jgvandyke.com (John Pawling) Mon, 15 March 1999 17:01 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 MAA22532 for <smime-archive@odin.ietf.org>; Mon, 15 Mar 1999 12:01:33 -0500 (EST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13690 for ietf-smime-bks; Mon, 15 Mar 1999 07:45:58 -0800 (PST)
Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13686 for <ietf-smime@imc.org>; Mon, 15 Mar 1999 07:45:57 -0800 (PST)
Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id KAA03684 for <ietf-smime@imc.org>; Mon, 15 Mar 1999 10:58:17 -0500 (EST)
Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id KAA27654; Mon, 15 Mar 1999 10:55:37 -0500
Date: Mon, 15 Mar 1999 10:55:37 -0500
Message-Id: <199903151555.KAA27654@ajsn101.jgvandyke.com>
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf-smime@imc.org
From: jsp@jgvandyke.com
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
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,

You stated:
>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 agree that the CMS RecipientInfo CHOICE syntax could be modified in future
versions of CMS through the addition of well-defined ASN.1 syntaxes, but I
disagree that adding "..." in the current CMS RecipientInfo syntax adds any
value.  If your use of "extended choice" refers to a RecipientInfo including
a CHOICE alternative not specified in the CMS document, then I object to
your statement that implementors "should not object if the they receive an
extended choice."  Please see my previous message for the explanation of why
I object to the premise that it is straightforward for recipient software to
ignore undefined CHOICE alternatives. 

- John Pawling