Jim,
Responses inline... Still working on 3 of the comments, which have been
moved to the bottom of the email.
All,
Jim's raised some concerns about the parameters fields and whether they
should be NULL or ABSENT. Additionally, this draft doesn't discuss hash
algorithm's parameter fields. We've got two options:
1) We leave the text as is and include some wording similar to what we say
about hash algorithm parameters (must support both NULL and absent
parameters and SHOULD generate absent). Note we need to add this text
regardless for the hash algorithm parameters because right now the ID says
nothing about them.
2) We poll implementers. We'd need to ask those that implemented:
- The originatorKey algorithm field MUST contain the id-ecPublicKey object
identifier when implementing ES ECDH with EnvelopedData but is the parameter
field populated with a NULL or is it ABSENT (i.e., the originatorKey is a
SEQUENCE of one component, the OID id-ecPublicKey).
- The signatureAlgorithm algorithm field MUST contain the ecdsa-with-*
object identifier when implementing ECDSA with SignedData but is the
parameter field populated with a NULL or is it ABSENT (i.e., the
signatureAlgorithm is a SEQUENCE of one component, the OID ecdsa-with-*).
In the past, we've solve this problem with the weasel wording for hash
algorithm parameters, but do we want to continue along this path? Is there a
widely deployed base of ES ECDH with EnvelopedData and did anybody do
something different than what RFC5008 says for ECDSA (i.e., absent
parameters when you use ecdsa-with-sha*)?
spt
-----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 Jim Schaad
Sent: Thursday, August 14, 2008 9:01 AM
To: Sean P. Turner
Cc: Ietf-Smime
Subject: Comments on draft-ietf-smime-3278bis-01.txt
Section 1.2
- bullet #1 - should be SHA-1 not SHA
- bullet #3 - change 'e' to 'a'
- be consistent on use of SHA-1 vs SHA1
I fixed these and found some other instances of SHA1 that should have been
SHA-1.
Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature
Fixed.
Snide remark - Can you use ECDH with CMS EnvelopedData w/o key
agreement?
No ;)
Section 3. - Is it permitted to do ECC static-static?
I believe it's permitted, but nobody asked for it so the RFC3278 authors
didn't include it. Since ES DH was the MUST I assume they went with ES
ECDH. Do you want to add it?
Section 3.1.1 - originator - The parameters SHOULD be ABSENT
not NULL. This is 1) consistent with what is done for DH and
2) means that you don't have one more additional encoding
binding for the originator field as oppose to the parameters
I think we should be doing what DH does and just have absent parameters.
Section 3.1.1 - please justify the requirement for DER
encoding of ECPoint.
I assume there isn't one and this was a cut-and-paste from the other field.
We'd just drop the DER part and the sentence would read as follows: "The
originatorKey publicKey field MUST contain the value of the ASN.1 type
ECPoint (see Section 8.2), which represents the sending agent's ephemeral EC
public key."
Section 3.1.1 - what about the ukm field?
The "but with the following restrictions:" before the bullets leads me to
believe there are no restrictions on the other 3 fields. I assume you're
asking for more text and we could add a blurb about ukm being absent. If we
add something about ukm we may just add something about the other fields and
change the intro sentence.
Section 3.2 - I don't understand why ES ECDH cannot be used
for AuthenticatedData. We can use the DH algorithm with it.
I can understand if you want to state that some ADDITIONAL
security properties exist from using 1-pass ECMQV.
I dug through the mail archives and found a thread between Francois
Rousseau, Dan Brown, and Simon Blake Wilson in March 2001. Before we add
it, I think we'd need to address the points raised. Here's how it went:
---
a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
agreement algorithm is supported with AuthenticatedData and not also the
ECDH key agreement algorithm. Although ECMQV is comparable to KEA, which can
also be used with AuthenticatedData, ECDH is the analog to the X9.42
Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
default algorithm with AuthenticatedData.
--> We looked at RFC 2630 which specifies the use of ephemeral-static
Diffie-Hellman within AuthenticatedData---but we didn't understand how this
mechanism provides authentication of the sender since the sender is not
certified. We didn't want to include the analogous technique based on these
concerns.
FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks
non-repudiation, and so in some instances is preferable to SignedData (For
example, the sending agent may not want the message to be authenticated when
forwarded). Using ephemeral-static ECDH within AuthenticatedData can achieve
this goal, but not necessarily ECMQV or static-static ECDH, which both
require a certified public key from the sender. As per Section 9 of RFC
2630, the goal of AuthenticatedData is to protect the integrity of the
content, but not to necessarily provide authentication of the sender. Note
also that RFC 2631 specifies both the ephemeral-static and the static-static
Diffie-Hellman modes.
--> Of course we could have included static-static ECDH, but this would
involve a fixed Diffie-Hellman "shared secret" (Z) between each pair of
correspondents, which seems undesirable.
FR> True, but I though this was the reason under Section 8.2 of your ID that
the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo
could optionally be supplied by the sending agent. By mandating the use of
the octet string ukm with the static-static ECDH, you would certainly avoid
this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the
partyAInfo MUST be used in Static-Static mode, but MAY appear in
Ephemeral-Static mode to avoid this same undesirable effect.
--> Make sense? Can anyone explain how ephemeral-static Diffie-Hellman
provides security with AuthenticatedData?
FR> I do not consider myself an expert with AuthenticatedData, but see my
two responses above.
---
Section 3.2.1 - for the bullet ukm - the last sentence makes
no sense--- Part of the problem is that the next paragraph is
not further indented.
This was typo. The paragraph after it should have been connected to the ukm
paragraph.
Section 3.2.1 - I would recommend for algorithm that absent
rather than NULL be used to simplify encoding/decoding steps
See intro.
Section 3.2.2 - what are the domain parameters the same as?
The check is that the recipient's domain parameters and the sender's domain
parameters are the same. Will add ", as the sender's domain parameters" to
the end of that sentence.
Section 3.2.3 - where does the additional ukm come from It
is/is not an ouptut of the key deployment/agreement algorithm?
The sentence was missing something from 3278. It should read: "The receiving
agent then retrieves the static and ephemeral EC public keys of the
originator, from the originator and ukm fields [as described in Section
3.2.1, and its static EC public key identified in the rid] field and checks
that the domain parameters are the same." Does this clear things up?
Section 3.2.3 - Are there requirements/recommendations for
validating a sender's certificate? Are there security
implications for not doing so?
I think we could add something about validating the certificate prior to
use. We've been discussing something similar for the S/MIME v3.2 IDs. I'll
add a reference to the security considerations and will grab the text from
MSGbis.
Section 5 - The first implementation requirement makes no
sense. Nor does it provide for interop. It makes more sense
to talk about SignedData conformance w/ the spec or Encryption
conformance w/ the spec.
I'm happy to recast these.
Section 5 - Why does ECDH care that P-256 curve be used with
SHA-256? What is this paragraph trying to state?
It doesn't care. I mistakenly added the ECDH, or ECMQV to the paragraph it
should only be about ECDSA.
Section 5 - What is sha1kdf - where is this referenced? Is
the what the previous paragraph is talking about?
These are defined later. I'll add a reference to the paragraph.
Section 5 - Are the KDF functions referenced here defined
using an object identifier in the X9.62 specifications? If so
it would be good to include those OIDs in the ASN.1 module.
(No private opinion)
Yes they use the OIDs from X9.62 and they are included in the modules.
Section 5 - Need to do some type of reference to where all of
the key wrap and content encryption algorithms are defined.
Agreed.
Section 8.1 - Has the following text:
When the object identifier id-ecPublicKey is used here with an
algorithm identifier, the associated parameters contain NULL.
I thought that there were ec domain parameters that were to
be encoded with the public key. Where else would this be
used? Is this from the OriginatorKey clause above that I
think is incorrect?
In this ID it's only used in the OriginatorKey clause. I'd change the
following "The following object identifier is used in this document to
indicate an elliptic curve public key:" to "The following object identifier
is used in this document to indicate an elliptic curve public key in the
OriginatorKey field:" and change "When the object identifier id-ecPublicKey
is used here with an algorithm identifier, the associated parameters contain
NULL" to "When the object identifier id-ecPublicKey is used here with an
algorithm identifier, the associated parameters contain are absent."
Section 8.1 - for ecdas-with-*, is it considered acceptable to
have absent parameters?
See intro.
Section 8.1 - The parameters for the encryption schemes -
KeyWrap ::= OBJECT IDENTIFIER or
KeyWrap ::= AlgorithmIdentifier
It is not clear from the text at the end of the last
paragraph in this section. Many people use OID and "algorithm
identifier" as the same thing.
How about: When the object identifiers are used here within an algorithm
identifier, the associated parameters field contains the KeyWrapAlgorithm
field, which indicates the key wrap algorithm and any assoicated parameters.
Section 8.2 What happens for keyInfo if the key wrap
algorithm actually has parameters?
I think this is wrong. It ought to allow for parameters and absent
parameters (i.e., for aes*-wrap). I propose:
Old: keyInfo contains the object identifier of the key-encryption algorithm
(used to wrap the CEK) and NULL parameters.
New: keyInfo contains the object identifier of the key-encryption algorithm
(used to wrap the CEK) and associated parameters. In this specification,
3DES wrap has NULL parameters while the AES wraps have absent parameters.
Section 8.2 - suppPubInfo - Since AES128 is the required key
wrap, use that for the example not 3DES
Fixed.
Still working on these:
Section 3.2.2 - Please elaborate on the re-used statement in
the last paragraph. Can be re-used for what? for how long?
why can't it be re-used for encrypted data?
Section 3.2.2 - if you re-use the ephemeral - what does/does
not need to be changed? The additional ukm?
I'm leaning towards deleting this sentnece and the similar sentences in
4.1.2 and 4.2.2.
Section 4.1.2 - Note: There is a legal attack where by the
recipient modifies the content and goes to court with the
modified content. Unless you bind the output MAC in with the
MAC key, you cannot prevent this type of attack.
Not sure what to do with this one.