Peter,
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Peter
Gutmann
Sent: Thursday, April 05, 2001 1:36 PM
To: "IETF-An"@above.proper.com; iesg(_at_)ietf(_dot_)org;
jimsch(_at_)exmsft(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Last Call: Password-based Encryption for S/MIME
to Proposed
Standard
"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.
When you get an updated ASN module(s), please send them to me for futher
verification.
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".
I don't buy this argument anymore than the others, but I think we need to
just say we are going to forever disagree on this and skip it.
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.
Here is a use for this that I have at present. There exists a dirth of good
algorithms to use for the AuthenticatedData structure. At present the only
one that works is Static-Static DH (which is not a standard CMS algorithm).
THe problem is that with algorithms such as RSA and E-S DH there is no
method of authenticating the originator. I could use the password protected
key for doing AuthenticatedData. (Thus proving that it originated with
somebody who could correctly compute the password.) If I use it in this
senerio then I need some way for a server to determine which of the many
recipients originated this message and thus what password based key is
needed for validating of the AuthenticatedData structure.
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).
You might not like octet holes, I might not octet holes (possibly for
different reasons) but they provide the simpliest solition to this problem.
I would suggest that the same identification structure is used for this as
is currently used for KEKRecipientInfo. This is fairly general purpose.
6. Section 1.2.1: Paragraph keyDerivationAlgorithm: Please
justfy why this is
optional.
See (3) above.
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.
While I could by that argument, section 2.3 is talking about Symetric KEY
encryption algorithms not CONTENT encryption algorithms. Again what is the
difference between the two sections.
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).
What you want and what I want are not incompatable. If you defined an
id-alg-pwri-kek-encryption OID, gave it the structure of AlgorithmIdentifier
then you and I could both be happy. I would have a seperate OID to
distingish between a KEK and a CEK algorithm (ie-alg-pwri-kek-encryption vs
des-3DES-CBC) and you would not need to define a new OID for every algorithm
under the sun. The content encryption algorithm is the parameter to the key
wrap algorithm. I cannot accept that des-3DES-CBC is a different algorithm
based soley on the location in the ASN that the OID is placed.
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.
I have no method of verifying or disproving you statement at that it is
already in hardware, but I find it difficult to believe that id does not
require additional software above the hardware level to implement. That
being the case I can make the exact same argument for the CMS key wrap, that
a software module operating above a standard card implementing the standard
content encryption algorithm can be used to implement CMS. That in fact is
actually the first way that I impemented the CMS key wrap algorithm for test
purposes.
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).
jim