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

From: [email-masked]
Date: Mon, 04 Nov 2002 10:06:33 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Subject 
                          Identification Method (SIM)
	Author(s)	: J. Park et al.
	Filename	: draft-ietf-pkix-sim-00.txt
	Pages		: 12
	Date		: 2002-11-1
	
This document provides the new straightforward approach to generate 
and verify unique information for identifying of the certificate 
subject. 
A Virtual ID(VID) may be put into the 'othername' field of the X.509 
subjectAltName certificate extension to make provisions for 
identifying the subject.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-sim-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sim-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 24 Nov 2002 13:59:37 +0100

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

---

From: [email-masked]
Date: Mon, 25 Nov 2002 06:51:15 -0700

and of course the (FSTC) FAST model has some authoritative agency/authority
(for the information) .... authenticating the information in a transaction
that (can) looks very much like an existing online payment authorization
transaction (aka the end-user makes some signed assertion to a RP ... and
the RP gets the real-time agreement back directly from the authoritative
agency). This somewhat makes the distinction between a certification
authority (as TTP) and an authoritative agency; where there can be
contractual and liability relationship between the RP and the agency
certifying (& responsible for) the information.

There are (at least) three issues

1) certificates originally targeted as solution for offline certified
information in an offline environment ... attempting to find a reason in an
online world

2) x.509 identity certificates creating a value proposition .... for a time
somewhat attempting to aggregate more & more privacy information ...
exasperating the identity theft and privacy leakage problems. one reaction
was institutions going to relying-party-only certificates that contained
just an account number .... which were attached to signed messages &
transactions that contained the same exact account number and transmitted
to business process that contained the account record and already contained
a copy of the public key for authenticating the transaction (trivially
showing that certificate itself was redundant and superfluous). The
existence of such certificates were technical artificial contrivance having
nothing to do with any business process.

3) the traditional online business model has had bilateral
agreements/contracts a) between the authoritative agency (like a financial
institution) and the end-user, b) the end-user and the relying party and c)
the relying party and the authoritative agency. Many of the certification
authority constructs were introduced as TTPs that would certify information
nominal the responsibility of some authoritative agency .... supposedly
because the relying-party might not have an online conduit to the
authoritative agency. However, the CA typically had no direct
contract/business relationship with either the authoritative agency or the
relying party .... any contract (implied or real) was between the end-user
and the certification authority (which could be totally unrelated to any of
the three bilateral agreements already mentioned).  I think that the GSA
has addressed this by making the CAs agents of the GSA and the RPs having
contractual relationship with the GSA (with regard to the GSA agents).

the certificate challenge then is 1) role in online world, 2) contain
useful information w/o leaking useful information, 3) some correspondence
to normal accepted business relationships (especially in a TTP scenario
where the TTP is independent of the actual authoritative agencies for the
information and all existing business relationships).

Some of the adult oriented internet has been using $1 auth for sort-of a
real-time age checking transactions. You do a something that looks like
MOTO payment transaction with a RP ... the RP does a $1 auth through the
normal network but doesn't do settlement (so nothing ever shows on your
statement). The result of the $1 auth is saved and used as implying that
you are of legal age (aka there is legal relationship between you and the
financial institution acting as an authoritative agenchy, there is legal
relationship between the RP and the financial infrastructure ... and you
are directly interacting with the RP). While there are some issues with
regard does the existance of legal relationship between you and your
financial institution actually implying legal age ... as well as the lack
of a digital signature (or other form of strong authentication) actualy
mean that you are you (say a x9.59 digitally signed transaction) ... the
control flow and the business relationships follow normal accepted
practices.