Subject: RE: New Extension Proposed: Method Of Authentication

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Sep 1998 15:25:47 -0400

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

---

From: "Fillingham, David W." <[email-masked]>
Date: Wed, 9 Sep 1998 15:44:32 -0400

Tony:

I agree with Santosh and Phillip on this matter - I don't think an
additional extension would help.

The method of verifying a subscriber's identity is one element of a
certificate policy that factors in the assurance of the binding between
an identity and a public key - but only one.  It seems we could go down
a path of defining another extension for liability limits, which may be
more important to many users, and another for technical security
mechanisms (e.g., is the private key protected using hardware, or
software), and another for "authorized certificate applications" (e.g.,
only good for Company X applications) and so on.

I see no need to automatically read CPS documents - X.509 already
specifies how the certificate policy extension should be processed.  If
a policy, including the subscriber I&A process, is acceptable to a
relying party for a specific application, then the certificate
processing application can accept the certificate asserting that policy.
 Some human being reads the policy, and makes this determination, based
on the entire policy, and then asserts the policy as one that is
"acceptable" for the application.  

If a public key system implementor wants to define a certificate policy
based exclusively on the initial subscriber registration identification
mechanism, they could do so.  I don't think this would be a good idea,
but it's certainly allowed by the standards, including the IETF
Certificate Policy and CPS Framework, and to my mind, is preferable to
defining another extension.

Dave Fillingham

>----------
>From: 	Tony Bartoletti[SMTP:[email-masked]]
>>registration, registration after revocation, revocation request, normal

---

From: "Fillingham, David W." <[email-masked]>
Date: Thu, 10 Sep 1998 15:21:09 -0400

I agree with Phillip.

My folder containing the debate on the meaning of the non-repudiation
key usage bit contains 97 messages from people trying to define what
that one bit is supposed to mean.  Trying to convey security policies
via a similar method strikes me as doomed from the start.

Dave Fillingham

>----------
>From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent: 	Thursday, September 10, 1998 1:48 PM
>To: 	Mike Smith; [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Cc: 	[email-masked]
>Subject: 	RE: RE: New Extension Proposed: Method Of Authentication
>
>
>> 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
>
>This is heading straight into the quagmire I spoke about...
>
>Decimal numbers is just about the worst approach since it means that 
>a central registry has to be kept - yet another task for IANA! and
>the arbitrary limit of 255 sounds guaranteed to ensure that the
>namespace will quickly become cluttered with ad hoc private 
>definitions being used on an 'experimental' basis.
>
>I don't see any value in the taxonomy presented. What is a 'military'
>identification method? Is identification by the US army equivalent to
>that of the Taleban in Afghanistan?
>
>The drivers license is particularly dubious. My UK drivers license
>has no photograph and is valid until sometime after 2020.
>
>Are there CAs who actually want to specify their exact authorization 
>processes? Are such processes objectively definable? A commercial
>CA does not define authorization procedures for every concievable
>document they might accept in their CPS. The first time a US CA
>decides on acceptable forms of authentication for a Monaco 
>corporation is likely to be when they get a purchase request.
>
>
>If you want to take the matter further I suggest you write an
>Internet Draft and see if the working group chairs want to 
>make it a work item.
>
>		Phill
>

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Sep 1998 16:44:21 +0200

This is really fascinating.

When I read the proposal for a new extension I said to my self:
Good this man i brave. I wonder how many seconds he will live before he is
gunned down.
Not because the idea is stupid. Just because of the obvious "quagmire"
syndrome.

I have recently studied one extensive trial to specify such extensions and
I just want to join to the consensus here. 

- This is a quagmire and not suited for standardization (at least not
within PKIX).
- The policy OID solves the problem as far needed.

And according to changing CPS:es. One CPS may change many times as long as it
reflects the same policy. If security drops below policy requirements then
a new
policy OID has to be identified. So minimum security level is defined by
policy 
and not by CPS.

/Stefan

>Internet Draft and see if the working group chairs want to 
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Mike Smith <[email-masked]>
Date: Fri, 11 Sep 1998 10:16:37 -0600

OK, the quagmire consensus is taken for what it is.  I first proposed automating some trust decisions using a new extension, then using the existing policy qualifier.  The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient.

If this is to be the technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards.

Maybe the old PKIX 1 needs to be restructured to retain its contents and meaning, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies ,  practices or concept of operations (whatever people are using the OID to point towards).

The goal here is not to reopen old wounds or pull people into yet another quagmire (my Celtic genetics may predispose me to jumping inot bogs, however).  The question that folks seem to be attempting to address is the automation of trust domains.  

The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner.

I disagree.  This group is comprised of the most experienced and, IMO, brightest technologists in the industry.  

So, I pose the question to the best and brightest:  How do you suggest, then, that we automate domain or trust processing?

I think I know how we are going to operate across domains of trust  in the finanical industry.  I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet.

If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time).

Michael

>>> Stefan Santesson <[email-masked]> 09/11 8:44 AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

---

From: Mike Smith <[email-masked]>
Date: Fri, 11 Sep 1998 12:33:22 -0600

I think you've got it.  

As far as being ahead of state of the art, I've been in meetings with many of the folks on this list several years ago when the same issues of parsing the CPS in order to automate were brought up.

By the way, I was not suggesting parsing a free-form CPS, but structuring the CPS for automated processing, which might need then both a human and machine readable form or sections of the same CPS.

The saying goes (Warren Miller, Ski Film producer):  "If you don't do it now, You'll only be another year older when you do".

Michael

