Subject: New Extension Proposed: Method Of Authentication

From: Mike Smith <[email-masked]>
Date: Wed, 09 Sep 1998 10:03:36 -0600

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.

At one time, Bob Jeuneman prepared a paper proposing this extension and detailing many categories, from anonymous, self-authenticated, self authenticated with data verifired (or with credit account, etc.), authenticated in person, in person with governement-issued picture ID, multiple forms of government picture IDs with current credit reports and corporate D&B, etc.

The current practice, I beleive, is to embed the authentication mechanism in a CA operations or policy statement tha may or may not be online for someone to peruse and make their own judgement.  Putting a clear indicator in the signed cert would help.

Comments?  Bob?

Michael

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 09 Sep 1998 09:36:53 -0700

It seems to me that the certificate policies (section 4.2.1.5) is still the
proper place for this. If we create a set of bits that says how the CA is
authenticating, unless the statement in the new bits is *exactly* what the
CA is using, they should not commit to those bits because someone later can
say "but you said you were doing such-and-so". The CPS is under their control.

Can you be specific about the advantage of what you are proposing versus
the certificate policy?

--Paul Hoffman, Director
--Internet Mail Consortium

---

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

> 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: Denis Pinkas <[email-masked]>
Date: Thu, 10 Sep 1998 14:25:40 -0700

Mike Smith wrote:
> At one time, Bob Jeuneman prepared a paper proposing this extension 
> and detailing many categories, from anonymous, self-authenticated, 
> self authenticated with data verifired (or with credit account, etc.),
> authenticated in person, in person with governement-issued picture ID, 
> multiple forms of government picture IDs with current credit reports 
> and corporate D&B, etc.
 
> The current practice, I beleive, is to embed the authentication 
> mechanism in a CA operations or policy statement tha may or may not 
> be online for someone to peruse and make their own judgement.  
> Putting a clear indicator in the signed cert would help.
 
> Comments?  Bob?

If we were going in that direction then we might need to indicate
whether one or more of the following has been presented: a driving
license, a passport, an ID card, a bill from an Electricity supplier, a
bill from a Telephone company, a bill from a Water supplier, etc ... We
already have (too) many extensions. The policy statement is enough.
There is no need for a verifier to understand the details of the policy,
but only to know whether the policy is acceptable for the application. 

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