Subject: Comments on draft-ietf-pkix-sim-01

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 Nov 2003 19:38:56 +0100

I have always wondered about the goal of this document, since it is not 
crystal clear.

It seems that the goal is to allow a relying party to determine whether the 
subject of a particular certificate is the right person. This is currently 
difficult since there might be not enough information in the DN and 
disclosing more information in the DN would be against privacy.

Is it the basic motivation of this document ?

There is however an additional property of the "solution" (or is it a real 
requirement ?) :

    Furthermore, the subject can prove to the
    relying party that they are associated with a valid identification
    with out disclosing the identifier.

This requirement is not crystal clear. What is a valid identification ?
If it is a bank account number, is it a number with the right Luhn code 
computation in it and an existing bank identification number in it ?

Now the solution is rather complicated and it can be seen that an encryption 
channel is required. A high level view of the goal(s?) and the advantages of 
the solution is currently missing.

There might be a much simpler solution to solve the basic problem that is 
trying to be solved:

Include in the certificate a hash of "personal information" that can be 
revealed by the certifcate holder and thus any relying party to which this 
information is disclosed can verify it (usually once).

Denis

---

From: "Jongwook, Park" <[email-masked]>
Date: Fri, 7 Nov 2003 21:27:31 +0900

Denis:

I think you catch on the basic idea of this draft exactly. Generally, the DN
in the 'subject' or 'subjectAltName' extension must be unique for each
person. However, it is very difficult to identify that the subject of
certificates is in fact the right person issued by CA since many people
often have the same name. 

To solve the above problem, this document don't use the DN for including the
non-public data since the information in DN can't meet the requirement and
is likely to disclosing private data. Alternatively, this draft proposes the
PII(Privacy Identification Information) structure which is encrypted form of
any sensitive identifier and finally put into the 'subjectAltName'
'GeneralizedName' 'otherName' field. This way can be regarded as a
complementary method for the shortcoming of the DN. 

PII structure is defined as follows :

PII = H(R || SIItype || H (R || P || SII))
where R : 160-bit random number, P : Password, SII : Sensitive
Identification Identifier and H : Cryptographically secure hash function
such as SHA-1, not MD2 or MD5.

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details.
As a first example, let us suppose the RP already know the SII of the
certificate holder via out of band. In this case, certificate holder should
send R, P and his certificate containing the PII. Then RP can figure out if
the PII in cert and another PII' calculated itself from R, P and SII already
obtained are identical or not. It is definitely clear that R and P should be
transmitted in a secure channel. 

For another example, suppose such context where some people don't really
want to divulge any hint of his sensitive identifier to RPs. Maybe it's a
kind of same case why we need the Proof of Possession (POP) in RFC2510.
Anyway, please note the PII is the double-hashed structure. That is to say,
the subject send only intermediate value, H(R || P || SII) to RP without
disclosing the SII. Then relying party can calculates H ( R || SIItype ||
intermediate value) and verifies whether this value is equal to the PII in
the certificate. Finally, RP can guess the certificate holder has right
certificate even if it doesn't know the value of SII itself. 

Alike the above procedures, the certificate holder should be send R, P, SII
and PII in a cert if the RP doesn't have any information about the
certificate holder. The rest of the verification is similar to the first two
cases. 

In conclusion, PII structure is cryptographically secure and efficient
scheme to protect personal information although it seems to be complicated
at a glance.

Best regards,
Park.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 7 Nov 2003 09:22:31 -0500

I agree with Park.  I found the document easy to read and follow.  I did not
find the protocol difficult.  It is also easy to see why there are two
stages of hashing.

The document can use some editing.  I did not note my editorial comments as
I was reading it.

I have only one substantive comment.  The document should address how
SIIType is communicated between the subject and the relying party.  I did
not find a mention of it.  May be I simply missed it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jongwook, Park
Sent: Friday, November 07, 2003 7:28 AM
To: 'Denis Pinkas'
Cc: [email-masked]; [email-masked]; Russ Housley; [email-masked]; Bill
Burr; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

Denis:

