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

[Anders Rundgren <anders.rundgren@xxxxxxxxxx>]

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