Russ Housley <housley(_at_)spyrus(_dot_)com> writes:
For consistency, please use the spelling that CMS inherited from PKCS#7 v1.5:
key-encryption key
content-encryption key
All right.
I expected section 2.1.1 to include: g^q (mod p) == 1.
I'm not sure that this is sufficient. However, it follows from
the following criterion, (which I just added) which is listed
in FIPS-186
h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1
(g has order q mod p)
In section 2.1.2, you say: "algorithm is the ASN.1 algorithm OID of the
symmetric algorithm with which this KEK will be used." I think it would be
more clear to say that is is the OBJECT IDENTIFIER protion of the symmetric
algorithm identifier; no parameters associated with the symmetric algorithm
identifier are used.
How about:
algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which
this KEK will be used. Note that this is NOT an AlgorithmIdentifier,
but simply the OBJECT IDENTIFIER. No paramters are used.
Later in section 2.1.2, you say: "Note that pubInfo is required in
Static-Static mode, but MAY appear in Ephemeral-Static mode." I would
prefer to see the first half of the sentence reworded to include "MUST."
Note that pubInfo MUST be used in Static-Static mode,
but MAY appear in Ephemeral-Static mode.
In section 2.1.5, you need to upcase "MAY NOT."
Hmm... This makes me a little queasy. This is a descriptive, not
prescriptive statement...
In section 2.2, you say: " When symmetric ciphers stronger than DES are to
be used, a larer m may be advisable." This screams for a paragraph in
Security Consderations.
Please add a section parallel to section 2.3 that describes Static-Static
Mode. The term is used in the body of the document, so it probably needs a
description.
All right.
Please add a paragraph is the security Considerations section regarding the
size of the private key, x, and the size of the generated symmetric keys.
In general, the private key need to be twices the size of the resulting
symmetric keys. Note: KEA uses a 160 bit private key to generate 80 bit
SKIPJACK keys.
I agree that you are correct here, but this puts us in very unpleasant
waters:
The FIPS-186 key/parameter generation algorithm only describes how
to generate for m==160. X9.42 DOES describe how to generate for
<arbitrary m. However, X9.42 isn't publicly available, so we shouldn't
make a normative reference to it, but rather should describe the
procedure inline.
I suppose I could try to write something like:
Follow FIPS-186, except substituting 'm' for 160, but I'm pretty
nervous about that.
I'd like to get the sense of the group here.
-Ekr
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]