Subject: Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

From: [email-masked]
Date: Fri, 16 Jul 1999 13:28:28 -0400

There are legal issues to be resolved regarding limitations of liability
and responsibilities of issuers, certificate authorities, subscribers, and
relying parties. There are legal issues to be resolved regarding digital
signatures. Last time I checked, about thirty states had enacted or were in
the process of enacting digital signature laws. The federal government has
a digital signature law pending. I was not basing my comment solely on
legal issues regarding authentication of users. What is the limitation of
liability of an issuer when a third party effects a transaction based on a
certificate the issuer has issued, after the subscriber repudiates the
transaction? What if all three parties are in three different states or,
worse, countries? Whose law applies? What happens when a CA closes shop?
Are the certificates valid or invalid? Who will relying parties consult if
they need to verify that a certificate issued by the defunct CA was valid
at a previous point in time for a disputed transaction? For how many years
must a CA keep expired certificates? What responsibility does a CA have for
providing for cessation of activities?

I initially was led to believe PKI supported non-repudiation because this
was one of the claims being made for it by its proponents. It was only
after I started examining it more closely that I realized the claims were
unsubstantiated. As long as one party can reasonably deny a fact, it is up
to the other party to prove otherwise. If I receive a transaction and act
on it, and the initiator subsequently denies the transaction, what do I
have to authenticate the user and the data? I can't claim in court that I
received and acted on a message because my server accepted it since it came
with a valid certificate,  and because the signature and the message digest
were valid, based on the certificate. I need to to be able to produce the
original message, the digest, the signature, and the certificate, and be
able to show that the validity checks all passed. I also need to know what
algoritms were used. I need logs and audit records to prove the transaction
came in. And I need all this possibly months or years later. But, most of
all, I need to be able to demonstrate that I based my decision on
reasonable assurance that the originator was who they claimed to be.

Which brings me to userids and passwords, and why I must use an application
password even if I have issued a certificate.  Passwords provide reasonable
assurance to me that the originator is who they say they are; as long as
the password is kept securely. Dynamic passwords (two-factor
authentication) provide even stronger assurance that this is so. What do I,
as a verifier, have when a certificate is used? I have no reasonable
assurance about the originator because I have not done anything to
authenticate them. I don't know how secure the originator's PC is. I don't
know if they have told the browser to cache the private key password, nor
the strength of it. I don't know if their PC will lock itself after a
certain amount of inactivity. I don't know who has access to the PC. It is
not difficult to copy certificate files from one system to another. If the
password is not strong enough, it probably would not be too difficult to
crack it. The certificate would be more reliable, for user authentication
purposes, if I, as an issuer, could control usage of the private key and
user authentication, or, minimally, if It is stored on some external
device. At least this provides two-factor authentication. I can't control
how software vendors utilize certificates in their browser products, but I
am at their mercy if I allow my application to run from their browser. If
risk assessment requires me to use password security anyway, I need to be
able to show significant incremental value added by certificates, given
that the certifcate process places a large administrative burden around all
this.

Granted, all this is less confusing if an originator is executing a
transaction with the issuer of the cetificate, because the issuer could
control the user authentication process. But it becomes more complex when
the certificate is used to execute a transaction with a third party. How
can a bank verify a certificate and, more importantly, vouch for a
transaction, if it can't be reasonably assured the customer is who they
claim to be? All it has is a request for validation from the third party
(merchant) and a message.

I am sure this will all be resolved over time, but at this point, I don't
feel we are close enough.
eric

Stephen Kent <[email-masked]> on 07/16/99 03:04:48 AM

To:   Eric Guerrino
cc:   "[email-masked]'" <[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))

Date: Fri, 16 Jul 1999 03:04:48 -0400
To: Eric_Guerrino@LNOTES5
From: Stephen Kent <[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))
Cc: "[email-masked]'" <[email-masked]>

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

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.  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?

Steve

---

From: Joe Tardo <[email-masked]>
Date: Fri, 16 Jul 1999 09:20:17 -0700

At 01:28 PM 7/16/99 -0400, [email-masked] wrote:

>a digital signature law pending.

Does anyone have the digital signature legislation URLs handy referencing
the latest on what the 30 states and Federal Government are enacting?

Thanks,
Joe

---

From: Stephen Kent <[email-masked]>
Date: Sat, 17 Jul 1999 15:01:55 -0400

Eric,

<snip>

>that the certifcate process places a large administrative burden around all

