Subject: Re: Draft-ietf-pkix-rfc2511bis-07

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Jan 2005 16:03:37 -0500

Folks,

Jim sent this message in mid-December and I have seen no response on 
the list, so far.  if nobody responds to Jim, Tim and I will 
interpret this as implicit authorization for Jim to proceed as he see 
fit on this topics.

Steve

>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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 24 Jan 2005 14:31:27 -0800

A new draft of this document has been submitted  All of the issues listed
below have been addressed or removed from the document.  Thoses people who
have CMP implementations need to look carefully at the updated document as I
am sure, not being a CMP guru, that I have changed how things work in some
cases.  This may not affect any current implemenations but I don't know
that.

Except for one issue, this document is ready for last call.  The remaining
issue is to address and pickup any further changes that CMP made to CRMF
without actually specifying it as such.  If anyone knows the rational and
syntax associated with id-regCtrl-altCertTemplate which is partially
specified in the RFC 2510 bis document but not documented please let me
know.  If no one speaks up I will put the syntax into CRMF document and
deprecate it.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Monday, December 13, 2004 1:31 PM
> To: IETF-PKIX
> Subject: Draft-ietf-pkix-rfc2511bis-07
> 
> 
> 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.
>