Subject: RE: CMC issues

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 Sep 2000 16:20:20 -0700

Avi,

-- see below for answers

Hi,

After reading CMC, I have got questions about the standard. Comments are
welcomed.

- ASN.1 module issues:
1. In the module, pendToken in pendInfo is defined to be an INTEGER,
while queryPending is defined as OCTET STRING in 5.13.

<JLS> This is an editing error.  The correct value in the module should
be OCTET STRING.  This is on the list of updates for the revised version
of the document.

2. The definition of bodyList in 5.1 is "SEQUENCE SIZE (1..MAX) OF
BodyPartID" while in the module it is defined as "SEQUENCE SIZE (1..MAX)
OF INTEGER"

<JLS> The text is correct for this item.  This has been appended to the
list of corrctions for the document.

3. The module imports AttributeCertificate and CertificateList. Both are
superfluous.

<JLS> Noted and will be removed in the next version.

- Use of SHA1 is hard coded in section 5.2. This does not leave the
standard open for other hash algorithms. Are there any plans to change
this?

<JLS> There has already been discussion about this issue on the mail
list.  THere are no plans to change this to allow for arbitrary hash
algorithms in this location.  If a new hash algorithm is required (i.e.
SHA1 becomes really broken) then a new control attribute would be
defined with a new fixed hash algorithm.  Allowing for different hash
algorithms here would also require the ability to discover this
information.

- If the shared secret method is used as proof of identity, it may be
exposed to off line dictionary attack (if supplied by the user). Usually
such an attack becomes harder by enforcing expensive computation for
each trial of a shared secret (computation of the hash 1000 times or
so). The CMC standard does not use this technique. It should at least
state that the shared secret must be randomly chosen (not a user
supplied password).
This attack is usually meaningless, as the shared secret is used only
once, however, if the initial enrollment request fails, the same secret
may be used in following requests (the standard does not require
replacement of it). As mentioned, a requirement of randomly chosen
secret may solve this.

<JLS>  Noted in the update documented comment list.

- It seems to me that the single round trip preference mentioned in
section 1 cannot come along with the industry practice of PKCS#10/PKCS#7
(mentioned in the same section). Proof of Identity may be supplied in
the full enrollment message (thus not using the PKCS#10 request) or
pending token must be returned (and having more then single round trip).

<JLS>  Using the current PKCS#10/PKCS#7 resonse, there is no simple way
to do any proof of identity in a single round trip.  Note that you
cannot even return a pending token here so there is no standard way to
do a multiple trip proof. The Proof-of-Identity is normally done in some
external non-standard way (either entering the proof on the web
enrollment page or an external e-mail message are normal ways today) or
not at all under current industry practice.

- According to the standard, the crm is signed (otherwise, there is no
meaning to the addition of the idPOPLinkWitness in the control section
of crm as described in 5.3.1). On the other side the full enrollment
request is signed, as described in section 4.2. In a case of renewal,
both signatures are required (the crm/pkcs10 are signed by the new key,
the whole message is signed by the old key). In the initial enrollment,
though, there is one redundant signature.

<JLS> The signature may or may not be redundant, however there are no
plans to remove the extra signature so that the structure and processing
of the message is consistant independent of the renewal/initial
enrollment processing.

Avi
--
Avi Gozlan
Encryption Group, R&D
Check Point Software Tech. Ltd
e-mail: [email-masked]