Passwords do not address the problem you claim, above, even though one may
argue that use of a password plus a certt adds some security to the user
authentication process.   But passwords are often guessable, and can be
compromised by the same sorts of attacks that can compromise private keys
stored on PCs, protected by a password.  So, the extent to which use of a
password increase the quality of authentication depends on a number of
factors, including the perceived threat. Yes, the preferable implementation
approach is use of a personal crypto engine token, e.g., a smart card or PC
card, which counters software-based attacks designed to extract private
keys.

I am not familiar with the phrase "dynamic passwords," in a technical
context.  Are you referring to use of hardware tokens like SecurID, used in
challange-response user authentication?  If so, then I agree that such
technology is a vast improvement over static passwords, but it is not
better than the use of certs protected by similar hardware technology,
e.g., smart cards or PC cards.  Depending on the threat model, and on the
rest of the security context on which they are employed, the relative
merits of user authentication tokens vs. certs based in software are
debatable.

Your criticism of certificates ("I have no reasonable assurance about the
originator because I have not done anything to authenticate them") seems to
assume a TTP model of issunace.  If an organization does its ownh
certificate issuance, this statement simply is not true.

>(merchant) and a message.

I think you are confusing cert validation with cert issuance assurance
procedures, etc.  Cert validation is an algorithmic process.  The level of
confidence one has that the holder of the corresponding private key is the
entity specified in the Subject field is a separate matter.

Steve

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 19 Jul 1999 11:39:08 -0500

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Saturday, July 17, 1999 2:02 PM
> To: [email-masked]
> Cc: [email-masked]'

> entity specified in the Subject field is a separate matter.

Commercial certificate validation is a risk-based procedure. It depends
on the risk associated with the accuracy of the status and compromise
data, the trustworthiness of the source of the status and
compromise information, the reliability of the inputs
on status and compromise, the security of the user
platform, and the appropriateness of the user's X.509
policy-configuration for the transaction type.

One can do issuer-independent "validation-reliance" velocity
measurements, much like the credit-card industry does for transaction
handling during credit-card validation, to manage the overall
risk curve for a community relying upon or merely using PKI
validation. Trusted commercial TTP networks have been doing
security validation for years, one can note, and have well
established procedures which transfer directly to
commercial-oriented PKI based on the network validation model.

Ed Gerck published seminal papers on this general
way of thinking, for PKI, a year or two ago.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jul 1999 14:53:53 -0400

Peter,

>commercial-oriented PKI based on the network validation model.

What you have described is a list of many of the factors that affect the
assurance of the cert validation process, as well as of the cert issuance
process.  I think it is useful to make the discintion that I did between
the algorithmic aspects of cert validation vs. the assurance that results
from the various factors cited above.  Hence I stand by my distinction. I
am not familar with Ed's papers on the topic, but I hope they don't cloud
the distinction cited here, as it is an important one.  Note that the scope
of PKIX is limited primarily to the protocols and algorithms used for
validation, as the assurance aspects of implementations, external
authentication procedures, etc.  Our one foray into the other arena, PKIX
Part 4, is an informational, not standards track, document.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 20 Jul 1999 11:50:59 -0700

[NOTE: some answers below are IMO indeed simple, which does not mean
that they are easy  -- it just means that they are already decidable.  The posting
is long in order to provide context.]

> a digital signature law pending.

There are some often neglected issues around this -- and which may simplify
very much what you are concerned about.

First, let me recall that the law (especially common law) is not very demanding
about what a "signature" is -- any scribble will do, usually, and also gestures can be
legally binding (think of an auction for example), as well as a simple statement such
as "OK, done!" if this is customary in the trade.  So, a "digital signature" can probably
enjoy considerable latitude and still be considered as a legal signature.  Where a
digital signature fails miserably, though, is in its absence of 'ceremony' (a legal
term that describes the formalities of signing a document) since no one can say
what happened over the wire, if the signer really read the document, if the document's
language was really understood, if there was really intent to sign, etc.

However, these problems were already encountered much before the Internet.
Indeed, the law already supports digital signatures in some countries that are based
on common law (UK for example), and many years ago, already.  Since telegraph
came around, and telex -- with the first needs to accept contractual agreements
over the wire.

So, new laws actually run into the danger of vacating previous laws and thus right
conflicts may easily ensue. Besides, as many new law proposals do in regard to
Internet matters do (e.g., the Utah digital signature law and the so-called
"Anti-cybersquatting law" being proposed in the US Senate), they usually run over
the requirements of due process in the good name of providing a remedy -- which
may create other problems (e.g., constitutional rights or simply lack of use; do you
know of any CA in Utah?) then the ones such laws try to solve .  For civil law
countries the situation may be somewhat less extensible, also because judicial decisions (jurisprudence) are not binding to lower courts in many such countries.

But, still, in any country (whether governed by common law or civil law, with possible
exceptions, also those governed by islamic law), a contract is the governing law
between the parties and they can tune it to their needs -- and, that is what contracts
are good for.  Thus, if a contract recognizes a digital signature as a signature, then the
law will very probably recognize it also as a signature (e.g., unless the contract itself is
legally invalid) -- including all cases that release the signer (use of deceit or unlawful
force being just two examples).

So, yes, this is simpler than it might seem at first sight. Digital signatures such as provided
by X.509 or PKIX can be legally used already today and in almost all countries -- as they
are -- but much will depend on the contract between the parties, which is IMO a good
thing since the technology is new and one needs to empower the users to choose what
they are already willing to accept for each case and risk.  In some states (e.g., California)
there are legal restrictions being enacted in this area which will further empower users.
Thus, this may well be a trend towards more user's rights to choose what technology
they are willing to use -- where digital cannot be the only choice.

> I was not basing my comment solely on
> transaction?

This is simple -- and all commercial CAs have answered this. As given by their CPS,
which is included by reference in the contract.  This is not like the famous case of the
Carbolic Ball Company, when liability was assumed at large. This is also not like a
check warranty, where the bank warrants the check to a certain  amount to any
recipient. This is a case where all liability at large is specifically denied and also
rendered legally unreachable even under third-party rights or consumer laws -- for the
simple and effective reason that all content is denied since a certificate is supplied 'as is',
which in UK law is called "endorsement sans recourse" and carries no liability at all.
This is a case where the CA  CPS is also supported by the Uniform Commercial
Code (US), which  declares that suppliers of data processing service are not liable
for providing incorrect results but just for using incorrect methods.  And this is where
Internet standards such as X.509 or PKIX are dearly useful to CAs, because such
standards provide the metric  for "correct methods" and thus free whomever uses
them  (e.g., CAs) from any liability stemming from the method's eventual design
problems and flaws -- hence some of the intrinsic tension in these debates.

> What if all three parties are in three different states or,
> worse, countries? Whose law applies?

This is simple. Any court can decide if jurisdiction applies -- this is not something
that the defendant, you or me can decide.  Thus, a Canadian company can be sued
in the US even if it has no branch office in the US. This is very common in  Europe
and a related case in the UK (involving a "telex signature") for a contract between
a company in the UK and another in Switzerland also dealt with the case of
different time zones to decide when a contract starts to be effective -- a question also
often neglected in regard to digital signatures.

And, even though three different countries may indeed be involved, this is also not
unusual in today's global economy.  Again, using an example from Europe, a resident
of Germany driving a car rent in  Spain but now on a road in France, hits a truck registered
in Italy but driven by a Belgian (who has an insurance from a Belgium company) due
to a  road defect. Who pays what? Who sues whom? Where? Each party decides
and the courts verify jurisdiction.

> What happens when a CA closes shop?

This is simple. Law already defines, for each country, what are the business
responsibilities -- and this is another issue where "Internet rules" seem to desire
to run over law  (e.g., as ICANN that wishes to define what happens if a TLD
registrar closes shop, but, unfortunately seems to open more cans of worms than the
one it wants to deal with).  What happens when a hospital closes shop?  Who is
responsible for post-surgery complications due to a fault caused by that hospital?
What happens when a plane manufacturer closes shop? Who is responsible for
the warranties and maintenance?  What happens when a bank closes shop? What
happens when a software company closes shop -- and, for example, you use
WordPerfect?

> Are the certificates valid or invalid?

This is simple.  They can be valid as long as the parties involved so decide.
The only needed functionality from the CA would be CRLs but since no CAs
warrant CRLs and no browsers consult them, this is anyway something that
the parties themselves had to deal with -- even when the CA was active.

> Who will relying parties consult if
> at a previous point in time for a disputed transaction?

This is simple. Themselves (e.g., by a suitable revocation policy they may agree upon
and that may include periodic reconfirmation for a next period of validity, possibly
also with insurance coverage according to their risks) or any third-party VA
(verification authority) that does not issue certificates but only serves as a type
of clearing house for certificates  (possibly, with the added benefit of insurance).

> For how many years
> must a CA keep expired certificates?

This is simple. Law already provides for this in each country.  For example, in
Germany, for at least 30 years.  The business responsibility of a CA goes over the
lifetime of  a certificate, and  for several reasons.  I have discussed this elsewhere
in the context of allowing e-commerce deals to outlive the certificate used to sign
them -- as they must in order to comply with sellers, bankers and consumer's rights,
warranty, etc.

> What responsibility does a CA have for

This is simple. As with any business, a CA can be terminated as the owners decide
or in cases provided by in law -- from whence different responsibilities also ensue for
each situation.

In this regard, there is IMO a very mistaken tendency of some "interest groups" in
the Internet, to consider the Internet as some sort of "public good"  that needs
special regulation or a division between "user" and "provider". The Internet is however,
not a public good (like a park or the radio wave space) -- the Internet is a network
of *private*  networks that willfully decide to collaborate, or not (in fact, there is value
in both behaviors; the first one in providing worldwide connectivity and the second
one in denying it for security purposes).  To better qualify  the issues at play here,
I quote a segment from another msg I wrote elsewhere:

--------------------------------------------------
The Internet is a global network of millions of private networks that voluntarily use
the Internet Protocol (IP) and the Transmission Control Protocol (TCP), or similar,
in order to support worldwide communication and services [cf. the “Internet” term
definition by the US Federal Network Council, in
http://www.fnc.gov/Internet_res.html].  The Internet is thus not a single entity but it
is a highly diffuse and complex system with many administrative and legal boundaries,
over which no entity has authority or control.  Further, on the Internet there is no
static division of roles between information providing and information accessing (as
in the case of TV, for example), so that anyone can become an information provider,
or access information, at any time – where either is called an “Internet user” or,
simply a “user”.

The Internet gives a user an open-ended worldwide audience, both in providing
content as well as in replying to queries – which are both qualified as an act of
providing “services”.   Services may also include sales, purchases, auctions or
any commercial activity including the sales of products to be physically and
non-physically (i.e., by the Internet itself) delivered.  The Internet does not
follow a “push” model in order to supply sales information (e.g., as radio, TV,
newspaper, mail lists, telemarketing calls, etc.), rather, it uses a “pull” model.
Once an Internet provider makes a service available on the Internet, it is
available to all Internet users worldwide and the provider cannot prevent that
service from entering (i.e., being “pulled by”) any community, jurisdiction or
country – i.e., the provider cannot prevent that information to be accessed by
a potential customer anywhere at anytime.
---------------------------------------------------

> was one of the claims being made for it by its proponents.

Yes, and in fact terminology has not been very precise in this regard. What many
considered "non-repudiation" was actually just "cooperative non-repudiation" in
which the signer itself declares it will not repudiate (e.g., PKIX itself has defined
a so-called "non-repudiation bit" for this purpose) -- but this works only if the signer
does not repudiate ;-) and ... if the signer is the signer, if the signer understood what
was being signed, and so on...

> It was only
> unsubstantiated.

They are, to a large extent. But, they do provide IMO for the needed
experimentation in order to allow at least some measure of non-repudiation
to be widely discussed and better understood (as we are doing, btw). And, it is
IMO one of the happy circumstances of this WG as well as other discussion
groups to bring these issues to the front.

Legally, anything can be repudiated -- but, technically, our task is to provide
evidences *both* ways: evidences to support non-repudiation and evidences to
support repudiation (even of an act that the other party may consider
non-repudiable).

> As long as one party can reasonably deny a fact, it is up

Yes, I agree with this. But in the majority of US states it can be much simpler --
in the case of  a tort there is no need to prove reasonable reliance but just
justified reliance.  The US Supreme Court has also decided that justified reliance
is the metric to be used for such cases.  The difference is that in justified reliance
(to give an example also cited by the US Supreme Court and cited in tort law), if
a seller tells me that a property is free to be bought, I do not need to check with
any notary even if checking with the notary is as easy as crossing the street.

> password even if I have issued a certificate.

Here, I disagree. These are two different authentication methods and there is as much
sense in requiring a certificate and a password as there is to require two passwords
or two certificates -- if done well it can provide for increased reliance or less risk, but
if not done well it can be actually worse.  But, there is no need.  Specially, to require a
password if a certificate is also required since a certificate provides more assurance
than a password -- and much more information (more on this, below).

> Passwords provide reasonable
> the password is kept securely.

 But you don't know that. And, in a channel that is either uncertified or unencrypted (i.e., it
needs to be both), a password can be easily snatched.

