Subject: RE: Pictures in QCs - No problems!

From: Anders Rundgren <[email-masked]>
Date: Tue, 23 Mar 1999 08:46:12 +0100

David,
>There is nothing technically challenging about defining such an extension,
>but why should PKIX do it?  What is the advantage of stuffing a
>JPEG image into a certificate, as opposed to signing a MIME structure
>(web page or message body) containing the JPEG image and everything
>else of interest?  Browsers already know how to decode a variety of
>mime-types, and will sooner or later know how to validate signatures
>the PKIX-S/MIME way.

It is surely not technically challenging but it is nifty if you are working with ID-cards
based on smart cards.  Cost (always important!) , security (I have confirmed with
a major bank that they like this idea) and convenience would be greatly improved
by adding a few biometrics to a cert:

http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP

>In other words, attaching attributes, biometric values, and other metadata
>to the subject of a certificate sounds more like an application issue
>than a Public Key Infrastructure issue.  A PKI binds a public key to
>an identity, where an identity is the domain-specific unique ID of
>the subject.  A picture is not an identity; it is not reasonable
>to store public keys in a database using a picture of the subject's
>face or handwritten signature as the primary index.

You are probably right in theory about what PKI is but in a practical application
like an ID-card scheme you can be less stringent without losing a single advantage
of PKI.  I consider much of the QC attributes as pure metadata as well although they
can be searched for in a database.

>I hope that PKIX's new, expanded charter covering Attribute Certificates
>will be limited to ensuring that attributes can be issued, distributed, 
>located and securely bound to subjects.  The attributes themselves
>should be opaque blobs (OID/OctetString pairs) as far as PKIX is
>concerned.

I can hardly see that things become much better because you put JPEGs in Attribute
certificates instead of in QCs.   Just more overhead.   The prime uses of attribute
certificates will IMO be for dynamic data like roles and authority.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

But the real question is:  There are proponents and opponents to extending certificates
to contain biometric data.  If the QC-spec. does not support this in a structured fashion
people like me will insert them anyway.  Does IETF gain anything by creating a mess
for those who support this scheme?

Or is the IETF afraid that to technically support biometrics in QCs could be interpreted as
IETF says: "Biometrics is the way to go" ?

Also note that such an extension does not affect any "sensible" and "politically correct" 
usages of QCs.

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

---

From: "Dale Gustafson" <[email-masked]>
Date: Tue, 23 Mar 1999 16:31:22 -0600

Anders,

Yours is one of the more widely applicable ideas suggested here recently and I believe it
should be evolved further.  Intuitively, there is a need to add innovative capabilities like
this to PKIX that will be difficult to satisfy simply by extending x.509 v3 public key / ID
certificates with a plethora of non critical extensions -- primarily due to the impact on
certificate size and a growing, installed base of ID certificates and secure applications that
use them.

Over time it may well become increasingly difficult to achieve consensus on any proposed
addition or modification to the x.509 v3 certificate profile -- especially if each new secure
application is likely to need / want to define more "application specific" information that
needs to be included in ID-certs.

Perhaps this concept could be evolved more readily through inclusion within Attribute
Certificates that will, in some cases, be distributed to a more targeted set of users (e.g.,
depending on the needs of secure applications).  In theory, such an approach would enable
secure application developers to evolve their designs more rapidly.  Presumably, the high level
design of attribute certificate support in PKIX would provide secure application developers
with a structured method that helps them define which data elements { must | should | may } be
included in a given attribute-cert, how to reference other data elements, etc.  This also
suggests that it might be beneficial to define a set of standard data elements that are
available for use in attribute-certs when applicable.

Best Regards,

Dale Gustafson