PII structure can be applied to the various situations in different ways in
accordance with the RP's security environments. Please refer to the section
5. Example Usage of PII of the draft for details. As a first example, let us
suppose the RP already know the SII of the certificate holder via out of
band. In this case, certificate holder should send R, P and his certificate
containing the PII. Then RP can figure out if the PII in cert and another
PII' calculated itself from R, P and SII already obtained are identical or
not. It is definitely clear that R and P should be transmitted in a secure
channel. 

Best regards,
Park.  

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

This requirement is not crystal clear. What is a valid identification ? If
it is a bank account number, is it a number with the right Luhn code
computation in it and an existing bank identification number in it ?

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 14 Nov 2003 10:31:47 +0100

Park,

Thank you for the explanations.

> transmitted in a secure channel. 

R is only needed, if the SII is too short, to optionnally hide the value of 
SII by preventing guessing attacks. If the SII value is long enough, then R 
is no more needed. So R should be optional.

In the ASN.1 description of the SIM :

  - 1°  the SIItype field is missing,
  - 2°  R should be OPTIONAL,
  - 3°  an indicator should added to say whether or not
        a password is required in the computation.

Note: if neither R and P are present and the SII is long enough, then we 
have the proposal I made in my previous e-mail:

Include in the certificate a hash of "personal information" that can be
revealed by the certificate holder and thus any relying party to which this
information is disclosed can verify it (usually once).

Denis

---

From: Vadim Fedukovich <[email-masked]>
Date: Sat, 15 Nov 2003 16:18:27 +0200

Dear Park,

yes PII suggested makes it unpractical trying to learn protected data
unless the password was disclosured to some party to let it verify
the binding. Once sent out, no control is here anymore and the password
could be sent further to other parties, to prove the binding.
Maybe one can use proofs of knowledge instead to stay in control
of sensitive information. That is, run proofs yourself
using non-X.509 tools and only include proofs-bootstrapping data
in certificates issued.

For example, to prove the number SII is bound to ID certified
one can choose a new fresh random nonce t and send (C, T) to the verifier:
     C = Hash(ID, p, g, (g^{t * SII} mod p))
     T = g^t mod p
where ID is name/locality/country from the certificate and g is
a generator over prime filed (mod p).

The verifier could test that (T^{SII} mod p) corresponds to C, ID, g, p
Given strong hash function and hard discrete logarithm problem such a prof
should be convincing for the verifier.

Yes, the basic prof above could be running by anyone for any ID
so one should include some (private exponent) number in the verification
equation and include corresponding public value (g^{private} mod p)
in the certificate issued.

One can elaborate providing the whole idea looks acceptable

regards,
Vadim

-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 16 Nov 2003 08:15:11 -0500

Denis:

"R" also helps with adversary finding out some SII when an off-line,
exhaustive dictionary attack is conducted.  With "R" in there, the adversary
has to attack each certificate.  Without "R", the adversary can try random
SII and if it matches a certificate, he has accomplished something.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, November 14, 2003 4:32 AM
To: Jongwook, Park
Cc: [email-masked]; [email-masked]; Russ Housley; [email-masked]; Bill
Burr; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01

Park,

> Denis:
> 
> I think you catch on the basic idea of this draft exactly. Generally,
> the DN in the 'subject' or 'subjectAltName' extension must be unique 
> for each person. However, it is very difficult to identify that the 
> subject of certificates is in fact the right person issued by CA since 
> many people often have the same name.
> 
> To solve the above problem, this document don't use the DN for
> including the non-public data since the information in DN can't meet 
> the requirement and is likely to disclosing private data. 
> Alternatively, this draft proposes the PII(Privacy Identification 
> Information) structure which is encrypted form of any sensitive 
> identifier and finally put into the 'subjectAltName' 'GeneralizedName' 
> 'otherName' field. This way can be regarded as a complementary method 
> for the shortcoming of the DN.
> 
> Identification Identifier and H : Cryptographically secure hash 
> function such as SHA-1, not MD2 or MD5.
> 
> PII structure can be applied to the various situations in different
> ways in accordance with the RP's security environments. Please refer 
> to the section 5. Example Usage of PII of the draft for details. As a 
> first example, let us suppose the RP already know the SII of the 
> certificate holder via out of band. In this case, certificate holder 
> should send R, P and his certificate containing the PII. Then RP can 
> figure out if the PII in cert and another PII' calculated itself from 
> R, P and SII already obtained are identical or not. It is definitely 
> clear that R and P should be transmitted in a secure channel.

