[Top] [All Lists]

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

1999-03-12 09:10:21
Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> 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 
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" <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 

<Prev in Thread] Current Thread [Next in Thread>