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

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

Tim and Park:

Some more comments:

2.  It is not clear from the document whether SIM is a new extension or it
goes in the subject alternative name field.

3.  Was there some consideration given to add PII for multiple SIIType in
the certificate.  Seems that it could be useful to bind SSN, driver's
license, and say credit card number all in one certificate so that different
relying parties can use the same certificate.  In that case, SIM syntax
needs to change and needs to explicitly include SIIType.  If that were done,
there does not appear to be a security problem with it.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 9:23 AM
To: [email-masked]'
Subject: RE: Comments on draft-ietf-pkix-sim-01

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:

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

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: Stephen Kent <[email-masked]>
Date: Fri, 7 Nov 2003 10:13:33 -0500

>there does not appear to be a security problem with it.

I would argue against binding multiple types of identifiers in the 
same cert.  I refer you to the NAS Committee report "Who Goes There? 
Authentication Through the Lens of Privacy" for a lengthy discussion 
of why such bundling is not a good idea from both a security and 
privacy perspective.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 8 Nov 2003 10:12:27 -0500

Steve:

I agree that putting multiple sensitive attributes in one location is
inviting trouble.

However, when you look at the details of the protocol, the CA and the
certificate are not the points of attack since they do not contain sensitive
information.  The likely points of attack are the hash, password, subject
workstation, relying party workstation, and RA workstation.

Whether you hold single attribute in a certificate or hold multiple
attributes in various certificates (so that you can present the required
attribute to the relying party), the relying party should only see the
attribute(s) it must.  Thus, putting multiple attributes in the certificate
is not going to change the relying party workstation vulnerability.

Similarly, the subject is likely to use the same workstation for carrying
out the transactions and hence subject workstation threat will not change.

The hash algorithm and passwords could have the same diversity whether the
attributes are vetted in one certificate or multiple certificates.

This leaves the RA workstation threat.  If the RA workstation is used to
enter and say hash the attributes, its security compromise could lead to
compromising a set of attributes rather than a single attributes.  However,
using the current I-D, an RA could vet multiple attributes for the same
subject using a single CA or multiple CAs, resulting in the same
vulnerability.

Thus, as a minimum, the RFC Authors should be encouraged to beef up the
security section to discuss the issue of RA protecting the attributes.

I think the best approach may be to add appropriate caution in the Security
Considerations section, discourage the vetting of multiple attributes by an
RA if the RA system has to process those attributes, but permit the
certificate syntax to carry multiple attributes in case there is a need for
it.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

At 9:49 -0500 11/7/03, Santosh Chokhani wrote:
>Tim and Park:
>
>Some more comments:
>
>2.  It is not clear from the document whether SIM is a new extension or
>it goes in the subject alternative name field.
>
>3.  Was there some consideration given to add PII for multiple SIIType
>in the certificate.  Seems that it could be useful to bind SSN, 
>driver's license, and say credit card number all in one certificate so 
>that different relying parties can use the same certificate.  In that 
>case, SIM syntax needs to change and needs to explicitly include 
>SIIType.  If that were done, there does not appear to be a security 
>problem with it.
>

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 9 Nov 2003 13:53:43 +0100

Santosh,
I agree with your vulnerability analysis.
The real problem is rather to get broad support for SIM due to the
numerous other ways to achive the same functionality.  Most of the
alternatives are supported by existing standards.

From an upgraded earlier posting of mine:

Korean citizens (as well as Swedish citizens) have a citizen number that
is more or less "secret" as it contains date-of-birth and gender.  To put
this number in clear in a generic ID-certificate would limit the certificate's
usability as only some relying parties (typically government-associated)
need this information.  To cope with this, you propose a method where
a user in a safe and selective way can transfer this number to an RP
that can verify its authenticity.

Actually the scope of this problem touches a more fundamental issue that
I have spent some time studying: How to combine PKI with "information"
concering the subject.   Therefore, I took the liberty to describe some
completely different methods to achieve "approximately" the same goal.

