Subject: RE: KISS for PKIX

From: "David P. Kemp" <[email-masked]>
Date: Fri, 16 Jul 1999 11:05:04 -0400 (EDT)

> From: "Flanigan, Bill" <[email-masked]>
>
> > I agree that these are precieved problems that hinder PKI deployment, but I
> > also think that many of these are red herrings.  If I use certificates to
> > authenticate users, in lieu of passwords, why are there any new legal
> > issues?  Part of the problem is that people have been led to believe that a
> > PKI must support non-repudiation, which generates a large number of valid,
> > legal concerns. 
> > 
> BF:  Yes, Steve, and these legal issues go way beyond those related to a
> password (in part because now there are a whole bunch of additional entities
> involved).  They include the end entity (human and
> human-responsible-for-machine), the registration agents (RA, LRA,
> out-of-band delivery person/service), the CA (both the cert-server side and
> the directory/repository side), the PKI administrators, etc.  Then there are
> validity issues, CRL issues, repository time-and-security issues (e.g., how
> long must a cert or CRL remain in secure storage?  50 years?  150 years?)
> Aside from the CP and CPS, there are also Privacy Act issues.  Then there is
> key escrow and recovery (yes, they are completely different and involve
> different processes and entities).  I sometimes wonder if there are enough
> lawyers on the planet to support all these up-and-coming PKI!
>
>    <snip>
>
> BF:  Steve, very few humans will read (or be able to understand if they
> read) the CP.  The number of extensions in PKIX for machine-readable policy
> is miniscule compared to what is needed--I would hazard a guess of 30-50 for
> the "typical" CP (and, of course, we still have the CPS which may or may not
> have policy-related items not explicit in the CP plus CA cross certification
> where policy mapping is a MUST).
> 
> BF:  P.S.  Being an early adopter of a PKI striving to be based on PKIX (and
> commercial products) that goes beyond the pilot level is not fun.  It almost
> seems like the standards were designed to make sure that early adopters
> don't progress beyond the pilot stage!  The same could be said of commercial
> products.  You must have very deep pockets to progress a PKI from
> supporting, say, 100K certs to 5,000K certs.  And I am rapidly coming to the
> conclusion (a conclusion I don't at all like) that if PKIX is to the PKI
> flavor of choice for the planet, it must be substantially overhauled (or
> replaced).

Bill,

I must say I'm totally confused by this conclusion.  Of all the issues
you list (the number of PKI entities, validity, archiving, Privacy Act,
KR, CP and CPS), what single issue would be affected by a modification
to the certificate structures defined by PKIX/X.509?

How would a change in the X.509 certificate format affect the number of
CAs, RAs, etc required to run a non-pilot PKI?  How would it affect
archive requirements?  How would a change in the syntax of the X.509
CertificatePolicies extension affect (for the better) the legal/policy
requirements of operating a large-scale PKI?  In short, what single
modification to X.509, or what substantial overhaul or complete
replacement, would make any of these issues the slightest bit easier to
manage or resolve?

In other words, if PKIX needs replacement, what are the business
requirements for whatever you would replace it with, and how would
your new certificate structure satisfy those requirements to any
greater extent than do PKIX certs?

> BF:  Yes, Steve, and these legal issues go way beyond those related to a
> password (in part because now there are a whole bunch of additional entities
> involved).

You are postulating a large-scale general-purpose PKI, and then arguing
that the legal issues related to operating a PKI are caused by a set of
data structures defined in X.509/PKIX.  That does not address Steve's
point that if you are *not* using PKIX to implement a PKI (with support
for NR, archiving, etc), then these issues do not arise.

What if AOL issued X.509 certificates to all of its subscribers, and used
those certificates solely as a replacement for passwords: the identity
proofing is no more and no less than that required to get an AOL password
today; no third-party issuers; no PKIX-specific policy statements other
than statements which currently exist (acceptable-use, data privacy, etc).
Please explain why these PKIX AOL login certs become any more unmanageable
if the number of AOL subscribers grows from 100K to 5,000K?

---

From: "Flanigan, Bill" <[email-masked]>
Date: Tue, 20 Jul 1999 12:52:06 -0400

Comments to comments to comments in CAPITALS below.

> ----------
> From: 	David P. Kemp[SMTP:[email-masked]]
> Reply To: 	David P. Kemp
> Sent: 	Friday, July 16, 1999 11:05 AM
> To: 	[email-masked]
> Subject: 	RE: KISS for PKIX
> 
DAVE, I CAN'T THINK OF A SINGLE ISSUE--THEY SEEM TOO INTER-RELATED.

> replacement, would make any of these issues the slightest bit easier to
AGAIN, I CAN'T THINK OF A SINGLE MODIFICATION THAT WOULD DO IT, BUT I
CAN--IF YOU FORCE ME TO-- THINK OF POTENTIAL REPLACEMENT CANDIDATES.  A
COMPLETE OVERHAUL IS WAY BEYOND THE SCOPE OF THIS THREAD--SO FAR.
PKIX/X.509 IS SORT OF LIKE *HIGH DEFINITION* TELEVISION.  ITS BEEN AROUND
(OR JUST AROUND THE CORNER) FOR QUITE A WHILE; LOOKS BETTER (EVEN THE
LOW-DEFINITION VERSION) THAN WHAT WE HAVE NOW; BUT IT WILL BE YEARS BEFORE
WE WILL HAVE IT FULLY AVAILABLE AND CAN AFFORD IT.  IN THE MEANTIME, THERE
IS THIS *HDTV VACUUM.*  AND WE ALL KNOW ABOUT NATURE AND VACUUMS.

> greater extent than do PKIX certs?
I THINK I'VE OUTLINED SOME OF THE *BUSINESS REQUIREMENTS* ALREADY.  I DON'T
HAVE A NEW CERT STRUCTURE PER SE.  STILL HOPING THAT PKIX/X.509 CAN BE MADE
SIMPLER SO THAT THE *I* IN PKI CAN BE TAMED BEFORE IT DEVOURS ALL RESOURCES
ON THE PLANET!  DAVE, IT'S FOLKS LIKE YOU WHO CAN HELP MAKE THIS
SIMPLIFICATION HAPPEN--IF YOU SO DESIRE. 

> data structures defined in X.509/PKIX.
> 
THESE *DATA STRUCTURES* ARE NOT HELPING TO IMPLEMENT BEYOND THE PILOT/DEMO
STAGE.  JUST LIKE HDTV--THE INFRASTRUCTURE NEEDED TO SUPPORT IT MAY RESULT
IN SELF-IMPOSED EXTINCTION.

> That does not address Steve's
WELL IF I AM NOT, LET ME TRY IT AGAIN:  QUITE SO.

> if the number of AOL subscribers grows from 100K to 5,000K?
HMM, YOU'VE LOST ME HERE, DAVE.  I HAVE NO IDEA HOW AOL OPERATES.  BUT IF A
CERT IS USED SOLELY AS A REPLACEMENT FOR A PASSWORD, WHY BOTHER?  (YOU WOULD
PROBABLY HAVE TO TYPE IN A PASSWORD ANYWAY TO ACCESS THE CERT IN THE CLIENT
(OR TOKEN) AND ENABLE IT TO BE SENT TO THE SERVER.)  THIS SEEMS TO ME TO BE
A NEXT-TO-ZERO LEVEL OF ASSURANCE, WHICH IS NOT, I HOPE, WHAT PKIX IS ABOUT.
(WHY USE HDTV TO VIEW TRANSPARENCIES MEANT TO BE USED WITH A MAGIC LANTERN?)
AGAIN, DAVE, IT'S SMART FOLKS LIKE YOURSELF WHO CAN HELP MAKE THE *RIGHT*
MODIFICATIONS OR ENGINEER AN OVERHAUL/
REPLACEMENT AND THEREBY GREATLY AID EARLY (AND LATER?) ADOPTERS.  ONE WAY OR
THE OTHER, I FEEL THAT THIS *CHASM OF COMPLEXITY* BETWEEN PROTOCOL
DEVELOPERS AND ADOPTERS MUST BE BRIDGED FOR PKIX/X.509 TO BECOME THE PKI
FLAVOR OF CHOICE FOR THE PLANET.

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 20 Jul 1999 10:24:17 -0700

>IS THIS *HDTV VACUUM.*  AND WE ALL KNOW ABOUT NATURE AND VACUUMS.

Thanks Bill.  This is a good analogy.

Another is the market for video game machines.  Long dominated by the lesser-
powered Super Nintendo (16-bit) and Playstation, along comes a far more powerful
graphics/game machine (3DO or something) touted to blow everyone away.  The only
problem:  It was so complicated and unfriendly for developers to program on, and
so expensive to purchase, only a very few games were ever made for it.  R.I.P.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 20 Jul 1999 13:49:32 -0400 (EDT)

No, the U.S. DoD would not contract or delegate its message
authentication services to another country, although it may choose to
accept another country's authentication of that country's personnel.
DoD policy is made at a high, centralized, level and communicated to
the end applications through the use of certificates.  The end
applications are responsible for policy enforcement (displaying "OK" or
"Not Authenticated" or "Not Authorized" to the user on a per-message
basis), and I don't see how this function could possibly be made to
work using an account database and certificate-less PKI.  Certificates
allow users to be aggregated (by nationality, by clearance, by explicit
privilege, etc) and allow decisions to be made on a distributed basis
without distributing the account record for every user to every
application.  Banks are free to assume that their central servers are
100% available.  The DoD does not have that luxury - operations must
continue among peers (full mode, not a degraded disconnected mode) even
if a centralized server or the pipes to it become unavailable.

  "Everything should be made as simple as possible,
     and no simpler."
                         -- Albert Einstein

> From: [email-masked]
> 
> re: authorization/authentication seperation
> 
> this is not in terms of technolgy or security seperation ... this is in terms of
> business interest seperation .... i.e. would the US dod contract to a another
> contry's  military organization to do the preliminary authentication on all US
> military SBU and top secret messages ... allowing them to  decide which messages
> are flagged as correctly authenticated and which message are flagged as
> non-authenticated??? this is further exasberated by the fact the US
> would be in direct conflict with with the country that has the military
> organization that has been selected to preprocess and authenticate US military
> traffic on behalf ot the US military.
> 
> There is all sorts of opportunity for fraud when the business interests of the
> organization doing authentication is in conflict with the business interests of
> the organization authorizing and executing the transactions.
> 
> one of the reasons for reg. E is that it is readily recognized that the merchant
> interests and the consumer interests do not coincide 100% ... furthermore ...
> merchant banks representing merchants and consumer banks representing consumers
> ... are also representing conflicting interests.

---

From: "Flanigan, Bill" <[email-masked]>
Date: Tue, 20 Jul 1999 15:00:46 -0400

> Sent: 	Tuesday, July 20, 1999 1:49 PM
> To: 	[email-masked]
> Subject: 	Re: KISS for PKIX
> 
[snip]

> Certificates
> privilege, etc) 
Dave,

	Interesting.  Which PKIX/X.509 extensions do you recommend for these
