Subject: RE: New Extension Proposed: Method Of Authentication

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Sep 1998 13:44:32 -0400

The subscriber authentication at the various stages (such as initial
registration, registration after revocation, revocation request, normal
rekey, etc.) is supposed to be described in the certificate policy.
Thus, the certificate policy asserted points to the authentication
method.

There is NO need for another extension.

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Wednesday, September 09, 1998 1:16 PM
> To:	Mike Smith; [email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: New Extension Proposed: Method Of Authentication
> 
> > In using certificates, it is useful to know what form of 
> > authentication is used by a CA to identify a new certificate 
> > requester.  A certificate extension seems the best place to store 
> > this information.
> 
> This sounds to me like a trip into a quagmire. I don't think that
> it is possible to charaterize authentication mechanisms usefully
> in a set of binary flags.
> 
> For example two CAs may be requiring presentation of a driving
> license for authentication, only one CA may be using a state of
> MA license with photo ID and another a UK driving license without
> photo ID.
> 
> Even with documents such as passports there is considerable 
> variation between countries in the strictness of their proceedures.
> 
> Then there are proceedural variations, is the applicant present
> in person or were the credentials merely faxed...
> 
> 
> Nor is the mechanism of authentication by itself particularly 
> usefull unless there is an evaluation of the reliability of the
> party performing it. 
> 
> Of course one can start to characterise these characteristics
> as well but to do so merely throws up yet more information which
> might be relevant, factors which become increasingly subjective.
> 
> 
> This is a hard AI problem - establishing a shared vocabulary of
> terms which permits exchange of concepts whose semantics are
> not embedded in the communication mechanism or indeed any 
> mechanism for which a formal description is available.
> 
> 		Phill

---

From: Eric Murray <[email-masked]>
Date: Wed, 9 Sep 1998 12:24:18 -0700 (PDT)

> There is NO need for another extension.

I agree that putting the policy into an extension is a quagmire.

However, given that most CPSs will be on web sites, and those
CPSs can be changed at any time, should there be a way to
indicate which CPS is in effect at any given time during
the certificate's life?

Say Fred is issued a cert by Carl the CA.  Carl signs Fred's
cert under the then-current CPS 1.2, which required Carl
to verify Fred's identity using dental charts.   Sometime
later, Carl changes his CPS to version 1.3, which no longer requires
dental charts as a form of identification, but instead
accepts a state driver's license.

Fred would like to sign a contract to purchase a house.  The lender
requires a high-quality signature, and a cert with only a state
driver's license as identification isn't good enough.  How does Fred
indicate that his cert was issued under the older, more rigorous CPS?

One way to deal with this is to revoke all certs issued under a
given CPS when it is changed.  I'm not sure that that provides any assurance
that a given cert was issued under the current CPS though- a receiving
party would have to depend on the current CPS stating that such
is the policy.  And it's obviously very undesireable from a CA standpoint.

Another way would be to require the CA to sign their CPSs and include
version numbers, and to include in the cert extension which points to
the CPS, the version number of the CPS which was in effect when the cert
was issued.  This will prevent CAs from updating CPSs "out from
underneath" existing certs.  That may or may not be a desired effect.

I did a very quick read of the draft and didn't see anything that
handles this problem.  But I have not been following the discussion very
much and have not studied the draft, so I could well have missed it.  If
there's already something in the draft to deal with this, or this
subject has already been discussed on the list, please accept my
apologies.

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 09 Sep 1998 12:12:19 -0700

>Thus, the certificate policy asserted points to the authentication

True, but this certainly places a limit upon the degree of automation
that can be employed in the future, at least until we have software
that can read a CPS and base decisions upon it.  No time soon.

Granted, some 20 bits describing authentication method(s) would be
contentious, but the very exercise would reveal much about where and
how trust is really anchored, and the degree to which automated agents
could evolve.

>There is NO need for another extension.

Have enough work already? ;)

___tony___

>> mechanism for which a formal description is available.

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Wed, 9 Sep 1998 15:39:46 -0400

> Thus, the certificate policy asserted points to the authentication

True. What I interpreted the proposal to be however was an abstract
syntax for describing certificate policy in a form that would allow
automated evaluation. There is a big difference between putting a 
pointer to the certificate policy into a cert and attempting to encode 
the certificate policy within the certificate itself.

While such a facility would be 'nice to have' my experience is that
it is a very hard AI problem, at least as hard as the problem of
natural language understanding.

There is a project in the International Chamber of Commerce called 
ETerms which addresses the problem of providing a CPS repository
and which has as a long term goal the establishment of a shared
vocabulary of contract terms.

This enterprise is best described as 'chock full o' lawyers'. Many
of the issues being delt with involve subtle and obscure points
of international law - such as the fact that the criteria for
establishing constructive notice vary according to the jurisdiction.

Significantly the E-Terms project is not attempting to establish a
taxonomy of trade terms in common use. I don't think such a 'top
down' approach is feasible. Instead what is being attempted is a 
convergence of the user community towards the use of a common 
vocabulary which is itself a product of the process. This is more
of a bottom-up, evolutionary approach.

		Phill

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 09 Sep 1998 16:20:25 -0700

>natural language understanding.

Phill,

I do understand, and would expect any attempt to address the stated
shortcomings via an extension (or any other method) to be a multi-year
effort:)