FINLAND'S SOLUTION
----------------------------
Assign a unique electronic ID (number) to each citizen and supply this
information together with the semi-secret citizen-ID
to the RPs that have the proper authority to handle the secret ID.
The electronic ID has no usage except in on-line usage using
certificates but is still usable even for RPs that do not have
or need the secret ID. 

ON-LINE ASSERTIONS
-----------------------------
The following method allows *any* data to be given to RPs, and without
deploying secrets in certificates:

1. The user surfs to an on-line service that needs some additional CA-
   registered information regarding the user
2. The user is authenticated using SSL/TLS client-authentication
3. The service automatically redirects the user to a CA URL which is deducted
 from the issuer of the certificate
4. The user is authenticated by the CA using SSL/TLS client-authentication
5. The CA application informs the user that "Service XYX wants the following
   user attributes, do you agree?"
6. The user hits OK and is automatically redirected back to the service with 
   an SAML "ticket" containing the requested attributes signed by the CA

Although looking complex, it is just a couple of mouse-clicks + two
authentication PIN-code-operations for the user to perform. 

If the RP also saves the received ticket, it will not have to repeat the
request a second time, which makes this scheme both very flexible
and user-friendly.

OFF-LINE ASSERTIONS
----------------------------
A user may also surf to a CA, and after being authenticated, request
that the CA sends a CA-signed message with user-attributes to a
selected RP.  To make this a viable scheme, the user-certificate should
contain a unique and static ID in the CAs issuing-domain, in order to
to not have to repeat this process for each certificate renewal.

AUTHENTICATED RP LOOKUP
--------------------------------------
Another solution is that the service authenticates to the CA and gets
this information directly based on user certificate as input.  This
solution is based on that the CAs must "know" the RPs and their
needs which is a drawback.

MULTIPLE CERTIFICATES
---------------------------------
Multiple client-certificates (with and without the number in clear), is of
course another possible solution that has the advantage that nothing
special has to be built.  Requires a little bit more knowledge on the
user's part though and is entirely static with respect to user-attributes.

cheers,
Anders Rundgren

----- Original Message ----- 
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 08, 2003 16:12
Subject: RE: Comments on draft-ietf-pkix-sim-01

Steve:

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 9 Nov 2003 10:49:49 -0500

Anders:

If I understand correctly, the SIM approach may be more flexible as more
secure than some of the items listed below since the CA need not hold all
the sensitive information and become a target of attack.

The attractive part of SIM is that even at the RA, sensitive information
needs to be there at the most during registration and after that it is
hashed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: Sunday, November 09, 2003 7:54 AM
To: Santosh Chokhani; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-sim-01

Santosh,
I agree with your vulnerability analysis.
The real problem is rather to get broad support for SIM due to the numerous
other ways to achive the same functionality.  Most of the alternatives are
supported by existing standards.

>From an upgraded earlier posting of mine:

Korean citizens (as well as Swedish citizens) have a citizen number that is
more or less "secret" as it contains date-of-birth and gender.  To put this
number in clear in a generic ID-certificate would limit the certificate's
usability as only some relying parties (typically government-associated)
need this information.  To cope with this, you propose a method where a user
in a safe and selective way can transfer this number to an RP that can
verify its authenticity.

Actually the scope of this problem touches a more fundamental issue that I
have spent some time studying: How to combine PKI with "information"
concering the subject.   Therefore, I took the liberty to describe some
completely different methods to achieve "approximately" the same goal.

FINLAND'S SOLUTION
----------------------------
Assign a unique electronic ID (number) to each citizen and supply this
information together with the semi-secret citizen-ID to the RPs that have
the proper authority to handle the secret ID. The electronic ID has no usage
except in on-line usage using certificates but is still usable even for RPs
that do not have or need the secret ID. 

ON-LINE ASSERTIONS

1. The user surfs to an on-line service that needs some additional CA-
   registered information regarding the user
