Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-printsin QCs

From: Anders Rundgren <[email-masked]>
Date: Tue, 7 Dec 1999 16:25:08 +0100

Well Steve,
This was the question.  And it was not only raised by me:

>  >Someone mentioned that the hash is sufficient, since the actual
>  >data could just "tag along" with the cert, if required. But there
>  >needs to be a standard even for this kind of operation. Is there?
>
>
>This was the original QC solution. As you noted (and I have told the
>authors several times) this is a half-made solution. A genuine example
>of poor engineering!

PKIX creates infrastructure standards.  Specifying a means of binding 
biometric data to a cert is within scope.  specifying a means of 
carrying this data in a wide range of application environments is out 
of scope.

I would say that this sloppy definition requires that the maker of the smart-card and
the authenticating application are identical.  Interoperability=ZERO.

 For example, we don't tell IPsec, SSL/TLS, or S/MIME how 
to transport certificates or CRLs in those applications;

Odd examples.  AFAIK SSL/TLS specify exactly how and when client and
server certificates are transmitted between client and server.

Having defined a means of binding biometric data to a cert, 
while not putting it in the cert and thus mitigating privacy 
problems, we have done the part of the job that is appropriate for 
this WG.

As noted by others, the URI+hash thing does not do the privacy job the way you describe it and then
the whole foundation is flawed.  I.e. we are back to "file-size" discussions which are pretty trivial.

User certificate selection is (so far) the only documented, interoperable, general-purpose solution to privacy
problems of the kind introduced by certificates containing "sensitive" information like SSNs, biometrics etc.

Anders

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Dec 1999 13:51:52 -0500

>Anders,

While interoperability is a prime focus of IETF WGs, we still have to 
have bounds on our work.  Smart cards are not the only means of 
dealing with certs. So, the fact that there is need for additional 
standards in specific contexts, in order to ensure interoperability 
is not new, nor surprising.

>server certificates are transmitted between client and server.

Unfortunately, your knowledge is lacking here. SSL/TLS do NOT specify 
cert usage details at all.  This is the province of HTTPS, a 
different (and not IETF standard) protocol.

>problems, we have done the part of the job that is appropriate for

It is out of scope, starting with the assumption that certs live 
exclusively on smart cards.

>User certificate selection is (so far) the only documented, 
>interoperable, general-purpose solution to privacy
>problems of the kind introduced by certificates containing 
>"sensitive" information like SSNs, biometrics etc.

I don't what point you are trying to make above.

Steve