There are two significant shortcomings with the existing situation,
nonetheless.  First, as pointed out by Eric Murray, is that this
"pointer to the certificate policy" is a weak link in a critical
chain to the foundation of trust.  I recall (two years ago!) this
very subject was debated on this list, with some calls to have the
cert contain a hash of the CPS in effect at the time of certificate
creation, so there could be no subtle (or not so subtle) rewording
of the CPS after the fact.  Alas, no such provisions were included.

Still, suppose the certificate did contain the CPS hash.  Imagine
that a client system, in the course of validating certificates,
determines that a particular CPS has changed.  That is, some of the
certs point to the older CPS, and some to a brand new CPS.  Assume
further that it can (securely) retrieve both the older and newer CPS
at will.  It can still validate the older certs, but it can do nothing
with the newer ones until a human steps in to read the new CPS, and
then determine its sufficiency for the purpose(s) at hand.

In terms of automation, "the bits stop here."

Its just an observation...

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL

---

From: Narayan Raghu <[email-masked]>
Date: Thu, 10 Sep 1998 12:27:57 +0530

Hello, 

Ultimately, it is the verifier of a certificate who decides if a
certification authority is to be trusted. Hence, the onus is on him to
verify the policies of the CA and decide whether to designate that CA as
the trusted root. 

IF a CA changes it's policy, it could simply generate another keypair,
which signes certificates verifed by the new method.  That way, the
verifier can decide whether to designate the new CA certificate as
trusted root or not, depending upon the new policy of the CA. The
verifier can thus choose to trust all those certified by the old CA
Certificate/Keypair, since the old policy was acceptable. 
The key here is that we link a new CA policy with a mandatory new CA
signing keypair.

I dont think it's required to mention the verifying method in the
certificate, since it's the certificate verifier's responsibility.

narayan 
ibm bangalore
india

Paul Hoffman / IMC wrote:
> 
> At 04:20 PM 9/9/98 -0700, Tony Bartoletti wrote:
> >chain to the foundation of trust.
> 
> Then don't validate certs with CPSs; only validate ones with OIDs that
> you
> understand.
> 
> Remember, these policies are for CAs who you have already decided you
> trust
> to sign someone else's key. If you don't trust them not to change
> their
> CPS, why do you trust that they are even following the CPS you looked
> up
> once? Any reasonable CA who changes their CPS will keep the old one at
> the
> original URL and create a new CPS with a new URL, and put the new URL
> in
> certs that conform to the new policy.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 Sep 1998 14:53:26 -0700

> indicate that his cert was issued under the older, more rigorous CPS?

You are adressing an important issue. When you sign a contract, you
usually look at the back of the page where there is either the full
terms of the contract or a short form of them with a pointer to a full
form. It is thus important to know whether you agree or not with these:
if yes, you sign, if not you don't. 

The equivalent in electronic terms is to point to a security policy and
sign it (i.e. add the security policy to the core of the signed message
and sign the whole). Different pointers may be used. Here are two
examples: an OID, a URL address. If the policy changes, the pointer must
change. A hash of the policy has to be used to make sure which terms you
were agreeing with. 

These terms will indicate which CAs are adequate to be used by the
signers and which security policies from that CA will be adequate to be
used, relative to these terms.

> is the policy.  And it's obviously very undesireable from a CA standpoint.

Indeed !

> underneath" existing certs.  That may or may not be a desired effect.

:-(

> subject has already been discussed on the list, please accept my

You did not missed it, the draft is silent on this kind of topic, but it
would not be the right place anyway to place it. At the Chicago meeting,
we talked about expanding the work to handle non repudiation in more
details. If such an extension of the work happens, then we could
possibly deal with this kind of topic.

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

---

From: Paul Koning <[email-masked]>
Date: Thu, 10 Sep 1998 09:21:30 -0400

>>>>> "Tony" == Tony Bartoletti <[email-masked]> writes:
>...
 Tony> Still, suppose the certificate did contain the CPS hash.
 Tony> Imagine that a client system, in the course of validating
 Tony> certificates, determines that a particular CPS has changed.
 Tony> That is, some of the certs point to the older CPS, and some to
 Tony> a brand new CPS.  Assume further that it can (securely)
 Tony> retrieve both the older and newer CPS at will.  It can still
 Tony> validate the older certs, but it can do nothing with the newer
 Tony> ones until a human steps in to read the new CPS, and then
 Tony> determine its sufficiency for the purpose(s) at hand.

 Tony> In terms of automation, "the bits stop here."

I think that's as it should be.  Whether a new CPS is sufficient for
the purposes at hand, in any situation where someone cares enough to
look at the CPS at all, is a question that undoubtedly involves
lawyers, or even people involved in still less formal processes.

Until and unless someone comes up with a mapping from legal english to 
formal logic (unlikely given Goedel's theorem) I believe the bits HAVE 
to stop where you said.

Incidentally, as an aside -- this discussion made me worry about the
potential for unrestrained growth of certificates.  As someone
involved in building diskless (embedded) systems, megabyte-sized certs 
worry me a lot.

	paul

---

From: Eric Murray <[email-masked]>
Date: Thu, 10 Sep 1998 08:19:49 -0700 (PDT)

> involved in building diskless (embedded) systems, megabyte-sized certs 

Me too.  Our company also does embedded systems which need to
accept and verify certs.
Please keep your certs small if you really want
them to be ubiquitous.  I'd much rather see a URI and perhaps
a hash in the cert instead of the entire CPS.