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

From: Sharon Boeyen <[email-masked]>
Date: Wed, 9 Feb 2005 10:57:45 -0500

Jim, sorry for the delay in responding. I have 2 comments:

1) The new document completely changes the meaning of an Object Identifer
(changing the name as well as the syntax). In the original RFC (see page
11), the OID was defined as follows:
 
id-regInfo-asciiPairs  OBJECT IDENTIFIER  ::= {id-regInfo 1} --with syntax
OCTET STRING
(however in Appendix B they call this id-regInfo-utf8Pairs with a syntax of
OCTET STRING, so there was some confusion even back then)
 
In the new RFC it changes to:
 
id-regInfo-utf8Pairs  OBJECT IDENTIFIER  ::= {id-regInfo 1} --with syntax
UTF8String (see section 7.1.
 
OIDs cannot be redefined like this.  I suggest you leave the old OID as is
and define a new one for UTF8 String. 

2) The use of the EncryptedValue structure has been deprecated. This is one
of the two choices for conveying an encrypted key in the archive options
control that would appear in the controls element of the cert request. The
other choice is envelopedData. EncryptedValue is in use in existing products
and therefore should not be deprecated.

Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Friday, January 07, 2005 4:04 PM
To: [email-masked]
Cc: IETF-PKIX
Subject: Re: Draft-ietf-pkix-rfc2511bis-07

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: Fri, 11 Feb 2005 01:36:01 -0800

Sharon,
 
My problem on the timing of getting remarks in -- since we haven't started
last call and I have some comments that required an update to the document
anyway.
 
1.  I will define a new OID for this.  My assumption is that the old one
should be obsoleted as this change was made by the original authors of the
draft, I assume in response to interop changes and replaced with the new
UTF8String regInfo item.
 
2.  I would disagree with the statement that since EncryptedValue is used in
existing products it should not be deprecated, however I am willing to be
convinced that we need to keep it.  I deprecated the use of the structure
for the following reasons:
 
a) There is no identification in the structure as to what public key was
used to encrypt the symmetric key.  This means that servers must guess as to
which private key is used in the decryption operation (or try multiple
keys).
 
b) There is no method of changing the structure to be encrypted, but for the
reasons covered at the start of section 4.2.1 I did just that in this
document.  The document does not allow for the encryption of just the
PrivateKeyInfo structure anymore.
 
c) The content within the EncryptedValue structure was context sensitive,
but not tagged as to actual content.  It might be either a certificate or a
private key.
 
d) It is not possible to do encryption with key agreement keys given the
lack of location to place the sender public key or to identify where it came
from.
 
e) It is currently necessary to implement both EncryptedValue and
EnvelopedData to implement the spec.  This would tend to violate the edict
from the chairs that we should avoid, when possible, having two different
ways of accomplishing the same thing.
 
f) The structure valueHint is under defined if it is to be meaningfully
used.
 
The only marginal advantage that I see is that EncryptedValue uses bit
strings rather than octet strings to wrap the data, but as they are almost
always in 8 byte quantities with all of the common algorithms in use this
seems to be of dubious benefit.
 
I am not sure what indendedAlg was actually suppose to be used for.  This
seems to be duplicate information with the algorithm identifier associated
with the public key in the certificate request, although I suppose the first
could be rsa-oaep and the latter rsa-enc.
 
jim

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: Wednesday, February 09, 2005 7:58 AM
To: 'Stephen Kent'; [email-masked]
Cc: IETF-PKIX
Subject: RE: Draft-ietf-pkix-rfc2511bis-07

  

Cheers, 
Sharon 

-----Original Message----- 

Folks, 

Steve 

is