[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: QC's - for human eyes only?



Ilan,
I agree 100% to what you are saying and exactly the points given by you 
I put in this list about a year ago.

I.e. Finger-print support, in-line biometric data option, and no mentioning of
how the verification is actually performed.

The reason for not putting in finger-print information was said to be due to no
request for such data [I don't count apparently - now we are two :-)] and that finger-print techniques are
not yet established.  My reaction to this was: Who have been asked?  The PKIX-list is
maybe not the only place to look in.  And there are at least 10 companies working 
and shipping biometric finger-print sensors.  Several "standard" formats exist today.

Regarding the in-line data of biometric data, the IETF chair has told me that current computer
technology is not capable of processing certs of lets say 10K size.
My reaction to this is: What systems do really have such limitations?  Must we
create a standard for the next Millennium based on Windows 3.1-type of platforms?
The only sensible thing would be to add a biometric data-type that contains a MIME-type
identifying the content-type and a blob holding the actual data.  The in-line feature has
huge advantages over the current definition as you reduce network overhead, remain
compatible with current authentication and signing schemes, and get a nice persistent
container for all user data.

You are absolutely right on the networked certificate solution as well.  Even a part of PKCS #15 I think.

I.e. there are no TECHNICAL problems whatsoever with adding your suggested features!

Regards
Anders Rundgren
[slightly flaming] Senior Internet e-commerce architect

----------
From:  Ilan Shacham [SMTP:ilans@arx.com]
Sent:  Sunday, December 05, 1999 13:39
To:  Ietf-Pkix (E-mail)
Subject:  QC's - for human eyes only?

Hi all,
Section 3.2.4 of the QC profile, which describes the biometricInfo 
extension states:

"   ...This extension SHALL only be used to store a hash of biometric
   information suitable for human verification, i.e. where decision
   whether this information is an accurate representation of the subject
   is performed by a physical person. This implies a usage where the
   biometric information is represented by for example a graphical
   image, displayed to the relying party, which MAY be used by the
   relying party to enhance identification of the subject..."

I don't see why we should limit ourselves in such a way, and not allow
for machine verification of biometric data (such as finger-prints, etc.).
It seems to me that even if today biometrics aren't advanced enough,
we should not limit ourselves towards the future.

Another shortcoming of the biometricInfo extension, is that it does
not allow for the actual biometric data to be included, but instead
mandates the data to be accessed through a URI. This approach
may be relevent today, when biometric data is large, and memory
on smartcards is limited, but surely advances in the future would
allow the actual biometric data to be put in the certificate, it would
be a shame to create a new extension for ActualBiometricInfo...
I could also see why it would be relevent not to rely on the network
for maintaining all the information needed to validate a certificate.

Comments?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:ilans@arx.com
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864