Subject: Re: Pictures in QCs - No problems!

From: "David P. Kemp" <[email-masked]>
Date: Mon, 22 Mar 1999 10:58:08 -0500 (EST)

> Tom Gindin wrote:
> >  While Anders admittedly knows little about ASN.1, he may be onto
> >  something useful here.  What would be wrong with defining a non-critical
> >  extension called displayableImage with syntax
> >  DisplayableImage ::= SEQUENCE {
> >       mime-type PrintableString,          -- I apologize if it's really
> >  IA5String
> >       body      OctetString
> >  }
> >       and then trying to get the browsers to support it?  They don't do so
> >  yet, of course, but it seems like a good idea and not incredibly difficult.

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.

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.

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.

---

From: Ed Gerck <[email-masked]>
Date: Mon, 22 Mar 1999 09:47:15 -0800

David P. Kemp wrote:

David:

Thanks for inserting some good common sense into this thread. The
temptation here is (again) to increase security by taxing privacy --
however, privacy is a long-term asset while security is a short-term
goal. So, this trade-off is not a good idea [1].

> A picture is not an identity; 

Here, I must take issue. This is IMO not correct, even one argues that
it may depend on what is defined to be an identity. 

For example, if you have video footage of a crime, those pictures
constitute not only identities for the persons present at the crime, but
they also identify their actions and reactions. Even if you do not know
the name of the persons, they may still be found and held resposnible
based on those identities. It is of no concern here if such pictures may
be ambigous or even obscure. In the same way that one may be  called
John Smith, which is very ambiguous but is an identity. BTW, even an
expired driver's license can be a valid identity -- even if not valid
for driving a car. 

It is interesting though to see what else is far too often accepted
without questioning. That identity must be "assigned" by someone -- as
the only type of identity possible. But, perhaps we can recognize that
this is a circular attempt to define identity -- "identity is what
identifies". Instead, I suggest in [2] that "to identify is to look for
coherence" -- where coherence is (as usual) "a natural or logical
connection".  Note first that this is a non self-referential definition
of identification -- also, not circular.

Identification can thus be understood not only in the sense of an
"identity" connection, but in the wider sense of "any" connection. Which
one to use is just a matter of protocol expression, need, cost and (very
importantly) privacy concerns. The essence of identification is thus to
find connections -- where absence of connections also counts. 

> it is not reasonable

Agreed. This is open to debate...but it is certainly a bad idea for
privacy reasons. Any privacy information you give out or allow to be
stored is a security threat [1], not a security gain.
 
> The attributes themselves

Agreed, with a comment -- the PKIX model concerns itself with
certificates which bind an identity with a key and such identities are
blobs anyway you look at them, either as Distinguished Names or as
pictures. It is the PKIX standard and the CPS which may provide meaning
to them -- outside the certificate. 

Take Section 11.2 of X.509v3, "Management of certificates". It states
that the certificate allows an association between a name called "unique
distinguished name" or DN for the user and the user's public-key: "A 
certificate  associates the public key and unique distinguished name of
the user it describes.", while Section 7 explains that such DNs are
essential to the security design of X.509: "Authentication relies on
each user possessing a unique distinguished name." But, how are such DNs
assigned? Where are they unique? The DN is denoted by a NA (Naming
Authority) and accepted by a CA (Certification Authority) as unique
within the CA's domain, where the CA can
double as a NA. It is interesting to note that the same user can have
different DNs in different CAs, or can use the same DN in different CAs
even if it is not the first one to use it in a CA -- so different DNs
for different CAs do not necessarily mean different users and
vice-versa. Further, a DN does not have to contain the user's real-world
name or location. Thus, semantically, the CA certificate refers to a
name; however it does not denote it [3].

The same applies to a picture -- which is also a "name", a reference.

Cheers,

Ed Gerck

=========================
REFERENCES:

[1] http://www.mcg.org.br/faust.htm

[2] http://www.mcg.org.br/coherence.txt and
http://www.mcg.org.br/coherence2.txt

[3] http://www.mcg.org.br/certover.pdf
_____________________________________________________________________
Dr.rer.nat. E. Gerck                                 [email-masked]