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
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" <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
added.
Peter.