Denis

> For another example, suppose such context where some people don't
> really want to divulge any hint of his sensitive identifier to RPs. 
> Maybe it's a kind of same case why we need the Proof of Possession 
> (POP) in RFC2510. Anyway, please note the PII is the double-hashed 
> structure. That is to say, the subject send only intermediate value, 
> H(R || P || SII) to RP without disclosing the SII. Then relying party 
> can calculates H ( R || SIItype || intermediate value) and verifies 
> whether this value is equal to the PII in the certificate. Finally, RP 
> can guess the certificate holder has right certificate even if it 
> doesn't know the value of SII itself.
> 
> Alike the above procedures, the certificate holder should be send R,
> P, SII and PII in a cert if the RP doesn't have any information about 
> the certificate holder. The rest of the verification is similar to the 
> first two cases.
> 
> scheme to protect personal information although it seems to be 
> complicated at a glance.
> 
> Best regards,
> Park.
> 
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> I have always wondered about the goal of this document, since it is
> not crystal clear.
> 
> It seems that the goal is to allow a relying party to determine
> whether the subject of a particular certificate is the right person. 
> This is currently difficult since there might be not enough 
> information in the DN and disclosing more information in the DN would 
> be against privacy.
> 
> There is however an additional property of the "solution" (or is it a
> real requirement ?) :
> 
> This requirement is not crystal clear. What is a valid identification
> ? If it is a bank account number, is it a number with the right Luhn 
> code computation in it and an existing bank identification number in 
> it ?
> 
> Now the solution is rather complicated and it can be seen that an
> encryption channel is required. A high level view of the goal(s?) and 
> the advantages of the solution is currently missing.
> 
> There might be a much simpler solution to solve the basic problem that
> is trying to be solved:
> 
> Include in the certificate a hash of "personal information" that can
> be revealed by the certifcate holder and thus any relying party to 
> which this information is disclosed can verify it (usually once).
> 
> 
> Denis
> 
> 
> 
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 16 Nov 2003 10:36:48 -0500

Vadim:

This seems secure.  However, if the various certificate issuers used the
same p, q, and g for creating the public value of a given SII, it may offer
an opportunity to link different pseudo identities via the attribute to the
same person.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vadim Fedukovich
Sent: Saturday, November 15, 2003 9:18 AM
To: Jongwook, Park
Cc: 'Denis Pinkas'; [email-masked]; [email-masked]; Russ Housley;
[email-masked]; Bill Burr; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01

Dear Park,

yes PII suggested makes it unpractical trying to learn protected data unless
the password was disclosured to some party to let it verify the binding.
Once sent out, no control is here anymore and the password could be sent
further to other parties, to prove the binding. Maybe one can use proofs of
knowledge instead to stay in control of sensitive information. That is, run
proofs yourself using non-X.509 tools and only include proofs-bootstrapping
data in certificates issued.

For example, to prove the number SII is bound to ID certified one can choose
a new fresh random nonce t and send (C, T) to the verifier:
     C = Hash(ID, p, g, (g^{t * SII} mod p))
     T = g^t mod p
where ID is name/locality/country from the certificate and g is a generator
over prime filed (mod p).

Yes, the basic prof above could be running by anyone for any ID so one
should include some (private exponent) number in the verification equation
and include corresponding public value (g^{private} mod p) in the
certificate issued.

regards,
Vadim

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Nov 2003 09:13:22 +0100

Santosh,

> SII and if it matches a certificate, he has accomplished something.

As I said, this depends of the length of the SII, i.e. the difficulty to 
guess it. So R should be optional.

Denis