Subject: Comments on draft-ietf-pkix-sim-02.txt

From: "Jim Schaad" <[email-masked]>
Date: Tue, 24 Feb 2004 13:51:05 -0800

I have the following comments in regards to this draft.

1.  Previously noted the problem with verifiers getting the value of R.

2.  Section 2.1:  Alice discloses her SII to the RA, not here PEPSI.  This
is computed by the RA.

3.  Eve is trying to determine an SII not Alice's SSN.

4.  How do you reconcile the requirement "The CA does not learn Alice's SII
or here password" with the encrypted pepsi concept presented further on in
the document.

5.  Section 2.3:  You are overloading the symbol SII.  In one case it
represents the general concept of Alice's sensitive information (section
2.1), in another ir represents SIITYPE || SII.  This is confusing.  I
suggest removing all 'Xa' items from section 2.3.

6.  Section 2.3:  What is a SIMa - this is not previously defined (is now
PEPSI)

7.  Section 3:  I worry about the length of R.  Looking at it and seeing
that it is 160-bits long, I think that somebody is going to say - oh - SHA-1
hash of SIIType || SII (maybe with the password) is a good way of getting
the random number.   On what bases is 160-bits chosen?  (Note that the
attack work load is |P| and is independent of R).

8.  Are you going to register any IANA SII Types with this document for user
convenience?  I.E.  For a USA SSN do I include the hyphens?

9.  "The SII is composed of an alphanumeric string and has a type assigned
as well." --> "The SII is composed of an alphanumeric string.  The SSItype
is an OID which defines the format and scope of the SSI value."

10.  Append to section 3.3.  Selection rule are to include requirements on
minimum lengths of the password, manditory sets of characters to be included
in the password (i.e atleast one upper case, one lower case and one numeric
charcter.)

11.  Section 3.5 - one of SHA-1 or SHA-256 needs to be a MUST (or both)

12.  Section 3.6 - If I am running a CA and I require the CA to validate the
SII, I would also require the CA to validate the PEPSI value.  Otherwise
there is no way for the CA to know that the passed along SII value and the
PEPSI value match in any way.

13.  Section 3.6 - The method of encryption needs to be specified.  Am I to
use CMS here or to actually encrypted the value with the public key of the
CA.  How do I do this if what I am using is DH?  What algorithms (bulk and
public) am I required to support to implement this feature?

14.  Section 3.7 - How do I place a PEPSI into a PKCS#10 request.  If I put
it into the attributes field as an RA, I break the signature cehck on the
certificationRequestInfo field.  This does not work.

15.  Section 3.7 - for CRMF - this item needs to be place d in the regInfo
not the controls field. (as implied by regToken being in the regCtrl arc.)

16.  Section 4.2 - Please give an exmample of where I would use the OID
id-on-sim-pepsi.  This structure is only used for hashing purposes and
therefore does not seem to need to be identified.

17.  Section 4.2 - Is this the field that I am suppose to use to pass the
data from me to the RA?  If so then authorityRandom should be optional.

18.  Section 4.2 - How to I protect the data that I am passing to the RA?

19.  Section 5.  - You have a comment about a relying parting getting an SII
from the RA -- bad news all the way around.

20.  Section 5 - text for example 3 does not may any sense to me.

21.  Section 5 - The following text "  A cryptographically secure hash
function such as SHA-1 and SHA-256 is
   recommended to use for preventing the birthday problem. " does not make
sense to me.  This does not in and of itself prevent the birthday problem  

Jim Schaad

---

From: "Jongwook Park" <[email-masked]>
Date: Wed, 25 Feb 2004 22:26:03 +0900

Jim,

I appreciate for your thorough reviewing of the SIM draft.

To better share my idea with you, I categorized your comments into the
following way :

(1) Major issues :   #1, #16, #19
 Actually, there was a little confusion when I submitted the new draft. The