attributes?  Especially for "nationality".

Bill

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 20 Jul 1999 16:27:22 -0400 (EDT)

Russ Housley already provided an answer to this, under the message
thread "Showing Nationality in Cert".  I agree with Russ' answer:

  > I recommend SubjectDirectoryAttribute.
  >
  > Russ

as amplified by Bill Burr (the SDN.801 'prbacInfo' attribute for
structured privileges) and Sandi Miklos (the ACP133 'nationality'
attribute for nationality). See:
  http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html
  http://csrc.nist.gov/pki/twg/dir_docs/ACP133.zip

I would also quote from The Open Group's proposed authorization API:

     4.2 Authorization Credentials
   
     ... We understand that a standardized credential format is on
     the most wanted list of many vendors, organizations, and end users.
     However, even though intimately connected to the actual implementation
     of the decision functions, we believe that we can hide the internal
     credentials structure from the calling resource manager.

which suggests that in the absence of an International Standard or
IETF-standard credential structure, the best that we can hope for
is that commercial applications will be written to a standardized API,
enabling the use of authorization plug-ins to handle community-specific
credential formats.

Does anyone believe that the IETF can or should standardize an
authorization credential format?

---

From: [email-masked]
Date: Mon, 26 Jul 1999 11:14:51 -0700

while DOD doesn't have that luxary ... and may have lots of infrastructures that
require distributed ... and effectively self-describing and self-authenticating
credentials ... most service providers ... including banks, internet service
providers and other types of businesses do hit account records as integral to
service provision ... and as such self-describing and self-authenticating
credentials can be viewed as superfulous and redundant.

