Draft-ietf-pkix-rfc2511bis-07

["Jim Schaad" <jimsch@xxxxxxxxxx>]

As advertized this draft is now under new editorship.  As the new editor
there are a number of issues that I fill still need to be resolved before
this draft can go to last call.  If there is no help forth coming then I
will be making arbitrary decions on these issue.

Additionally, if anyone has kept any of the final reports from the interop
trials for CMP, I would like to see the sections that relate to CRMF.

You can easily find the open issues and questions by searching for [[[ in
the document.

1.  Section 4.1 - I have a partial answer for this question dealing with non
DN style names that are authenticated, but are not actually either subject
names (DNs) or subject alt names (General Names).  The only real question at
this point is should this rational be documented.

2.  Section 4.2 - I am worried about the possiblity of somebody copying an
encrypted private key being sent to the CA/RA and then copying it into their
own certificate request.  They could then later request a key recovery from
the CA/RA and get back somebody elses private key.  This is the reason that
I am worried about how a POP proof is done here.  One potential answer is to
include the authenticated identity along with the private key in the
encrypted block.

3.  Section 4.2 - We MUST solve the question of what the contents of the
encrypted blob look like.  One potential answer is to obsolete thisMessage
and reaplace it with an EnvelopedData then all that needs to be covered is
the format of the encrypted key plus any POP info required.

4.  Section 4.3 - Does the DH section need to be expanded so that any key
agreement key pair can be used?  This can be done by adding a MAC alg and
value pair to the end of the POPOPrivKey choice (and potentially obsoleting
the dhMAC element).

5.  Section 4.4 - Two questions regarding guidence for the number of
iterations and the amount of salt to be used.  We need a cryptographer to
give us some guidelines for these details, or atleast need to set some
minimums.

6.  Section 6.1 & 6.2 - The content of these controls is not well defined
and a couple of questions regarding this are asked.  This may have been
addressed in the interop by adding some undocumented restrictions.

7.  Section 6.4 - There are a couple of archive questions here.  At this
point my inclination is to kill the entire section unless somebody wants to
make it acutally work.

8.  Section 6.8 - Ditto here.

9.  Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"   The parsing is
difficult (but not impossible) due to the overload of the % token.

Jim