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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Denis Pinkas
Sent: Friday, November 07, 2003 3:39 AM
To: pkix
Subject: Comments on draft-ietf-pkix-sim-01
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