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
Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature
Snide remark - Can you use ECDH with CMS EnvelopedData w/o key agreement?
Section 3. - Is it permitted to do ECC static-static?
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
Section 3.1.1 - please justify the requirement for DER encoding of ECPoint.
Section 3.1.1 - what about the ukm field?
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.
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.
Section 3.2.1 - I would recommend for algorithm that absent rather than NULL
be used to simplify encoding/decoding steps
Section 3.2.2 - what are the domain parameters the same as?
Section 3.2.2 - where does the additional ukm come from It is/is not an
ouptut of the key deployment/agreement algorithm?
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?
Section 3.2.3 - Are there requirements/recommendations for validating a
sender's certificate? Are there security implications for not doing so?
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.
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.
Section 5 - Why does ECDH care that P-256 curve be used with SHA-256? What
is this paragraph trying to state?
Section 5 - What is sha1kdf - where is this referenced? Is the what the
previous paragraph is talking about?
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)
Section 5 - Need to do some type of reference to where all of the key wrap
and content encryption algorithms are defined.
Section 8.2 - 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?
Section 8.1 - for ecdas-with-*, is it considered acceptable to have absent
parameters?
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.
Section 8.2 What happens for keyInfo if the key wrap algorithm actually has
parameters?
Section 8.2 - suppPubInfo - Since AES128 is the required key wrap, use that
for the example not 3DES