> Dynamic passwords (two-factor authentication) provide even stronger assurance
> that this is so.

I am not sure what you mean by "dynamic passwords" but if you mean the use of a
trusted third-party in order to provide passwords, this is worse for a series of reasons
similar to those that speak against private-key escrow.

> What do I, as a verifier, have when a certificate is used? I have no reasonable
> authenticate them.

This is not correct. You have a fresh challenge-response exchange and you have
the willingness of the other party to engage in such strong authentication. Besides,
you also have certification verification, both statically (issuer's signature) and
dynamically (validity, CRL). Further, you also have the certificate's usage policy (e.g.,
do not use above $ 50.00). And, there is much more -- you have the certificate's  issuance
date (i.e., how stale is it?), the issuer's name and issuance policy, subject contact data, etc.
Nothing of the sort is present in a password. And, last but not least, you expect the
corresponding certificate to have been accessed by a ... password.

> I don't know how secure the originator's PC is.

Ditto with a single password with no certificate.

> I don't know if they have told the browser to cache the private key password,

Ditto with a password  -- screen cache, additional software, password written on
the keyboard underside (very common), password written in a post-it note on the
display, password written in a file called "password.txt", etc.

> nor the strength of it.

Ditto with a single password with no certificate.

> I don't know if their PC will lock itself after a
> certain amount of inactivity.

