I am happy to use '...' in the choice syntax, but unfortunately that is not
available when using 1988 ASN.1. So that option is not available.
If there is strong objection to having a "controlled" way of extending the
choice (i.e the OID route), but there is agreement to specifically allow the
equivalent of '...' in 88 syntax (i.e. extend the choice), then there is a
need to add a comment in the ASN.1. Also it would be a advisable to say
under what condition the CMSversion needs to change (if any). Rule are
needed so that there is no misunderstanding on how to expansion the choice
in the future.
Personally I think a new version number is advisable every time the choice
is extended, as that would make the handing of any extended choice easier
to handle on reception. But I am happy to follow the general consensus on
From: Peter Gutmann <pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: 12 March 1999 16:38
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> writes:
Peter has posted an Internet Draft for an addition to CMS. I think it is
late for us to be adding things for which there is disagreement on how to
it in. We can discuss Peter's draft and decide if we want to pass it out
the working group. If we do, it can be a stand-alone RFC. If it gets two
independent implementations, we might fold it into the CMS RFC (if we ever
get there.....) when we move from Proposed Standard to Draft Standard.
The point of making it an independent RFC was that it wouldn't hold up the
RFC - that can proceed as usual, and the PWRI RFC could be developed at its
As an alternative, if the current CMS draft would allow for the 'PBES2'
algorithm identifier defined in PKCS #5 v2 in the set of
KeyEncryptionAlgorithms, there would be no need for changing the ASN.1 in
CMS. Another advantage with this is that it would enable an easy way to
encrypted email where the key is derived from a previously agreed-upon
I don't think this is such a good idea, it's a significant change to the
RFC at a late stage (which I was trying to avoid by having an independent
RFC), and it's rather a kludge. I think it'd be better to leave KEKRI for
what it was intended for and have a dedicated PWRI which specifically
addresses the requirements of password-based encryption.
"John Ross" <ross(_at_)secstan(_dot_)com> writes:
Also, if every extension to the choice needs a new CMSversion number
assigned, that may be a lot of CMSversion around in the future.
You don't need to do this though, if you use '...' as I suggested in a
previous message then implementations will know that there could be further
types added there and skip any new ones they don't recognise. Once this is
done, there's no need to change the version number whenever a new choice is