Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

From: "David P. Kemp" <[email-masked]>
Date: Mon, 23 Oct 2000 13:54:24 -0400 (EDT)

Polar,

You keep paying lip service to the idea that "standards are not a
substitute for system engineering", and then turn around and say that a
technical interoperability profile MUST require certain behavior, and
that PKIX must somehow mandate that whatever infrastructure is out
there today must be made "secure".

That just isn't the way things work.

A driver's license is a paper certificate which binds some information
(name, address, date of birth, photo) using some security info (special
lamination, holograms, etc).  It is issued according to well known
business practices which give relying parties some measure of the difficulty
of obtaining one which contains incorrect information.

Relying parties (check cashers, liquor stores, cinemas) use the
driver's license to make access control decisions based on their own
judgement of the strength of the authentication mechanism and the risk
of loss.  They DO NOT have a contractual relationship with the issuer
of the driver's license, nor do they rely upon standards stating what a
license must contain.  They rely on what's in front of them and on the
generally accepted business principle that the 50 states can be trusted
to issue ID cards usable for the purpose of keeping a check written out
to one person from being cashed by someone else.

An attribute authority (someone issuing a season pass to an amusement
park) will include sufficient identifying information (such as a name
and driver's license number) to ensure that John Smith's (senior) pass
cannot be used by John junior, or by some other John Smith.  This is all
done without any contractual relationship between the state DMV and the
amusement park.

As PKI and PMI are used to automate real-world business processes,
system engineering is required.  I don't consider the following, which
you seem to be proposing, to be a reasonable approach:

1) Look at all the SSL certificates that are already out there,
2) Impose technical constraints on attribute certificates, in an attempt to
3) Solve a general unspecified access control problem.

Don Flinn and others have well expressed the need for both due
diligence and system engineering when applying PKI and PMI.  I agree
with them, and I am unconvinced that your approach of applying
technical constraints to solve a procedural problem will meet with any
success whatsoever.  I am therefore opposed to specifying in an AC
profile the precise (or even the imprecise) conditions under which a
compliant AC issuer MUST link an AC to a particular PKC.

Dave

> From: Polar Humenn <[email-masked]>
> 
> Denis,
> 
> I am in agreement with you on your approach of including the objectDigest
> Info along with entityName or baseCertificateID. I think in environments
> where the Relying Parties, Attribute Certificate Issuers, and Subject
> Entities do not know and trust a priori the certificate management
> environment they all are emphatically working in, then the entityName
> and/or baseCertificateID must only be used in conjunction with the
> objectDigestInfo.
> 
> A good thing would be to figure out under the precise conditions in which
> a compliant Attribute Certificate Issuer MUST include objectDigestInfo.
> 
> I can think of one of the conditions right off.
> 
> In applications where there is no absolute assurance by all three classes
> of possible parties, i.e. subjects, attribute certificate issuers, and
> relying parties, are privy to each others business practices about the
> use of DN's.
> 
> I am not yet sure how you can write such requirements without getting
> agreements from all three parties.
> 
> -Polar

---

From: Aram Perez <[email-masked]>
Date: Tue, 24 Oct 2000 01:47:38 -0700

David Kemp wrote:

[snip]
> of obtaining one which contains incorrect information.

There are at least three "attributes" with incorrect information on my
current California Drive License: the weight is wrong (I won't say in which
direction ;-) and my picture shows me with glasses (I wear contacts now) and
much darker hair (I have a bit more gray :-(

> to one person from being cashed by someone else.

I've stayed out of this thread, but you've touched upon one of my "hot
buttons". I'd like to make two points:

1. Since when does my driver's license prove that I have enough money in my
bank account to write a check, or that I am "authorized" to buy liquor (and
get drunk) or that I can go see an R rated movie. The only thing that my
driver license states is "This license is issued as a license to drive a
motor vehicle: it does not establish eligibility for employment, voter
registration, or public benefits." So the only thing it "authorizes" me to
do is drive a motor vehicle. And given how I look, I'm sure that if I walked
into a liquor store and bought some whiskey, I wouldn't be asked to show my
license. Maybe I'll start a campaign to change the license so that it states
"... it does not establish eligibility for employment, voter registration,
or public benefits; not does it guarantee payment for check written by this
person, or authorizes the person to buy liquor or to watch adult movies" or
even better "This license is issued as a license to drive a motor vehicle,
to write checks, to buy liquor and to watch R and X rated movies: it does
not..." ;-)

2. I won't try to change the "real business world" where it's accepted
business practice to confuse identity with authorization. There is a big
difference between "generally accepted business practices and principles"
being used today and trying to develop technical standards based on
presumptions of only right and wrong. Electronic relying parties can not
follow the same business practices or principles because certificates
(whether identity or attribute) can't have "almost correct" information.
Should I ever be asked to show my license to buy liquor, I would be allowed
to because my picture is "close enough" to how I currently look.
Paraphrasing Ed Gerck, "The lifetime of a certificate is inversely
proportional to the number of its attributes." Why? Because changing 1 bit
invalidates the certificate, even though in the real world changing an
attribute does not invalidate my license.

Just my thoughts,
Aram Perez

[snip]

---

From: Polar Humenn <[email-masked]>
Date: Mon, 23 Oct 2000 17:49:40 -0400 (EDT)

> to one person from being cashed by someone else.

If we take this model. You don't just check the attribute certificate
(i.e. the drivers license). You check some identifying information on that
license that ties the certificate to the person giving it to you. A
picture, some bio information, (age, height, weight, eye color) (however,
incorrect, I might add :) that correlates the "certificate" to the entity.  
Those are *identifying* attributes, not authorization attributes. In the
PKI space, the *identifying* attribute is the public key.

A drivers license has only has one authorization attribute. The privilege
to drive a car. 

And that certificate is really issued to an entity that matches the
*identifying* attributes. On that certificate, the entity may be given a
name, an address, and possibly a number, for easy look up. That look up is
only relevant in the DMV's own directory, not in the post office's
directory, or at the hospital.

> done without any contractual relationship between the state DMV and the

The amusement park "would like to" include sufficient identifying
information (such as a name and a driver license number), but, it cannot,
because by the standard, it is limited to the DN given, "CN=John Smith,
O=Smith". If attribute certificate adds anything else to the DN, then the
correlation fails where it should succeed.

If there is insufficient information to begin with (i.e. capability for two
John Smith's one with a driver's license, and a Bob Smith's 13 year old
named John) then the correlation can succeed where it should fail.

Isn't this called a hole?

If I issue an amusement park pass to a guy with a drivers license, I
really have to either extract the same identifying attributes, picture,
height, weight, eye color, (in PKI, the public key), or I have to name him
by including his indexing attributes, such as his name, address, and
possible number, BUT I also have to say where that index is relevant, i.e.
the DMV of California, if not further classified by the State Authority of
California, certified by the State Registry of the United States of
America, certified by the Nation Registry of the League of Nations,
certified by Verisign. :)

Cheers,
-Polar

> > agreements from all three parties.

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com