Ditto with a single password with no certificate.

> I don't know who has access to the PC.

Ditto with a single password with no certificate.

> It is not difficult to copy certificate files from one system to another.

Ditto with a single password with no certificate.

> If the password is not strong enough, it probably would not be too difficult to
> crack it.

Ditto with a single password with no certificate.

> The certificate would be more reliable, for user authentication
> device.

No, it would not. This would be "private-key escrow" and there is already IMO
wide consensus (even among its original proponents) that it creates far more
problems than the few it perhaps solves.  For example, you would still have
unsecured access of the key owner to that external device, collusion problems
to solve, privacy concerns, etc.

> At least this provides two-factor authentication.

No, it does not.  It is actually "a bad idea" (as commented above)

> I can't control

Agreed, and this is what I commented before -- security is counter to functionality.
Indeed, users can accept the hassle of more security but this depends a lot on
what this extra burden will provide as a benefit.  But, usually, if there is any problem
coping with the added procedures (or, a software/certificate glitch that renders it
unusable) I would expect the vast majority of users to revert to less secure methods
in order to close a deal -- which might be well exploited by an attacker that does a
denial-of-service attack on the secure server in order to lure the user into a weaker
authentication procedure.

> control the user authentication process.

Yes.

> But it becomes more complex when
> claim to be?