>>> Paul Koning <[email-masked]> 09/11 12:07 PM >>>
>>>>> "Mike" == Mike Smith <[email-masked]> writes:

 Mike> ...Maybe the old PKIX 1 needs to be restructured to retain its
 Mike> contents and menaing, but to specify a parsable structure and
 Mike> standardize (define rigidly) the terms used in the policies and
 Mike> practices or concept of operations (whatever people are using
 Mike> the OID to point towards).

 Mike> ...The feedback I get is not really "you are off track", but that
 Mike> "the problem is too big to solve", or that this group is
 Mike> incapable of solving this problem in a timely manner.

 Mike> I disagree.  This group is comprised of the most experienced
 Mike> and, IMO, brightest technologists in the industry.

 Mike> So, I pose the question to the best and brightest: How do you
 Mike> suggest, then that we automate domain or trust processing?

I think the question you pose is not a little, but vastly beyond the
state of the art.

As I understand it, the goal you're posing is: define a way for the CA 
to encode into the cert information that the relying party can use to
decide whether the subject of that cert was authenticated by means
strong enough to be satisfactory to the relying party.

A somewhat analogous question (though not applicable to a particular
cert) is whether the CA's CPS is strong enough for the relying party.

It seems to me that this latter question is one you drop onto your
company's lawyer to settle.  It involves parsing natural language
(well, anyway, legal language) to see what it means, and whether that
meaning is satisfactory to your corporate requirements.

I very much doubt that a mapping from natural language legal
terminology to formal logic will be defined anytime in the next 10
years.  Come to think of it, thinking of Goedel makes me wonder if
it's even theoretically possible.

The above would seem to be just as applicable to the cert subject
authentication statement as it is to the CPS.  After all, the
authentication used in creating a particular cert is basically just
the application of the CPS to that particular subject.

 paul
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

---

From: Charles Moore <[email-masked]>
Date: Sun, 13 Sep 1998 07:31:56 +1000

All, we ( Australian National Standards Group) have been working on a
simular problem. 
I.e how does a relying party know what evidence of Identity that the
RA/CA makes a statement about when performing the registration process.
There are assocaited issues, but lets start with this one.

We have a working draft that proposes the use of a policy qualifier as
below:

pkaf-policy-Identification CERT-POLICY-QUALIFIER ::= {
	POLICY-QUALIFIER-ID	id-pkaf-policy-Identification
	QUALIFIER-TYPE		Identification }

Identification ::= BIT STRING {
	driversLicense	(0),
	passport	(1),
	creditCard	(2),
	organisationIDBadge	(3),
	governmentIDBadge	(4),
	articlesOfIncorp	(5),
	companySeal	(6),
	notarizedDoc	(7),
	biometricThumb	(8),
	biometricVoice	(9),
	biometricFace	(10),
	biometricRetina	(11) }

We have not used A CP ( or any reference to a CPS) alone to do this as
experience is that within a given policy there is no direct mapping to
the level of identification needed. Identification is not the driver for
a CP or CPS, but rather a qualifier of these. 

Hope this assists the discussion.

Regards
Charles Moore
SPYRUS Pty Ltd
Phone: +61 73 256 7465, Extension 101

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 13 Sep 1998 00:25:48 +0200

Mike,

First of all. I truly hope that I didn't offend you with my remark.
I certainly didn't want that.

Yes, the problem you raise is both real and relevant. I just don't share
the same belief in automation through policy definition codings in
certificate extensions.

I do believe that it MAY work sufficient in a fairly closed environment
where one organization has the control over interpretations and
implementations. But international standard, no way. 

Actually I believe that the policy OID in certificates may serve automation
just fine in real life. If trust automation is developing to be an
competitive edge in a certain community, then CA:s will try to adopt to
well known policies and indicate them in the certificates. So in that case
there will just be a limited space of policy OID:s to consider. Whether
this will happen or not is up to the market but the market sure has the
tools needed if there is money to be made through interoperability.

Over specifying things before the true need has emerged is always
dangerous. And I'm sorry to say that we Europeans have some quite extensive
experiences along that line.

/Stefan

At 10:11 AM 9/11/98 -0600, Mike Smith wrote:
>OK, the quagmire consensus is taken for what it is.  I first proposed
enhancing automating some trust decisions using a new extension, then using
the existing policy qualifier.  The overwhelming response from people whose
comments I respect is that we should consider the policy OID sufficient.
>
>If this is to be technological solution for automated processing, then we
need to step backwards a few years and look at the definition of "to
process" with regard to the actual CPS that the OID points towards.
>
>Maybe the old PKIX 1 needs to be restructured to retain its contents and
menaing, but to specify a parsable structure and standardize (define
rigidly) the terms used in the policies and practices or concept of
operations (whatever people are using the OID to point towards).
>
>The goal here is not to reopen old wounds or pull people into yet another
quagmire (my cletic genetics may predispose me to jumping inot bogs,
however).  The question that folks seem to be attemoting to address is the
automation of trust domains.  
>
>The feedback I get is not really "you are off track", but that "the
problem is too big to solve", or that this group is incapable of solving
this problem in a timely manner.
>So, I pose the question to the best and brightest:  How do you suggest,
then that we automate domain or trust processing?
>
>I think I know how we are going to operate across domains of trust  in the
finanical industry.  I suggest that we in the IETF apply our great
resources building AUTOMATED systems that have a high assurance of working
together across the Internet.
>
>If, as some have suggested , I need to write a draft covering these
issues, I am up for that (if Warwick and Stephen think it is worth the
group's time).

    !