Subject: RE: RE: New Extension Proposed: Method O

From: Graham Bland <[email-masked]>
Date: Fri, 11 Sep 1998 8:49:49 +0000

I think this is impossible to achieve for the following reasons

1. 255 categories would be far too few, in practice they would expand to 
thousands.

2. With each category there are wide variations, drivers licences for example 
contain different details, have different validity periods, some have photos, 
some don't and they are issued by Governments (some of whom I would not 
trust). Are photocopies acceptable? Must the driving licence be presented in 
person or can it be posted? Need it be current?  All these have a substantial 
bearing on the degree of trust I can place in a certificate.

3. It would take us years to agree on the categories and the meanings

For these reasons this could not replace a CPS.

Graham Bland

> -----Original Message-----
> From: [email-masked]
> Sent: 10 September 1998 18:06
> To: Ian Roberts; Graham Bland; Chris Wright; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: RE: New Extension Proposed: Method O
>
>
> --------------------------------------------------------------
> --------------
> Maybe "new" extension is too strong a phrase.  How about
> defining the policy
> qulifiers to have some standard" meanings, then:
>
>    reliance limit
>    licensure, licensing body
>    authentication method
>    etc.
>
> If we have standard identifiers, one byte each, provides 0 to
> 255 specific
> categories, with say, ten as internet standards.
>
> With initial authentication method, maybe we start with (decimal):
>     0 as anonymous,
>     1 as self-authenticated,
>     2 as driver license or government ID card
>     3 as passport
>     4 as military
>
> then start with combinations including common attributes,
> such as credit
> bureau rating as of issuance, etc.
>
> I do understand that, while policy OIDs may be supported some largely
> deployed systems do not support the policy qualifiers, but
> the standards do,
> so why don't we use them to improve our automation needs.
> Any time we need
> to rely on individ
> uals obtaining, reading and being held accountable to a two
> hundred page
> contract (CPS), we limit its usability.
>
> Having standard definitions for the most common usages and
> having these
> signed as part of the cert by the issuer should facilitate
> automatic policy
> acceptance across those domains with multiple policies (if I
> have accepted
> all of the Verisig
> n roots, then all of the categories of authentication are
> accepted.  If each
> cert has the main characteristics of trust (initial authentication, CA
> licensure, reliance liits, CPS location/OID, etc.), then I
> should be able to
> set my acceptanc
> e on user selected criteria,
> without re-reading the two hundred pages of each of the CAs
> my company does
> business with.
>
> Michael
>
> >>> Santosh Chokhani <[email-masked]> 09/09 1:25 PM >>>
> The certificate policy is supposed to the represented in the
> certificate
> as an object identifier.  The amendment to X.509 defines how the
> applications process that field to determine if a certificate is
> acceptable, including certificate policy and associated authentication
> mechanism.
>
> X.509 amendment offer a rich set of capabilities in this area in terms
> of what goes in a certificate, and how applications perform path
> validation.
>
> > -----Original Message-----
> > From: Tony Bartoletti [SMTP:[email-masked]]
> > Sent: Wednesday, September 09, 1998 3:12 PM
> > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith;
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: New Extension Proposed: Method Of Authentication
> >
> > At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote:
> > >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.
> >
> > 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___
> >
> > >> -----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
> > >
> > >
> >
> > 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      !
>
>
>
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com