I disagree in this case -- since this case can easily be the case where the bank
itself is the issuer, which you also agree is "less confusing" (just above).  This,
for the bank, is not very much different from giving the customer a check guarantee
card and checks -- for which use the customer is responsible and liable, and which
banks do all the time.

The main difference here is that the bank is of course privy to the contract with
the user, which does not happen if the user certificate were issued by a third-party.

> All it has is a request for validation from the third party

As above, not so -- the bank has a contract with the user.

> feel we are close enough.

Perhaps it is closer in some points, and farther in others, as I commented before.
But, there is no way to move ahead than to experiment and to provide room for
interdisciplinary discussions.

What is lacking though (and this is my motivation) are engineering models that
would make Internet certification and security development less of a happenstance
search as it is mostly done today, where YAPKIs (Yet Another PKI) upon YAPKIs
are proposed out of older network security models (that do not apply to the Internet,
which is a network of networks).

IMO, and as exemplified in other cases in the Internet such as the current domain
name issues, it is clear that there is also a tension between "legal effectiveness" and
"technical effectiveness" that makes any current solution not very satisfactory
when viewed under a balanced perspective.

Thus, it is also a happy objective of these discussions, with examples and
counterexamples, to help discern where the differences are and where
new solutions might be found. Which will, necessarily IMO, involve
compromises and a middle ground (e.g., between the currently prevailing CA
perspective versus relying-party's needs in regard to PKI) in  order to even
begin to find solutions.  For example, with a verifier-centric PKI.

Where, likewise, to learn to respect the diversity of opinions is IMO
the first rule to be followed by those that want to use debates and
public discussions as useful tools to mine the gold of truth.

Cheers,

Ed Gerck