Subject: New CMC Draft available

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 8 Mar 1999 10:12:48 -0800

A new draft of CMC (what will become draft -03) is now available on-line.
This draft should appear on the various IETF servers shortly after the
upcoming meeting in Minneapolis.  We apologize for missing the
internet-draft cutoff date to get the draft published on IETF servers before
the meeting; in the meantime the draft is available in various format from
Brian LaMacchia's personal website at:

	http://www.farcaster.com/cmc/

The differences between the -02 and -03 drafts may be summarized as follows:
1) New Section 5.3, Linking Identity and POP information, to address the
potential theft/replay attack involving cert requests with NULL subject DNs
that Carlisle Adams pointed out.
2) Revised Section 5.7, POP for Encryption-only Keys, to address a similar
attack involving the example state-reduction technique.
3) Numerous editorial changes that were made in response to comments posted
to the list and/or delivered to the authors privately.

In the new Section 5.3, CMC now specifies a mechanism for linking the POP
information contained within each signed PKCS#10/CRMF message to the
identity information derived from the one-time token carried in the Full PKI
Request message.   The basic idea is to force the client to sign another
value cryptographically-derived from the shared secret into each and every
cert request contained within the Full PKI Request message.  More
specifically, the client publishes a random string in the Full PKI Request
header and then signs HMAC(shared secret, random string) into every cert
request.  In order to successfully carry out a theft/replay attack the
attacker would have to either know the shared secret or be able to generate
an HMAC collision.  (That is, if Bob steals a cert request from Alice, Bob
needs to find random_bob such that HMAC(shared secret_bob, random_bob) ==
the HMAC signed into the request.)

In the revised Section 5.7, we now hash the entire cert request instead of
hashing just the public key.  With the changes in 5.3 the cert request can't
be copied & used in another enrollment transaction.  However, by hashing in
the cert request we now require the client to return, on the second request,
the exact same PKCS#10/CRMF that he submitted originally.

Finally, on a procedural note, as of this draft I am taking over Barb Fox's
authorship position on CMC.

Jim