Sean,
I have removed items that I considered to be completed
Jim
-----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 Turner, Sean P.
Sent: Thursday, August 21, 2008 6:10 PM
To: 'Jim Schaad'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt
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.
The major problem I have this text as it stands, is that the associated of
OID and ASN.1 type becomes different for when it appears in an originator
key vs when it appears in a public key (i.e. certificate). In theory, there
should actually not be a problem with having the full domain parameters
appear in the originator key field, although the reciver should check that
the parameters match those used for their key.
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 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?
We did allow for static-static DH, analogy says we might want to include it.
The question would be 1) would it be used (probably not) and 2) is there a
community that might thing you should validate the senders certificate prior
to decrypting a message (there were such communities, I think they have been
sufficiently discouraged from the practice).
I think a simple sentence -- Static-Static is not covered in this document,
the MQV method provides for better security, if you want to use ECSS - it is
analogous. (clean up the language).
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.
Issue open
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.
Text needs to be included as to what goes into the UKM field - specifically
it also needs to say where and how to use the ukm material in the (I assume)
ECC-CMS-SharedInfo structure to be used during key derivation.
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.
This is the key issue - Authenticated data DOES NOT provide data origination
assurance. All it says is that the data was not modified during "transit".
It does not say that the data is the same as the original sender.
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.
This is a problem of what AuthenticatedData provides vs what they think it
provides - see above comment.
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.
I don't see any identifier for sha1kdf (or what I would consider and
equivalent). There are ones for the entire scheme, but not for this piece
of the scheme.
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."
Result may be modified by discussion from top of mail message
Section 8.1 - for ecdas-with-*, is it considered acceptable to
have absent parameters?
See intro.
Open
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.
Combined with a clarification in the ASN.1 - this should be fine
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.
Fine
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.
This is part and parcel of the question of what AuthenticatedData does or
does not provide as a security service. Fix that concept and this goes
away.
Jim