Subject: RE: KISS for PKIX

From: "Flanigan, Bill" <[email-masked]>
Date: Fri, 16 Jul 1999 09:06:15 -0400

Eric, if I may jump in here:  Steve, please see my "BF:" inline comments
below.

Best regards,
Bill

> ----------
> From: 	Stephen Kent[SMTP:[email-masked]]
> Sent: 	Friday, July 16, 1999 3:04 AM
> To: 	[email-masked]
> Cc: 	[email-masked]'
> Subject: 	Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE:
> I-D 	 ACTION :draft-ietf-pkix-scvp- 00.txt))
> 
> Eric,
> 
> >I couldn't agree with you more. However, regarding acceptance of PKI
> >technologies by large organizations, I believe there are many reasons
> >organizations are not adopting PKI readily besides ease-of-use issues.
> Nor
> >does it have anything to do with ASN.1 vs XML. This issue can't be
> resolved
> >with technology solutions because their lack of acceptance is not due
> >solely to technical problems.
> >
> >The problems with PKI are numerous, from a corporate perspective, and
> many
> >large organizations have not moved initial PKI efforts beyond the
> >pilot/evaluation stage. Problems include outstanding legal liability
> >issues, the lack of fraud protection laws, the need to address cessation
> of
> >activites of a CA and/or a registry, the inability to bind a certificate
> >distinctly to a user (software certificates identify systems, not users),
> >the inability of an issuer to associate a security policy with the
> >certificate (issuers need to be able to dictate when to allow caching of
> >passwords,as well as things like session timeout and password
> construction
> >rules), undefined procedures and products to support records management
> and
> >archiving, as well as that non-repudiation claims for current PKI
> products
> >may have no legal basis. Then there are all the technical problems.
> 
> 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!

>  However, use of a PKI to support SSL, IPsec, and S/MIME
> (at least on an intranet basis) does not raise such issues, yet promises
> to
> improve security and to make life easier for users.
> 
BF:  Whether the nonRepudiation bit is set is irrelevant from a legal
perspective (e.g., check out the POV of S&T Subcommittee of the ABA plus
what the States' attorneys and courts have been doing recently).

> I disagree with your statement that a certificate in software binds a
> system, vs. a user.  Yes, smart cards are preferable, but if the choice is
> between a password and a certificate (and private key) with software
> cryptography, I see no reason not to adopt the latter, and I certainly see
> no reason to declare that the latter is not a user (vs. system)
> authentication mechanism.
> 
BF:  Not only do you have to physically protect the .p12 file on the floppy,
you have to protect it from the OS(s), repeatedly.

>   Finally, why do you say that an issuer cann
> associate a security policy with a certificate?  We have the syntactic
> means to do so as part of the standard.  Do you mean that we don't have
> appplications that pay attention to the policy extension?
> 
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).

> Steve
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).

---

From: Stephen Kent <[email-masked]>
Date: Sat, 17 Jul 1999 14:22:31 -0400

Bill,

>lawyers on the planet to support all these up-and-coming PKI!

In an intranet context, with certs used for authentication, and the
organization acting as RA and CA, I don't believe that any of these legal
issues apply.  Some may apply when one outsources the CA function, and even
more if one outsources the RA function, but that was not the example I was
trying to illustrate.

>what the States' attorneys and courts have been doing recently).

One might make a stronger assertion re certificate use and NR through a
cert policy ID, but until a trial takes place, no one of really know.

>you have to protect it from the OS(s), repeatedly.

True, but it's secure from guessing attacks whereas most passwords are not.
Trojan Horse attacks that can grab the encrypted private key file and
extract my key are also capable of grabbing passwords too, so I stand by my
assertion.

>where policy mapping is a MUST).

Many folks in the community make a strong distinction between a CA policy
and a CPS.  However, I agree that few users will read a CP, just like none
of us read the fine print on our rental car contracts, credti card
agreements, etc.  We still manage to get along.

>flavor of choice for the planet, it must be substantially overhauled (or

Sorry you feel that way.  What's your proposed alternative?  Why not
contribute more to the PKIX activities to address the concerns you have?

Steve