Subject: Re: QC Sample Sucks (a bit)

From: Anders Rundgren <[email-masked]>
Date: Thu, 18 Mar 1999 14:13:24 +0100

Michael,

>Nevertheless, a photo-id serves a useful authentication function. But any
>protocol that assumes that biometric data is secret is fundamentally flawed.

There is a slight but very important difference between public information and
information that is not secret. 

Neither SSNs or biometrics can be assumed to be secret but they
should not be published in such a way that anybody can access them.  A 
protocol (if we are talking "computerease") should not expose such data to 
others than the Relying Party (and under the control of the Subject).

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Mar 1999 19:40:20 +0100

I disagree with the subject heading of this discussion.

The function of the example cert is to give an technical example of how the
profile is used. I don't believe that there is any "typical" ID-certificate
so I see the use of the example from the technical viewpoint. Not a guide
to how an ID should be expressed.

Regarding biometrics:

Anders suggests that the Qualified Certificate profile should include
specific solutions for storing biometric data. I'm not so sure.

First, this is already possible. You can:

1) include biometric data or a hash of biometric data as a unique
identifier stored in the dnQualifier.
2) define a new attribute and include it in the structure.

Both are valid options.

The problem of defining anything further in the profile is the lack of
standards. You would anyway have to provide additional information in order
to instruct the relying party how to use the data, so nothing would add to
the existing possibilities.

Secondly I don't believe that this widely asked for at this stage of
evolution. Maybe something for the future when there are useful and
standardized way to express biometrics and standardized way to make
sensible use of the information stored in a certificate. Until then this
will all be proprietary solutions used under locally defined conventions.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Mar 1999 07:32:06 +0100

Anders Rundgren wrote:

> Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
> NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key Infrastructure,
> this cannot (should not at least) be interpreted as public for anybody.
> Just to your own selection of trusted RPs.

This runs counter to the very idea of a cerificate -- which is a 
verifiable credential.  That there might be opaque parts of a
certificate which are meaningful only to a verifier,  perhaps
with active participation on the part of the cert holder to
protect privacy, is another matter.  If I read the above
correctly,  you're suggesting that the ID-certficate be
encrypted? 

Sorry if I am unclear but I wrote "never be TRANSMITTED" in clear.  The RP should verify
the cert using current PKI technology.  You may know that in Europe there are many
ID-card programs in deployment phase and unfortunately few of these have addressed the
issue of access to CA directories.  IMO CA services should (unless you have a search
warrant) be restricted to publishing anonymous CRLs.

> >It notes that if capture of a biometric if not physically secure, then
> >there is a terrible risk of spoofing.

Biometric data is as sensitive as a private key -- perhaps more so,
it's harder to revoke.  It shouldn't be in a cert, which is a public
credential.

Why do you insist on PUBLIC credential?  Do I break some "holy" PKIX-rule by
saying that only the USER can give away credentials to his/hers TPs?
I am not a very religious man so I can take it :-)

This is what will happen otherwise the whole ID-card business going on in Europe
will fail hard.

A very common biometric object in ID-cards is a photo.  It can't be revoked but
is not exact either.   Such data make perfect sense if you want to verify that the holder
of the "Personal Security Device" (holding a cert) really is matching. 

You CAN put photos on the outside of a PSD if it is of reasonable size.  However,
I am working with a concept where the PSD will be "buried" within a mobile phone.
An electronic photo in the cert (one of the ID-certs you have) will be much easier
for a security officer to read on a large screen than current ID-card photos.

Anders Rundgren

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Mar 1999 11:26:52 +0100

Juergen,
>"Petra Glöckner" wrote:
>> 
>> Hi Anders,
>> 
>> I never meant to cope with all different scenarios with the
>> one QC example. I just wanted to display the concept of our
>> PersonalData structure with the possibility to have multiple
>> authorities responsible for different attributes.

>But there is another concept probably more meaningful. The X.509
>standard enables multiple authorities to issue attribute certificates.
>The authorities are called attribute certification authorities. End
>entity´s attribute certificate is linked to entity´s public key
>certificate by entity´s distinguished name or certID.

That is the way to do it!  Now the "only" question is how the user is going to
get these attribute certificates that could contain non-public information.
Then you will end-up with my CyberPhone concept where you use a 
"light" ID-cert to access information that concerns only you and the RP.
Or is there another "silver bullet"?

>Is there someone who is planning to implement a personal data record
>where multiple authorities are responsible for different attributes?
>Personally, I think that your approach leads to long vehicle
>certificates of short life-time. The more attributes and different
>authorities are involved the longer the certificate and the shorter the
>lifetime. Certainly not designed for today´s smartcards.

Or as I would put it: An impossible idea unfortunately already implemented.

This is one of the reasons our ID-card project is close to a stand-still.  A personal
ID-card is not an employment card.  And vice versa.

Anders Rundgren