Re: I-D ACTION:draft-ietf-pkix-sim-00.txt

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

Hi Guys,
You wanted some comments on this?

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.

=====================================================
Regarding the method you suggest, I feel that it is a bit hard for the user to
have to deal with long random numbers that probably will change for each
certificate renewal.  At least as the foundation for an IETF-standard, I
would rather propose an informational or experimental RFC.
=====================================================

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.

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.

SIGNED SECRET
---------------------
Yet another solution is that user signs the secret data using his/her private
key and that there is a copy of the signature value in the certificate.  Note:
I have not made any deep crypto-analysis on this one, so it may be broken...

cheers,
Anders Rundgren