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

["ross@secstan" <[e-mail]>]

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
that issue.
-----Original Message-----
From: Peter Gutmann <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 12 March 1999 16:38
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS


>Paul Hoffman / IMC <[e-mail]> writes:
>
>>Peter has posted an Internet Draft for an addition to CMS. I think it is
very
>>late for us to be adding things for which there is disagreement on how to
put
>>it in. We can discuss Peter's draft and decide if we want to pass it out
of
>>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
CMS
>RFC - that can proceed as usual, and the PWRI RFC could be developed at its
>own pace.
>
>>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
send
>>encrypted email where the key is derived from a previously agreed-upon
>>password.
>
>I don't think this is such a good idea, it's a significant change to the
CMS
>RFC at a late stage (which I was trying to avoid by having an independent
PWRI
>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" <[e-mail]> 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
>added.
>
>Peter.
>
>