---

From: [email-masked]
Date: Mon, 26 Jul 1999 11:10:18 -0700

HMM, YOU'VE LOST ME HERE, DAVE.  I HAVE NO IDEA HOW AOL OPERATES.  BUT IF A CERT
IS USED SOLELY AS A REPLACEMENT FOR A PASSWORD, WHY BOTHER?  (YOU WOULD PROBABLY
HAVE TO TYPE IN A PASSWORD ANYWAY TO ACCESS THE CERT IN THE CLIENT (OR TOKEN)
AND ENABLE IT TO BE SENT TO THE SERVER.)  THIS SEEMS TO ME TO BE A NEXT-TO-ZERO
LEVEL OF ASSURANCE, WHICH IS NOT, I HOPE, WHAT PKIX IS ABOUT (WHY USE HDTV TO
VIEW TRANSPARENCIES MEANT TO BE USED WITH A MAGIC LANTERN?) AGAIN, DAVE, IT'S
SMART FOLKS LIKE YOURSELF WHO CAN HELP MAKE THE *RIGHT* MODIFICATIONS OR
ENGINEER AN OVERHAUL/ REPLACEMENT AND THEREBY GREATLY AID EARLY (AND LATER?)
ADOPTERS.  ONE WAY OR THE OTHER, I FEEL THAT THIS *CHASM OF COMPLEXITY* BETWEEN
PROTOCOL DEVELOPERS AND ADOPTERS MUST BE BRIDGED FOR PKIX/X.509 TO BECOME THE
PKI FLAVOR OF CHOICE FOR THE PLANET.

