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.
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.
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.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.
It is out of scope, starting with the assumption that certs live exclusively on smart cards.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.
I don't what point you are trying to make above. Steve