2. The user is authenticated using SSL/TLS client-authentication 3. The
service automatically redirects the user to a CA URL which is deducted  from
the issuer of the certificate 4. The user is authenticated by the CA using
SSL/TLS client-authentication 5. The CA application informs the user that
"Service XYX wants the following
   user attributes, do you agree?"
6. The user hits OK and is automatically redirected back to the service with

If the RP also saves the received ticket, it will not have to repeat the
request a second time, which makes this scheme both very flexible and
user-friendly.

OFF-LINE ASSERTIONS
----------------------------
A user may also surf to a CA, and after being authenticated, request that
the CA sends a CA-signed message with user-attributes to a selected RP.  To
make this a viable scheme, the user-certificate should contain a unique and
static ID in the CAs issuing-domain, in order to to not have to repeat this
process for each certificate renewal.

AUTHENTICATED RP LOOKUP
--------------------------------------
Another solution is that the service authenticates to the CA and gets this
information directly based on user certificate as input.  This solution is
based on that the CAs must "know" the RPs and their needs which is a
drawback.

MULTIPLE CERTIFICATES
---------------------------------
Multiple client-certificates (with and without the number in clear), is of
course another possible solution that has the advantage that nothing special
has to be built.  Requires a little bit more knowledge on the user's part
though and is entirely static with respect to user-attributes.

cheers,
Anders Rundgren

----- Original Message ----- 
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 08, 2003 16:12
Subject: RE: Comments on draft-ietf-pkix-sim-01

Steve:

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, November 07, 2003 10:14 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sun, 9 Nov 2003 17:32:24 -0500

>I agree that putting multiple sensitive attributes in one location is

Sanosh,

The issue the NRC report addresses is not the fact that these 
attributes are "sensitive" pre se. Rather, each attribute of the sort 
you noted is an identifier from a different identity system. The 
report argues that it is a bad idea to bind multiple identity 
attributes in the same cert.

>is not going to change the relying party workstation vulnerability.

Again, the argument made is the report is not about disclosure of 
these identifies to an RA or CA, but rather the bundling of multiple 
identifiers in a single cert.  The hashes representing the different 
identities, by their combined presence in a single cert, would make 
it easy to link disparate user identities to the same underlying 
individual, a privacy concern.  So, I suggest that we not try to make 
any provision to represent multiple identifies of this sort in a 
single cert.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 10 Nov 2003 15:20:42 -0500

Steve:

Do you think there is some benefit to the SIM discussing privacy and linking
issues?

I can see that if the same user name (say DN) was issued different
certificates with different attributes by the same CA or different CAs, it
will be easy to link the identities represented by the various attributes.

Should this be a guidance to the subject, RA or both.  It could not be CA
since the CA does not vet these values.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Sunday, November 09, 2003 5:32 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

Sanosh,

>certificate are not the points of attack since they do not contain 
>sensitive information.  The likely points of attack are the hash, 
>password, subject workstation, relying party workstation, and RA 
>workstation.
>
>attributes in various certificates (so that you can present the 
>required attribute to the relying party), the relying party should only 
>see the

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 10 Nov 2003 17:38:45 -0500

I agree

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, November 10, 2003 5:33 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-sim-01

At 15:20 -0500 11/10/03, Santosh Chokhani wrote:
>Steve:
>
>Do you think there is some benefit to the SIM discussing privacy and 
>linking issues?
>
>certificates with different attributes by the same CA or different CAs, 
>it will be easy to link the identities represented by the various 
>attributes.

I think this is an issue for a CA/RA and for a user. A CA/RA ought 
not facilitate linkage but putting multiple personal identifiers into 
the same cert, or by issuing multiple certs under the same DN, with 
different, personal identifiers. But, it is also the responsibility 
of a user to not request certs from multiple CAs with the same 
subject DN, with distinct personal identifiers.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Nov 2003 17:32:56 -0500

Steve