final draft I submitted was different from the draft posted currently. I
already recognized the problem(#1, #17) you pointed out.  In addition, I
also noticed that the OID for id-on-sim-pepsi is not necessary(#16). Please
refer the attached draft.

For your convenience, I briefly introduce the *NEW* solution.

New solution:   Let SIM = R || PEPSI where
                         PEPSI = H(H( P || R || SIItype || SII))

Then, 

 - In section 2.3, Bob can get R from the SIM in the cert, SIMa. After that,
he can compute PEPSI = H(H(Pa || R || SIItype || SIIa)) and compare it to
the value in SIMa, thereby verifying SIIa.

- In section 2.3, Alice can now send an intermediate value H(Pa || R ||
SIItype || SII) since the R is published in the certificate as a form of SIM
= R || PEPSI.

- Basically, the value of R is salt which it can be published in a
certificate. So Alice doesn't have to remember it. The only value which
Alice should remember is the Password, Pa itself. 

I think that above solution will satisfy the requirements defined in Section
2. and resolve the issues you pointed out.

(2) Minor editorials :  #2, #3, #5, #6, #8, #9, #10, #11, #15, and #21
I have no problem with accepting your suggestions. especially, I'll add an
unambigouous reference for #10.
In response to above comments, next draft will consider theses issues to be
addressed.

(3) Clarifying the comments needed: #12 and #14
Sorry, but  you lost me here. Please, give me more detail about those
questions.

(4) Further consideration needed: #4 and #10
It obviously seems that there is contradictionary statments between the
security requirement and the usage of encrypted PEPSI(#4). Also, it is
unclear how Alice can protect the data such as SII and P which passed to the
RA(#18). The solution resovled these issues will be delivered, I believe.   

Finally, three comments, #7, #13, and #20 are remained. :-)
In #7, I chose the 160-bit random number since it is easier way to get it by
using the hash algorithm. 
Next, the following text "Encrypting PEPSI with the public key of CA MUST be
derived from PEPSI along with SII ...." in Section 3.6 will be answering for
the #13.
As for the last comment, I'm sure it will be explained if the intermediate
value of PEPSI, H(H( P || R || SIItype || SII)) replaced by H( P || R ||
SIItype || SII).

Once again, thanks for your reviewing.

Best regards,
Park

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jim Schaad
Sent: Wednesday, February 25, 2004 6:51 AM
To: [email-masked]; IETF-PKIX
Subject: Comments on draft-ietf-pkix-sim-02.txt

Jim Schaad

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 25 Feb 2004 16:48:49 -0800

Park,

Thanks for looking at the issues I raised.  I will attempt to further
explain items #12 and #14 here so that you can see what I am talking about.

#12 -- The only reason that I can see for an RA to pass the SII on to the CA
is that the CA wishes to validate that the SII value is correct.  This means
that the CA needs to validate two different pieces of information:  1) the
SII does indeed correspond to a value that Alice is permitted to use and 2)
that the SII is acutally correctly encoded in the PEPSI value and the RA is
not lying to the CA about the SII value that is embeded in the SII.  While
the current syntax allows for test #1 to occur, test #2 cannot occur without
the knowledge of SIIType and Pa.

#14 -- If you look at the syntax for a PKCS#10 item, the EE creates a
signature over the entire request body to be sent up to the CA.  This is
done for reasons of POP.  However if the RA modifies the request body by
placing the new control into the PKCS#10 request, then the POP would break
on the PKCS#10 request.  Thus to work the EE would need to have the PEPSI
and insert the value by itself.

jim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jongwook Park
Sent: Wednesday, February 25, 2004 5:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-02.txt

Jim,

Then, 

(2) Minor editorials :  #2, #3, #5, #6, #8, #9, #10, #11, #15, and #21 I
have no problem with accepting your suggestions. especially, I'll add an
unambigouous reference for #10.
In response to above comments, next draft will consider theses issues to be
addressed.

(3) Clarifying the comments needed: #12 and #14 Sorry, but  you lost me
here. Please, give me more detail about those questions.

(4) Further consideration needed: #4 and #10 It obviously seems that there
is contradictionary statments between the security requirement and the usage
of encrypted PEPSI(#4). Also, it is unclear how Alice can protect the data
such as SII and P which passed to the
RA(#18). The solution resovled these issues will be delivered, I believe.   

Finally, three comments, #7, #13, and #20 are remained. :-) In #7, I chose
the 160-bit random number since it is easier way to get it by using the hash
algorithm. 
Next, the following text "Encrypting PEPSI with the public key of CA MUST be
derived from PEPSI along with SII ...." in Section 3.6 will be answering for
the #13.
As for the last comment, I'm sure it will be explained if the intermediate
value of PEPSI, H(H( P || R || SIItype || SII)) replaced by H( P || R ||
SIItype || SII).

Best regards,
Park

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

Jim Schaad