........................................................................................................................................................................

password is shared secret .... shared with the organization that is
authenticating you.

digital signature ... & public key in place of password has lots of appeal ...
especially
coupled with hardware token (applies to both CADS and AADS implemenations)

even if the hardware token is pin/password protected ... current password
compromise
can be done in number of ways (thru the network, social engineering, etc)  ...
and then just knowing the password, compromises the integrity of the service. In
the hardware token case, service
is only compromised if the hardware token is also stolen (something you have and
something
you know).

at recent presenation there were claims that password exploits were trivial in
great majority of cases because either 1) person used same password for all
their services (security exposure in itself) or 2) used all different passwords
... but had to write them all down and keep them in convenient place.

If #1 ... do various knowledge guessing &/or go after one of the lower security
systems to
 gather a copy and then exploit all systems

if #2 ... hire janitors to search in & around keyboards for password list.

integrity of hardware token is such that it is realistic to use same hardware
token for multiplicity of authentication purposes.

---

From: "Miklos, Sue A." <[email-masked]>
Date: Tue, 27 Jul 1999 08:23:38 -0400

Dave, 

I believe that there is reference to the 'clearance' attribute ('97 X.501)
in the Attribute certificates w/TLS work.  Note that the clearance attribute
is one of three critical security information objects associated with prbac
(essLabel and security policy info. file being the other two critical SIOs).

My suggestion for the use of the nationality attribute was ONLY in the event
that the granularity of access control is constrained to a nationality,
which is not the most common event in the military community.

Sandi

---

From: "Aram Perez" <[email-masked]>
Date: Tue, 27 Jul 1999 08:51:24 -0700

[snip]
> (OR TOKEN) AND ENABLE IT TO BE SENT TO THE SERVER.)

There are many reasons why using certificates are better than passwords. In
case of AOL, since they are an "open system" providing thousands of access
points, they are subject to thousands of simultaneous password attacks.
Whereas, if I have a password to protect the private key that corresponds to
my AOL certificate, the attacker would have to have access to my private key
storage medium (which is generally NOT an "open system").

[snip]

Regards,
Aram Perez