"Jim Schaad" <jimsch5(_at_)home(_dot_)com> writes:
Comments on this draft:
[Minor editing odds and ends]
Thanks. The ASN.1 glitches came about mostly because it was originally done in
'94 and then edited from that back to '88 fairly late, which lead to a little
friction between the two versions.
3. Section 1.2.1: Paragraph 1: The phrase "user-supplied password or
previously agreed-upon key" is somewhat misleading. KEK is the generally used
agreed-upon key method for key managment. Please delete the phrase "or
previously agreed-upon key". (Ditto for all subsequent references.)
It was originally just "user-supplied password", but then people popped up who
were using it slightly differently, for which "previously agreed-upon key"
fitted perfectly (for example a University in Germany somewhere is (or at least
was when it was written) using it with a PIC wafercard to do IDEA wrapping of
3DES or DES keys, I thought it was 3DES but thinking back it could have been
just DES, which would imply they're using it for Kerberos login... this makes a
good Uni project since you can fiddle with Kerberos or Sesame or whatever using
cheap, readily-available wafercards). Anyway, you can't do this with CMS-KEK,
and what they're doing is effectively password-based encryption, they're just
replacing the (Kerberos/Sesame) password with a wafercard, thus "previously
agreed-upon key".
4. Section 1.2.1: In the event that two password recipient info's are
present, how do I determine which is the one I am to use?
I'll answer that one in two parts:
1. What practical need is there for this? Every password-based encryption
program from crypt through to this morning's release of GPG, asks for a
password and then encrypts data with it. Although it is theoretically
possible to use multiple passwords, the fact that after 20-odd years of
password-based encryption utilities noone has seen any need to add this
indicates that it's not a major issue.
2. How would you add support for this? That is, how do you identify in the
PWRI which password is being used? The usual method - throw in an OCTET
STRING hole and let people dump whatever they want in it - isn't much use
because every implementor will choose something different, which means app A
won't be able to do anything useful with a PWRI from app B.
The reason there's no provision for handling more than one PWRI is a
combination of the two above points, there doesn't seem to be any real demand
for it, and without real-world requirements it's not possible to determine what
should be done. If a real-world demand does emerge in a years time (or
whenever), we can publish a v2 which addresses it, but trying to guess in
advance a solution to an unknown problem seems risky.
(Having said that, if you know of a good solution to this problem which doesn't
involve OCTET STRING holes or a SEQUENCE OF everything-imaginable OPTIONAL
(which is about the same thing) I'd love to hear it, if there really is a
clear, precise solution I'll be happy to add it).
6. Section 1.2.1: Paragraph keyDerivationAlgorithm: Please justfy why this is
optional.
See (3) above.
8. Section 2.2 & 2.3: You have Key Encryption algorithms and Symmetric Key
Encryption algorithms. I don't understand the difference between these two
groups as they both appear to be using symmetric keys, take a KEK and encrypt
a CEK. The only difference appears to be that the first are simple encrytion
algorithms and the second are complex ones.
They're both completely standard, off-the-shelf algorithms (eg DES-CBC, 3DES-
CBC, whatever). The only reason they're distinguished in the text is to allow
a description of the difference between a KEK and CEK, and because the KEK
algorithms (section 2.2) are tied to RFC 2898 while the CEK ones (section 2.3)
aren't. Putting them in the same section would make it rather confusing, or at
least less unambiguous.
10. Section 2.2: Why is Triple-DES/CBC a MUST algorithm. This appears to be
reasonable for content encryption but is not a good idea for key encryption.
To guarantee interoperability? You need at least one MUST, and 3DES seems to
be the most widely-accepted algorithm. Why would you not have a standard
algorithm as a MUST?
12. Section 2.3.3: unwrap Item 2: This does not appear to agree with the
algorithm in section 2.3.2. Should it not be "Set the IV to the decrypted
content, decrypt the first 8 bytes."?
No, it's correct as it stands (because encryption is just two passes of
straight encryption, the IV for the outer encrypted layer is the last block of
the inner encrypted layer). A number of people have created implementations
from that text without any problems.
13. Section 2.2: I am having a problem with what you are using for the
KeyEncryptionAlgorithm. I think that you need to use something other than the
standard content-encryption algorithm OIDs in this location due to the fact
that you are adding additional processing in the form of the wrapping
algorithm. I think that this issue alone is a killer for this document as it
is presently set out.
I'm sorry, but I don't understand this comment. One of the design goals of the
PWRI wrapping is that it uses completely standard algorithms and modes without
any need to invent new OIDs, encryption modes, mechanisms, or whatnot (you can
take any standard block cipher off the shelf with a standard OID and use it to
wrap the key). What you're saying is that you want a series of gratuitously
incompatible OIDs used in order to make implementation difficult? This would
lead to complete chaos, every time a new algorithm turns up you'd need to
either update the existing RFC or publish a new one just to define a new,
incompatible OID... it'd be a nightmare for implementors, you'd have to do a
new code release every month or so just to keep up with all the new OIDs you're
defininig, even though you're using completely standard algorithms. In
contrast the current approach fits right in with any existing algorithm/OID
(for example although it was published long before AES came out, it's
automatically compatible with AES without having to publish a new RFC just to
define an AES-wrap OID).
14. Section 2.2: It is still my belief that the key wrap algorithm presented
as part of RFC2460 should be the MUST key wrap algorithm (i.e. id-alg-
CMS3DESwrap). The CMS version will be implemented in software for CMS
compatilibity and in all likely hood will also be done in hardware as well if
KEK encryption ever becomes real common place. (For use with S/MIME symmetric
key mailing lists if nothing else.) While I don't object to your offering a
second key wrap algorithm I don't see a strong benifit for it over the already
existing version in CMS.
The PWRI algorithm is a one-size-fits-all mechanism which works with any
cipher, including ones not yet invented (an example being AES, at the time the
draft was first written). At the time of writing, the CMS KEK wrap only worked
for 3DES-in-3DES wrap and RC2-in-RC2 wrap, and nothing else. In contrast the
PWRI wrap works for any algorithm, so you only have to implement the mechanism
once and it'll work for every future algorithm. CMS KEK wrap has since been
extended via a string of extra RFCs to handle IDEA-in-IDEA wrap and CAST128-in-
CAST128 wrap, but it still doesn't handle anything else (for example it won't
handle the 3DES-in-IDEA or DES-in-IDEA wrap mentioned in (3) above, and it's
going to require yet another new RFC to handle AES).
While it would be possible to change the text to say something like "Use this
mechanism for everything but 3DES", all that'll do is lead to unnecessary
complexity and interop problems (not to mention thoughts of "What the..." from
anyone who's seeing that requirement for the first time :-).
In terms of hardware implementation, I haven't seen PKCS #11 vendors rushing to
implement CMS KEK. OTOH since the PWRI wrap works with any standard cipher
with no special processing required, it's automatically supported in hardware
already.
Overall, the current draft just plain works, I don't see why it needs to be
artificially restricted or use incompatible OIDs whose only purpose seems to be
to make implementation a pain.
Peter.
(I'm heading out for the RSA conference tomorrow so it may take me awhile to
reply to followups).